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

[Thomas Lotze]

Roger Ineichen wrote:

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

True.

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

I see difference between creating content and providing it by a content
provider interface, but since the content created by some code must
somehow be passed to whatever then provides IContentProvider if it isn't
the same object anyway, that "some code" might as well provide
IContentProvider itself. In the case of pagelets the implementation does
that already anyway.

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

No, it isn't. The ancestry of IPagelet doesn't include anything named
IPresentation or similar.

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

So what's the business with all that delegation? Why must the source of
content be distinct from the content provider? It certainly isn't that way
for viewlets. What more is there to the delegation than in the case of
pagelets, the need to access the same pagelet instance for creating
content that has already been instantiated as the view?

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

Which, in turn, does appear in the ancestry of IContentProvider. Provision
of IPresentation doesn't seem to be a reason for pagelets not to be
content providers.

> Probably I don't understand this correct. Are you thinking about a
> IContentProvider which collects more then one pagelet?

Exactly. Or rather, more than one content provider, more than one of which
might just happen to be pagelets if someone thought it might make sense to
also use them that way directly.

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

Well, z3c.form is about creating an HTML form from a schema. Such a form
appears somewhere on a page, which might be the place the pagelet content
ought to go. If this is all you want, the implementation of a form as a
pagelet is fine. However, you might want something more complex to fill
that place, something that contains a form among other elements. Now
you're in a pinch: you want to use z3c.form for its functionality of
assembling an HTML form from a schema, but what you get is a pagelet that,
by being denied recognition as a content provider, shouldn't be used as a
part of what makes up the pagelet content.

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

Unless I'm mistaken, this has to do with the way view classes are created
by the ZCML viewlet directive - which is how I've used it so far.

> Did you recognize that the __init__ are different.
> 
> A IContentProvider defines:
> 
> def __init__(self, context, request, view)

An interface does not define the constructor signature of classes that
might implement it. Interfaces are about communicating with instances of
classes implementing them, not about creating those instances.

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

I think that it would be better to define pagelets to be content providers
so as to know what to deal with than to have to repeat that
IContentProvider thing for every extension interface and implementation.
It's not as if IContentProvider was all that specific anyway. Having to
add it explicitly again and again sounds like a dead chicken.

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

This isn't the interface's business but sounds more like a factory
function that instantiates the pagelet without passing the view to the
constructor and adds it as the __parent__ attribute afterwards.

> Does this make sense for you?

I understand the problems that have to be solved, but as long as you're
talking about __init__ being specified in interfaces, it doesn't make
sense to me.

> what do you think about to remove the formlib implementation from the
> z3c.pagelet package?

I think it would make things cleaner and make it easier to see what
belongs where. Plus there's possibly not much need to wrap zope.formlib in
pagelets given the existence of z3c.form. Removing the stuff sounds like
applying "there ought to be only one way to do it", so I'm all for it.

-- 
Thomas