[Zope3-dev] Re: AW: Are pagelets content providers?
Roger Ineichen wrote: > I was carfully skip some additional method decalration because I didn't > know if we gona use IPagelets without render and update in other > implementations. The z3c.pagelet README.txt says that "Pagelets are views which can be called and support the update and render pattern." So either this refers to the particular implementation only, in which case I'd say an independent definition of the concept of pagelets is missing, or otherwise it doesn't leave much room for implementations without update and render methods. > I disagree, the IPagelet is not a IContentProvider. The pagelet is the > component which defines the content and the renderer is the content > provider. It's a delegation pattern. > > I explicit didn't implement IContentProvider in IPagelet because a pagelet > has to conceptual functionality of a page and not of a content provider or > viewlet thing. So the pagelet is really two things: a specific implementation of a browser page, and a component which defines content. Both should reflect in its interface, and why should something which defines content and follows the update/render pattern not formally be declared a content provider? Calling it something else with the same methods serves only to keep around an interface twice, by different names. AFAICS, there's nothing wrong with two content providers taking part in delivering the pagelet's content: one that originally creates the content behind the scenes, and one that is called from the layout template and delegates content creation to the former. You don't have to prohibit a pagelet to be called a content provider in order not to call it from the template directly. The issue might just be about interfaces describing how an object can be used instead of what code is supposed to use it. OTOH, there's real value in pagelets being content providers: library or application developers wouldn't have to decide up front whether their content providing component is to be used for primary or supplementary page content by deciding whether to implement it as a pagelet or a content provider; it could be both without adding any dead chicken abstractions. A real-world use case is z3c.form forms: they are implemented as pagelets which is fine as long as each form makes up a page of its own. However, we'd like to combine forms with other stuff, such as a search form with a result list. This is possible by using a form (a pagelet) as a content provider, but that feels like a hack as long as it isn't backed by formal interfaces. > The interface IPagelet(IBrowserPage) should reflect the page replacement. > > The IPageletRenderer(IContentProvider) should describe the pattern how the > pagelet content get accessed. > > Dou you see my idea behind this declarations? I do, but I can't follow the conclusion that pagelets should not at the same time be declared content providers, which they de facto are. > What do you think, should we add render/update to the IPagelet which is > not defined in IBrowserPage? > > Or should we add a IRenderUpdate interface in zope.? which we can use in > zope.formlib, z3c.form, z3c.pagelet and probably many more interfaces? Having thought some more about it since asking it as a question yesterday, I now definitely think that IPagelet should extend both IBrowserPage and IContentProvider. I can't see any value in a new IRenderUpdate interface since the distinction from IContentProvider would be very academic IMO. -- Thomas ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: ChoiceField and the use of sources/vocabularies
Christian Theune wrote: Zagy and I are trying to make z3c.form compatible with sources. Shrug... Why wouldn't it be compatible already? Shouldn't the widget abstract everything away? We had to investigate zope.schema for that and found the mess of vocabularies and sources that is still around. Here are some facts we found: - The Choice field has an attribute `vocabulary` which it says to be an 'IBaseVocabulary' object. - Reading the code of the choice field turns out that the actual contract is an 'ISource'. - Most client code working against the `vocabulary` attribute actually assumes it to be an IIterableVocabulary. That should be fixed then. Adaption to some iteration interface seems sensible. - The vocabulary code is badly entangled and mixes up concepts that sources get right. - Widgets for the choice field have to react differently to sources and vocabularies. We think: - The contract for the `vocabulary` attribute should be ISource. +1 Making a contract more loose than it already is is always possible. - Client code (e.g. a widget) should adapt the generic source it gets to a more specific and richer interface like IIterableSource. - Widgets for the choice field shouldn't have to care for two different things that the source could be. - Vocabularies ought to die. No can do. But perhaps we can keep the amount of BBB dance as small as possible. Vocabularies are just special ISource implementations. They should work, even if they mix stuff. Mixing stuff isn't forbidden... We'd love to remove all traces of vocabularies from zope.schema and it more clear how to use sources. +1 to making sources more straightforward. As deprecation has fallen out of favor, we wonder how to get rid of vocabularies. We definitely do not want to fork zope.schema. Would a sufficiently newer version (3.5, 4?) rectify breaking something in this way? I estimate that providing BBB is going to be a real pain. :/ So pain it is... -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zc.testbrowser alpha 1 released
hey benji, do you see a chance to use zc.testbrowser on remote (headless) machines in combination with buildbot? jodok On 28.09.2007, at 16:06, Benji York wrote: zc.testbrowser 1.0a1 I am very pleased to announce the first alpha release of zc.testbrowser: http://pypi.python.org/pypi/zc.testbrowser zc.testbrowser is a refactoring of zope.testbrowser to remove the Zope-specific bits plus the addition of the zc.testbrowser.real module. Testbrowser Real zc.testbrowser.real lets you use the testbrowser API to drive a real web browser; at the moment Firefox (but we may add support for others in the future). This lets you do testing of JavaScript heavy web applications with testbrowser (and doctests, of course). I envision people often beginning tests using the "regular" testbrowser, realizing the test/documentation they want to write needs JS, and then switching their test to use "real" and not having to change the already written parts of the doctest. Screen Shots One other feature of zc.testbrowser.real is the ability to save the current web page to a PNG file. This should be very useful for creating user manuals with embedded screen shots. Thanks -- Many, many thanks to my partners in crime at the Foliage Sprint: Stephan Richter, Rocky Burt, and Justas Sadzevičius. Bikeshedding Request Even though I coined it, I don't really like the name "real". I'd like suggestions that are short, pithy, and descriptive if anyone has any. Along the same lines, any suggestions for a new name for zc.testbrowser.browser (the classic testbrowser) would be appreciated as well. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/batlogg.lists% 40lovelysystems.com -- "Complex is better than complicated." -- The Zen of Python, by Tim Peters Jodok Batlogg, Lovely Systems Schmelzhütterstraße 26a, 6850 Dornbirn, Austria phone: +43 5572 908060, fax: +43 5572 908060-77 smime.p7s Description: S/MIME cryptographic signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
AW: [Zope3-dev] Are pagelets content providers?
Hi Thomas > Betreff: [Zope3-dev] Are pagelets content providers? > > During the gocept sprint on z3c.form last week we found that > the interface of pagelets (z3c.pagelet.interfaces.IPagelet) > is a mere marker interface on top of IBrowserPage, which > seems to me a bit thin. Yes and no ;-) I was carfully skip some additional method decalration because I didn't know if we gona use IPagelets without render and update in other implementations. > For one, the implementation of pagelets makes use of the > render and update methods. Since these methods are the ones > to be customized when writing custom pagelets, they should be > documented. Yes you are probably right, feel free to add them to the IPagelet interface. I didn't use the IPagelet interface without render/update till now and I see no other usecase without them. Or does anybody see such non render/update usecase for IPagelet? > While it would be easy enough to just add the methods to > IPagelet (which has actually been done for render by now), I > think IPagelet should really be an extension to > zope.contentprovider.interfaces.IContentProvider in addition > to IBrowserPage. It is already possible to use pagelets such > as z3c.form.form.Form as content providers. While the pagelet > implementation distinguishes between pagelet and pagelet > renderer, only the latter being declared the content > provider, this distinction seems to be made only in order for > the content provider lookup to return the same pagelet > instance that is the view. The renderer then only (sort of) > forwards the pagelet's own content provider functionality, so > the pagelet might as well be declared a content provider itself. I disagree, the IPagelet is not a IContentProvider. The pagelet is the component which defines the content and the renderer is the content provider. It's a delegation pattern. I explicit didn't implement IContentProvider in IPagelet because a pagelet has to conceptual functionality of a page and not of a content provider or viewlet thing. Hm, probably the naming of the pagelet within it's (*let) in the name is not so good as I was thinking. It could suggest that the pagelet is a additional page content like viewlets or content providers. But a pagelet is a full replacement for the IBrowserPage and not additional. The interface IPagelet(IBrowserPage) should reflect the page replacement. The IPageletRenderer(IContentProvider) should describe the pattern how the pagelet content get accessed. Dou you see my idea behind this declarations? What do you think, should we add render/update to the IPagelet which is not defined in IBrowserPage? Or should we add a IRenderUpdate interface in zope.? which we can use in zope.formlib, z3c.form, z3c.pagelet and probably many more interfaces? Regards Roger Ineichen > Any thoughts, objections, ideas? > > -- > Thomas > > > > ___ > Zope3-dev mailing list > Zope3-dev@zope.org > Unsub: > http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch > > ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] New package zc.configure provides an exclude directive for excluding zcml files
On 10/1/07, Jim Fulton <[EMAIL PROTECTED]> wrote: > > On Oct 1, 2007, at 11:17 AM, Jim Fulton wrote: > > > > > On Oct 1, 2007, at 11:09 AM, Lennart Regebro wrote: > > > >> On 9/29/07, Jim Fulton <[EMAIL PROTECTED]> wrote: > >>> > >>> This helps in cases where you want the configuration for a package, > >>> but you don't want some of the configuration that it includes. This > >>> allowed me to trim quite a bit off of the startup time, and, more > >>> importantly, the test setup time, for a project I'm working on. > >> > >> Works like a charm. We tried it here at the grok sprint. Although we > >> were only able to speed up Grok startup with 10%. Maybe we can get to > >> 20-30% if we work more on it, but we're not sure it's worth it. > >> > >> http://regebro.wordpress.com/2007/10/01/neanderthal-sprint- > >> speeding-up-the-grok-startup/ > > > > Maybe grok was already trimmed down. In my case, I basically > > eliminated all ZMI support (since I didn't need it). I got about 40%, > > Oh BTW, I ran Zope with debug logging. That way I could see what was > being included. Oh, useful... -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Are pagelets content providers?
During the gocept sprint on z3c.form last week we found that the interface of pagelets (z3c.pagelet.interfaces.IPagelet) is a mere marker interface on top of IBrowserPage, which seems to me a bit thin. For one, the implementation of pagelets makes use of the render and update methods. Since these methods are the ones to be customized when writing custom pagelets, they should be documented. While it would be easy enough to just add the methods to IPagelet (which has actually been done for render by now), I think IPagelet should really be an extension to zope.contentprovider.interfaces.IContentProvider in addition to IBrowserPage. It is already possible to use pagelets such as z3c.form.form.Form as content providers. While the pagelet implementation distinguishes between pagelet and pagelet renderer, only the latter being declared the content provider, this distinction seems to be made only in order for the content provider lookup to return the same pagelet instance that is the view. The renderer then only (sort of) forwards the pagelet's own content provider functionality, so the pagelet might as well be declared a content provider itself. Any thoughts, objections, ideas? -- Thomas ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] New package zc.configure provides an exclude directive for excluding zcml files
On Oct 1, 2007, at 11:17 AM, Jim Fulton wrote: On Oct 1, 2007, at 11:09 AM, Lennart Regebro wrote: On 9/29/07, Jim Fulton <[EMAIL PROTECTED]> wrote: This helps in cases where you want the configuration for a package, but you don't want some of the configuration that it includes. This allowed me to trim quite a bit off of the startup time, and, more importantly, the test setup time, for a project I'm working on. Works like a charm. We tried it here at the grok sprint. Although we were only able to speed up Grok startup with 10%. Maybe we can get to 20-30% if we work more on it, but we're not sure it's worth it. http://regebro.wordpress.com/2007/10/01/neanderthal-sprint- speeding-up-the-grok-startup/ Maybe grok was already trimmed down. In my case, I basically eliminated all ZMI support (since I didn't need it). I got about 40%, Oh BTW, I ran Zope with debug logging. That way I could see what was being included. Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] New package zc.configure provides an exclude directive for excluding zcml files
On Oct 1, 2007, at 11:09 AM, Lennart Regebro wrote: On 9/29/07, Jim Fulton <[EMAIL PROTECTED]> wrote: This helps in cases where you want the configuration for a package, but you don't want some of the configuration that it includes. This allowed me to trim quite a bit off of the startup time, and, more importantly, the test setup time, for a project I'm working on. Works like a charm. We tried it here at the grok sprint. Although we were only able to speed up Grok startup with 10%. Maybe we can get to 20-30% if we work more on it, but we're not sure it's worth it. http://regebro.wordpress.com/2007/10/01/neanderthal-sprint-speeding- up-the-grok-startup/ Maybe grok was already trimmed down. In my case, I basically eliminated all ZMI support (since I didn't need it). I got about 40%, Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] New package zc.configure provides an exclude directive for excluding zcml files
On 9/29/07, Jim Fulton <[EMAIL PROTECTED]> wrote: > > This helps in cases where you want the configuration for a package, > but you don't want some of the configuration that it includes. This > allowed me to trim quite a bit off of the startup time, and, more > importantly, the test setup time, for a project I'm working on. Works like a charm. We tried it here at the grok sprint. Although we were only able to speed up Grok startup with 10%. Maybe we can get to 20-30% if we work more on it, but we're not sure it's worth it. http://regebro.wordpress.com/2007/10/01/neanderthal-sprint-speeding-up-the-grok-startup/ -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
