[Zope3-Users] [Fwd: Re: View or content provider]

[Daniel Nouri]

I believe Stephan didn't send his answer to the list by accident (I'm using
NNTP over gmane), so here it is:

-------- Original Message --------
Subject: Re: View or content provider
Date: Wed, 18 Jul 2007 10:25:43 -0400
From: Stephan Richter <srichter at cosmos.phy.tufts.edu>
Reply-To: srichter at cosmos.phy.tufts.edu
To: Daniel Nouri <daniel.nouri at gmail.com>
References: <1184171197.28953.5.camel at m03089>
<200707171503.33735.srichter at cosmos.phy.tufts.edu> <469DFAF5.2050100 at gmail.com>

On Wednesday 18 July 2007 07:35, Daniel Nouri wrote:
> 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).

It makes it much more flexible.I personally do not find multi-adaptation that
hard to understand. If properly taught, I have found that people get this
really fast, once they understand adapters.

Registrations are also easy to understand, because the objects adapted are
always well documented by the constructor and the zope.component.adapts
statement. So it is very formally defined.

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

Well, this is the reason we have a viewlet manager API that allows you to
further filter and sort the viewlets. And note, the interaction API between
the manager and the viewlet is well defined by interfaces.

> BTW, what I've seen from z3c.form* looked quite impressive!

Thanks.

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

Component registrations can be done at runtime easily in a local component
registry. Also, there is nowhere in the viewlet manager API a requirement
that says that the viewlets have to be looked up using adapters. In fact, for
a list of articles, I would not use adaptation in the same way the default
implementation does it.

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

I think they are. I would just implement the API very differently. I just wish
the Plone developers would have asked us for comments when using Zope 3
technologies.

Regards,
Stephan