[Zope3-Users] Re: View or content provider

[Philipp von Weitershausen]

On 23 Jul 2007, at 17:51 , Daniel Nouri wrote:
>>>>> 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.
>>
>> 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. :)

Python expressions can certainly be very powerful, but they have  
their limits. Just like adaption does (the isRTL use case is hard to  
do with adaption, I suppose).

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

Yes, at least for the use cases that Martin brought up. Note that I  
tried to warn him several times not to over-engineer, but I think  
it's normal that at the beginning you always end up doing that. It's  
never too late to simplify by introducing shortcuts...

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

Who says that the backwards compat mode has to away. Or that there  
can't be another shortcut that handles all the simple cases?