[Zope3-dev] Re: AW: Are pagelets content providers?

[Thomas Lotze]

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