Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> >> this is more a design feature than an implementation feature. > > > Could you explain *why* you need relations? > >
yes, because adapters provide flexible relations between *components* (interfaces, classes), but not between *content* objects. I want to be able to say (or the user) - this portlet uses this widget - this portlet uses this style not for a *class* of portlets, but for *instances* of classes. Adapters connect interfaces, not instances. to sum up: for exactly the same reason as why Zope2 moved to a component-based architecture, but for the content this time. I want to be able to connect content objects (portlets, styles, widgets, layouts) in a flexible way. and by the way it works, so why explain why you need something when it works as expected? >> >>>> 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. > > > Why would you want to generate RSS in a portlet? the portlet data is used for syndication in RSS / ATOM too in a RSS rendering engine (the [RSS] orange button). if the portlet already renders HTML, there is no way to convert HTML to RSS. > >> 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 >> > > > So > > - You get a widget of a particular type. > > - You adapt the widget (with a request) to get a widget filter. > > - You call the portlet to get some data. > > - You call the widget filter with the data to get HTML markup. > this is just one example of a rendering engine (the HTML rendering engine) > I guess the widget filter somehow decides how to generate HTML based > on the widget and data. Similarly, it somehow chooses a style. > It's unclear how this is working. > the widget knows nothing about the style that is going to be applied afterwards. The portlet <-> style connection is a relation defined in the relation store. > Can you say why you chose this division of labor? > it is one example of a chain of filters that covers most of the use cases to create HTML pages. Since the engine definition is defined in a zcml file it can be changed easily. I could go into the details of the design, but since it works as expected ... > I agree that, given a model where portlets only generate data, "pagelett" > is not a good name. Perhaps "applet" would be a better name. > > IMO, the choice of the term "widget" is unfortunate, both because it > clashes > with the Zope 3 use of the term and because it clashes with common > usage in > GUIS, where widgets are responsible for UI generation, whereas here, > AFAICT, > widgets are responsible for UI specification in some fashion. > > Here's an alternate suggestion that follows Zope 3 style a bit more: > > - We have applets that provide application functionality. These are > like your portlets. > > - We define layout types. These extend something like ISubPage (as > defined in > formlib). Alternatively, we use named adapters. > what is a layout type? > - We adapt the applets with the request to the layout type: > > view = component.queryMultiAdapter((applet, request), IDropDownList) > > or, with named adapters: > > view = component.queryMultiAdapter((applet, request), ISubPage, > 'dropdown_list') > > Would something like this work for you? > > Jim > I don't think so, because the relation portlet <-> widget <-> layout gets hardcoded in python. I would mean that I would have to rewrite the AJAX theme editor. the difference with the rendering architecture that I have implemented is that new rendering engines can be created by reusing components. I think that your approach is not generic enough, it is too much tied with the webpage generation paradigm (it assumes that a portlet has a layout, or a style...) which are web-related concepts. /JM _______________________________________________ Zope3-dev mailing list [email protected] Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
