[Framework-Team] Re: PLIPs for 3.1

[Wichert Akkerman]

Previously Tom Lazar wrote:
> 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.

I'm only aware of the term being used in 3D rendering context: the idea
is to break up a scene into tiles, determine some qualities of those
(what part is visible, lightning, etc.) and then render the tiles. There
are simularities: our pages consist of many different elements (portlets,
content objects, search results, breadcrumbs, etc.) that are rendered in
different types of UI elements (portlets, viewlets, folder/search result
list items, main view). At the moment we have no structured way to
approach this, which means that we are reinventing wheels in several
places. For example we have view templates for collections in CMFPlone
(the main topic view), in the collection portlet, in Collage, in the
folder_listing template, in the search result template and probably a
bunch of others. Instead I envision a system where we work with a set of
tile-types and register views per content type per tile type. That would
allow you to do things like 'give me a rendering of object X for a
portlet-style tile' or 'objects of type Y should use this template when
rendered in a search result'.

If you draw this up you basically get a matrix of views with a
content-type axis and a tile-type axes. Something like:

        | main content  |  portlet          | search result   | folderlisting
 -------+---------------+-------------------+-----------------+----------------
 Topic  | topic_view.pt | topic_portlet.pt  | topic_list.pt   | topic_list.pt
 Page   | page_view.pt  | page_portlet.pt   | page_summary.pt | page_list.pt
 Link   | redirect.pt   | link_portlet.pt   | link_list.pt    | link_list.pt

you could register them like this:

  <plone:tile
      template="page_view.pt"
      for=".interfaces.IDocument"
      name="portlet"
      />

and you could use them like this:

  <tal:tile replace="python:tile(obj, style='list')">
    ..
  </tal:tile>

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

I think this is too much of a change for 3.x. However it is a direction
that I think is worth investigating for 4.0. I'm not sure if I will have
time to work on it though.

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

I suspect this will simplify a lot of things by providing a consistent
method of managing how things should be rendered.

Wichert.

-- 
Wichert Akkerman <wichert at wiggy.net>    It is simple to make things.
http://www.wiggy.net/                   It is hard to make things simple.