Currently a number of z3c.* packages rely on ``zope.pagetemplate.interfaces.IPageTemplate`` even though they don't care at all that it's a template they're getting. All they need to know is that it's a callable and that it returns HTML.
I think it'd be a good idea to introduce the following interface that we can use instead:
class IRenderer(Interface): def __call__(**kwargs): """Outputs HTML."""
This interface should be defined in a package with minimal dependencies.
\malthe
Hi Malthe
Betreff: [Zope-dev] Interface for renderable component
Currently a number of z3c.* packages rely on ``zope.pagetemplate.interfaces.IPageTemplate`` even though they don't care at all that it's a template they're getting. All they need to know is that it's a callable and that it returns HTML.
I think it'd be a good idea to introduce the following interface that we can use instead:
class IRenderer(Interface): def __call__(**kwargs): """Outputs HTML."""
This interface should be defined in a package with minimal dependencies.
Why not define a IHTMLProvider or someting like that located in the zope.contentprovider package.
I think the contentprovider package is a good location for anything like that.
btw, the IPageTemplate is only used as an adapter lookup for templates at least in z3c.template. The reason why it uses IPageTemplate is that the adapter which get returned is an IPageTemplate.
If you introduce another new interface the IPageTemplate has to provide that interface.
Regards Roger Ineichen
\malthe
Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
2008/9/15 Roger Ineichen dev@projekt01.ch:
btw, the IPageTemplate is only used as an adapter lookup for templates at least in z3c.template. The reason why it uses IPageTemplate is that the adapter which get returned is an IPageTemplate.
Yes, I understand, but it's getting more than it should be asking for.
\malthe
On Monday 15 September 2008, Roger Ineichen wrote:
Why not define a IHTMLProvider or someting like that located in the zope.contentprovider package.
Yeah, I like that. This is the right package, since it defines high-level patterns without any heavy implementations.
Regards, Stephan
2008/9/16 Stephan Richter srichter@cosmos.phy.tufts.edu:
Yeah, I like that. This is the right package, since it defines high-level patterns without any heavy implementations.
Unfortunately, ``zope.contentprovider`` relies on ``zope.tales`` because it implements a TALES expression and somehow, this package pulls in zope.app.*-packages.
I think we should work to never have zope.*-packages depend on zope.app.* ––– and perhaps declare a truce on minimizing dependencies within the zope.* group of packages (it seems very difficult).
\malthe
On Tuesday 16 September 2008, Malthe Borch wrote:
2008/9/16 Stephan Richter srichter@cosmos.phy.tufts.edu:
Yeah, I like that. This is the right package, since it defines high-level patterns without any heavy implementations.
Unfortunately, ``zope.contentprovider`` relies on ``zope.tales`` because it implements a TALES expression and somehow, this package pulls in zope.app.*-packages.
Darn. Let me think about that. I guess a new package to collect our community-agreed high-level UI patterns would be good then.
From my point of view, it should include the following patterns:
* update/render
* generic IRenderer API (based on update/render!)
* Probably the concept of content providers
The package should probably live int he zope.* namespace.
Anything else?
I think we should work to never have zope.*-packages depend on zope.app.* ––– and perhaps declare a truce on minimizing dependencies within the zope.* group of packages (it seems very difficult).
I agree.
Regards, Stephan
Hi Stephan
Betreff: Re: [Zope-dev] Interface for renderable component
On Tuesday 16 September 2008, Malthe Borch wrote:
2008/9/16 Stephan Richter srichter@cosmos.phy.tufts.edu:
Yeah, I like that. This is the right package, since it defines high-level patterns without any heavy implementations.
Unfortunately, ``zope.contentprovider`` relies on ``zope.tales`` because it implements a TALES expression and somehow, this package pulls in zope.app.*-packages.
Darn. Let me think about that. I guess a new package to collect our community-agreed high-level UI patterns would be good then.
From my point of view, it should include the following patterns:
update/render
generic IRenderer API (based on update/render!)
Is the IRenderer interface not exactly the same like the IContentProvider?
Does it provide an additional __call__ method? Or only __call__ method?
It smells to me that we should name it to something like IProvider if it's a base for our IContentProvider or IXHTMLProvider if it provides XHTML based on z3c.pt
I preferre anything with the word provider instead of renderer.
- Probably the concept of content providers
The package should probably live int he zope.* namespace.
Anything else?
yes, this package must be a zope.* package. Then we could move the ITerms interface to this package too rather then add a new one like zope.term.
I think we should work to never have zope.*-packages depend on zope.app.* ––– and perhaps declare a truce on minimizing dependencies within the zope.* group of packages (it seems
very difficult).
I agree.
Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
2008/9/16 Roger Ineichen dev@projekt01.ch:
yes, this package must be a zope.* package. Then we could move the ITerms interface to this package too rather then add a new one like zope.term.
Could this package be called ``zope.browser`` then?
\malthe
Hi Malthe
Betreff: Re: [Zope-dev] Interface for renderable component
2008/9/16 Roger Ineichen dev@projekt01.ch:
yes, this package must be a zope.* package. Then we could move the ITerms interface to this package too rather then add a new one like zope.term.
Could this package be called ``zope.browser`` then?
+1 to this hot topic
I like the idea to have a pure interface package for some basic (context, request) adatper components called views, browser pages or contentprovider etc.
Regards Roger Ineichen
\malthe
Am 17.09.2008 um 01:57 schrieb Roger Ineichen: [...]
Could this package be called ``zope.browser`` then?
+1 to this hot topic
I like the idea to have a pure interface package for some basic (context, request) adapter components called views, browser pages or contentprovider etc.
Hi, is there any progress on this idea? Anyone who plans to implement it?
Yours sincerely,
Hi Malthe
Betreff: Re: [Zope-dev] Interface for renderable component
2008/9/16 Stephan Richter srichter@cosmos.phy.tufts.edu:
Yeah, I like that. This is the right package, since it defines high-level patterns without any heavy implementations.
Unfortunately, ``zope.contentprovider`` relies on ``zope.tales`` because it implements a TALES expression and somehow, this package pulls in zope.app.*-packages.
I think we should work to never have zope.*-packages depend on zope.app.* --- and perhaps declare a truce on minimizing dependencies within the zope.* group of packages (it seems very difficult).
zope.app.testing is only a test dependency. We have to replace such zope.app.testing dependencies in moste z3c.* package anyway. But first we need a better testing base for doing so.
Are you thinking about a basic UI interface package. where we probably define some interfaces e.g. IBrowserPage and friends and nothing else?
This whould offer a good base for any other UI framework to provide the right interfaces for their implementation. Interfaces like IContentProvider could depend on such an interface too. And the ITerms interface could also become a part of this package rather then move to a zope.term package which we already agreed on.
Regards Roger Ineichen
\malthe
2008/9/16 Roger Ineichen dev@projekt01.ch:
Are you thinking about a basic UI interface package. where we probably define some interfaces e.g. IBrowserPage and friends and nothing else?
It really depends on how much we want to play with frameworks like repoze.bfg that do not want complete buy-in.
This whould offer a good base for any other UI framework to provide the right interfaces for their implementation. Interfaces like IContentProvider could depend on such an interface too. And the ITerms interface could also become a part of this package rather then move to a zope.term package which we already agreed on.
In Zope, there's a default implementation for most interfaces and this makes it easy to get started. The downside is that often times those implementation have a bunch of dependencies. But I don't think there's a way out of that.
That's why I think we should simply try to get rid of zope.app.*-dependencies for starters and also try to move commonly used components/interfaces to base packages.
\malthe
-
Malthe Borch -
Michael Howitz -
Roger Ineichen -
Stephan Richter