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

[Roger Ineichen]

Hi Thomas
 
> Betreff: [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.

Probably we should say;
"Pagelets are views which support the publisher __call__
attribute and provide the update/render pattern."


> > 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.

You are wrong here. A IContentProvider doesn't define content.
A IContentProvider provides content. That's different.

I a component defines content it provides the IPresentation
interface which is the case for IPagelet.

A IContentProvider knows only how to get content for another
component. Again, it's a delegation pattern. 


> 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.

You are saying, that we have IContentProvider providing content
and defining content. Define content is the part of the 
IPresentation interface.

> 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.

Probably I don't understand this correct. Are you thinking
about a IContentProvider which collects more then one 
pagelet? Probably I don't see your idea. Can you descibe it
what do you mean with "as long as ... page of its own" 
and "pagelet as content provider".

I don't understand how a pagelet can get called as a 
content provider. The adaption doesn't work because
they support different __init__ method signatures.

> > 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.

Did you recognize that the __init__ are different.

A IContentProvider defines:

def __init__(self, context, request, view)
    self.context = context
    self.request = request
    self.view = view

and a IPagelet defines:

def __init__(self, context, request):
    self.context = context
    self.request = request

Probably we should describe this in the interface too.
This whould manifest the difference of content provider
which provide content and pagelets whcih defines content
in a better way.


I guess there is nothing wrong with your idea, you 
can allways mix IContentProvider and IPagelet in a new
interface. But the existing implementation of IPagelet
is not a IContentProvider out of the box.

A IPagelet called by the IContentProvider TALES expression
whould have to support __init__(self, context, request, view)
which isn't the case in the Pagelet implementation.

Probably it was a mistake to not define this defference in
the interface. But we where thinking that this let us some
room for the implementation. E.g. like you are proposing.
But I still think we should not mix the IPagelet and 
IContentProvider pattern into the pagelet implementation
by default.

Does this make sense for you?

btw, 
what do you think about to remove the formlib implementation
from the z3c.pagelet package?
 
Regards
Roger Ineichen

> --
> Thomas
> 
> 
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org
> Unsub: 
> http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch
> 
>