Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> Jim Fulton wrote: >> >> >>> Jean-Marc Orliaguet wrote: >>> >>> >>>> >>>> basically if the "slot" that you're thinking about contains portlets >>>> then it's a sort of slot not a sort of portlet. >>> >>> >>> >>> Cool. So we can define new slot-like things (for example, >>> for JSR 168-style slots) and use your slots or not, as we wish. >>> >>> In particular, we can use CPS skins without being forced to >>> install triad registries unless we want to use your slots. >>> >> >> >> In that case it is possible to plug in other relation store backends >> (e.g RDF) that do not support genuine triadic predicates, which means >> that only "local folder" types of slots will be available, but some >> relation storage is required for the dyadic relations between elements >> and styles, widgets... because the relations between the elements are >> not stored on the elements themselves. > > > Sigh. Is this documented anywhere?
Currently the application adds relations into the relation store using a relation tool, there is not definite documented interface though, since not all the use cases are defined yet: https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/relations/tool.py The idea is to allow any relation store back-end (RDF, SQL, ..) to be plugged in. If the relation information was stored in the elements themselves (e.g. annotations, attributes, ...) this would make it very difficult to move the storage from the ZODB. this is more a design feature than an implementation feature. >> >> yes, I re-read >> http://mail.zope.org/pipermail/zope3-dev/2004-December/012852.html and >> while going through the different definitions I saw that not two >> implementations are done in the same way, which is fine. >> >> The important aspect is that "portlets" or "pagelets" as they are >> implemented in cpsskins separate model and view. >> They implement the "data model" part only, not the view itself, which >> is done later by widget, layout and style filters inside the rendering >> engine. > > > I'd like to understand how this works. > > Jim A portlet / pagelet generates some data (a list of menu items, for instance) as a data structure in python. - the data goes through a widget filter that convert the data into HTML. Depending on what widget is being used, the same data is displayed differently (vertical list, horizontal list, drop-down list...). - a style filters add the style information (class="..."), the portlet can then be displayed in HTML if other combinations of filters are used (a RSS filter for instance), the same data is displayed in RSS instead of HTML. which is shown on the following diagram: https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.png and documented here: https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.txt /JM _______________________________________________ Zope3-dev mailing list Zope3email@example.com Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com