Re: [Zope-dev] Interface for renderable component
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, -- Michael Howitz · [EMAIL PROTECTED] · software developer gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1 Zope and Plone consulting and development ___ 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 )
Re: [Zope-dev] Interface for renderable component
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 -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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 )
Re: [Zope-dev] Interface for renderable component
2008/9/16 Stephan Richter [EMAIL PROTECTED]: 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 ___ 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 )
Re: [Zope-dev] Interface for renderable component
On Tuesday 16 September 2008, Malthe Borch wrote: 2008/9/16 Stephan Richter [EMAIL PROTECTED]: 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 -- Stephan Richter Web Software Design, Development and Training Google me. Zope Stephan Richter ___ 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 )
Re: [Zope-dev] Interface for renderable component
Hi Malthe Betreff: Re: [Zope-dev] Interface for renderable component 2008/9/16 Stephan Richter [EMAIL PROTECTED]: 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 ___ 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 )
Re: [Zope-dev] Interface for renderable component
2008/9/16 Roger Ineichen [EMAIL PROTECTED]: 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 ___ 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 )
Re: [Zope-dev] Interface for renderable component
Hi Stephan Betreff: Re: [Zope-dev] Interface for renderable component On Tuesday 16 September 2008, Malthe Borch wrote: 2008/9/16 Stephan Richter [EMAIL PROTECTED]: 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 ___ 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 )
Re: [Zope-dev] Interface for renderable component
2008/9/16 Roger Ineichen [EMAIL PROTECTED]: 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 ___ 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 )
Re: [Zope-dev] Interface for renderable component
Hi Malthe Betreff: Re: [Zope-dev] Interface for renderable component 2008/9/16 Roger Ineichen [EMAIL PROTECTED]: 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 ___ 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 )
