[Framework-Team] Re: PLIPs for 3.1

[Tom Lazar]

On Dec 9, 2007, at 1:45 PM, Wichert Akkerman wrote:

> Previously Martin Aspeli wrote:
>> ... there's another kind of portlet which we can provide (ship with  
>> or
>> not, up to you guys) - a "referenced content portlet". Here, you  
>> search
>> (using an UberSelectionWidget) for a Page that's then rendered as
>> content. We can provide multiple renderers depending on what was
>> selected (plone.portlets has some design provisions for this exact  
>> use
>> case), so that there's a portlet-specific view for a Document that's
>> different to one for an Event, say.
>
> The collection portlet is just that. Once you go down that road I  
> would
> prefer a more general approach where we introduce the concept of
> context-based rendering, or tile-based rendering as some people call  
> it.
> Basically the idea is that you want to render a particular object in
> different kinds of places/sizes: portlets, collage slots, main page
> body, reference, etc. This is something that I requested more and more
> often and it makes sense to try and come up with a proper  
> infrastructure
> for handling it.

that sounds interesting and also would cover some use cases that  
clients of mine have floating around. i like the term 'tile based  
rendering'. is there some (semi-formal) concept behind that term? with  
me it conjures up the idea of being a whole lot more flexible in how  
site managers (i.e. not developers!) can structure and re-use content.  
something like 'big' websites such as ny times, spiegel.de etc. use,  
where e.g. an article can have two, three different kind of teasers  
that are rendered in different sizes in different contexts etc.

is that something along the lines you had in mind? are you planning on  
turning that into a plip? 3.1 material? certainly, the Zope CA seems  
to lend itself for expressing such scenarios (i.e. adapting a content  
object to a certain teaser type/ teaser interface, which then gets  
picked up by certain viewlet/portlet managers etc.)

finally, i think we should tread carefully here, though, as there have  
already been numerous and vociferous complaints regarding how  
complicated the porlet infrastructure has become. any design should  
not increase the complexity for the existing use cases.

just my $0.02,

cheers,

tom

>
>
> Wichert.
>
> -- 
> Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
> http://www.wiggy.net/                   It is hard to make things  
> simple.
>
> _______________________________________________
> Framework-Team mailing list
> Framework-Team at lists.plone.org
> http://lists.plone.org/mailman/listinfo/framework-team
>