Gary Poster wrote:
and to sketch the difference between widgets and viewlets out.
The zope.widget package in the branch is currently in disrepair, but
the intent is for widgets to be subviews. The subview package
actually grew out of the widget work. This won't be ready for 3.2.
I personally don't think that I want default widget look-up to
require (context, request, view), as opposed to the current (context,
request), so I'd be in favor of widget interfaces extending the
subview interfaces, not the contentprovider interface. If for some
reason someone wanted a widget system with lookups based on
contentprovider then that could be an additional layer, still using
all of the (context, request)-based code.
I thought the anology would be between widget -> viewlet and not widget
-> content provider.
I read your subview readme. IMO the composition pattern of subviews you
proposed is very interesting too. Comparing the lookup signatures...
subview -> (context, request)
content provider -> (context, request, view)
viewlet -> (context, request, view, manager)
... the current viewlet implementation lacks of this pattern, because it
use different adaptions for content providers and viewlets. Looking from
this composite subview perspective, the view and manager parameters of
viewlets brings some redundant informations. In my understanding this
signature was choosen to gain a bigger presentation flexibility. Maybe
we could use a pattern like the lookup of named templates (formlib) to
decouple presentation of subviews, but using similar signature for
content providers and viewlets.
tel;work:++41 56 534 77 30
Zope3-dev mailing list