[Zope3-Users] Re: View or content provider

[Daniel Nouri]

Hi Stephan!

Stephan Richter wrote:
> On Tuesday 17 July 2007 14:28, Daniel Nouri wrote:
>> plone.portlets introduces some two dozen (!) interfaces/concepts on top of
>> viewlets in order to implement the flexibility that it needs.  E.g. it
>> introduces an 'available' method/property that controls visibility, which
>> viewlets by themselves lack.  I imagine I could do this with less overhead
>> without viewlets (see my other mail), or IOW: viewlets don't seem
>> inherently flexible to me.
> 
> Then you do not understand them. They are inherently flexible because content 
> providers are multi-adapters of context, request, and view and viewlets are 
> multi-adapters of context, request, view, and viewlet manager. Using adapted 
> objects as discriminators has opened totally new ways of developing UI 
> patterns in Zope 3. We have heavily learned from using those patterns and I 
> think the new z3c.form* framework benefitted a lot from it.

You make it sound like the more objects you adapt, the more flexible you
are.  Which is true to a certain extent, but at the same time, the more
objects you adapt from, the harder are the registrations to read and
understand and the more tedious they are to write (compared to e.g. CMF
expressions).

Also, adaptation only works to a certain extent as a way to determine if a
viewlet should be displayed or not.  So even with four interfaces to adapt
from, I cannot register by permission or by a rule like "are there any news
items available".  I'm not saying that these use cases can't be solved
easily, it's just that the registry for viewlets doesn't have a way to
express them with adaptation alone.

BTW, what I've seen from z3c.form* looked quite impressive!  I'm sure that
your concepts work nicely for you there.  But maybe they are not the most
practical way to define my kind of page composition use case, which needs to
be highly customizable at runtime (vs. zcml time).

> As to portlets. When talking about portlets, the Web community refers usually 
> to features described in JSR 168. Viewlets have absolutely no ambition to 
> come even close to this. In fact, we specifically designed viewlets to do 
> much less with the intend to later implement portlets on top of them.
> 
> To you viewlets might look extremely simple, in idea and implementation. But 
> this did not come over night and we said: Oh cool, let's use a 
> triplet-adapter to do content providers. Roger and I did an independent 
> implementation of viewlets, then fiercly discussed for nearly a week (people 
> attending the Tuebingen sprint can attest to this) the design goals and 
> implementation. The simple design of both, content provider and viewlets, is 
> thus a result of a deep understanding of UI development problem, not 
> something that was thrown together quickly. You know, often less is more!

I'm all for less is more!

> As to plone.portlets, I think they are heavily overengineered. Last time I 
> looked at its API, it was heavily bloated. This might be a result of being a 
> Plone package though, I do not know, but I would certainly implement them 
> much slimmer. 

Maybe the reason is that viewlets are not the best starting point for
Plone's use case?

In any event, I'm glad that viewlets exist, and I hope I'll soon have a
chance to use them in a way that they were designed to be used.  Currently,
in Plone 3, they are a source of frustration to me.  (And no, it's not
because Plone developers are inherently stupid :-P)


Regards,
Daniel