Philipp von Weitershausen wrote:
> Stephan Richter wrote:
>> Daniel Nouri wrote:
>>> 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
>>> to be highly customizable at runtime (vs. zcml time).
>> Component registrations can be done at runtime easily in a local
>> 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
>> implementation does it.
> Well, the way I define "viewlet" is that it's a content provider that's
> looked up by another content provider (the viewlet manager) using the
> adapter registry. That's why, after all, it's a *view*let.
> Portlets are also content providers, they're simply looked up
> differently, which distincts them from viewlets.
>>>> As to plone.portlets, I think they are heavily overengineered. Last
>>>> 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
> Martin Aspeli and I were in close context when he implemented
> plone.portlet. While I too was a bit overwhelmed of the amounts of
> machinery it ended up using, I also acknowledge the various complicated
> use cases that it's trying to solve.
I wonder if that machinery would have been considerably less heavy if we
would have sticked to CMF expressions and the like for registrations
(compare CMF's actions tool). I keep being amazed by how much flexibility I
can achieve by simply combining Python expressions with views, e.g. include
this element if "context/@@plone/isRTL". (I know you're not a big fan of
the @@plone view, but it's just an example. :)
> In the end, most of the machinery
> is there to support TTW configurability. I find this part is generally
> underestimated, both in effort and in LOC (probably because we have so
> little of it on Zope3 these days).
What do you mean by "this part is generally underestimated". Do you think
it's understandable that it's grown so complex, or are you saying that TTW
configurability is harder than it needs to be with viewlets and/or local
> plone.portlet seems to enjoy some success, though. Geir Baekholt told
> me, for example, that their new version of LinguaPlone is using portlets
> to render content that's commont to all translations of a document (e.g.
Well, any "modern" Plone Product will have to adopt the new portlets sooner
or later. (There is a backwards compatibility mode, but still.) That's why
I'm making such a fuss out of it. ;)
Zope3-users mailing list