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 <[EMAIL PROTECTED]> It is simple to make things.
http://www.wiggy.net/ It is hard to make things
simple.
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team
