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
