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.

fn:Dominik Huber
email;internet:[EMAIL PROTECTED]
tel;work:++41 56 534 77 30

Zope3-dev mailing list

Reply via email to