Hi Thomas
Betreff: [Zope3-dev] Re: AW: Are pagelets content providers?
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.
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
http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch