Roger Ineichen wrote: >Hi together > >I added a proposal where is important for the CPSSkin work and the >zope.app.viewlet implementation. >Can you take a look at it and tell me what do you think about. > >I hope it will be possible to implement a generic lookup concept >in page templates where we can use for CPSSkin or the viewlet >implementation form Stephan. > >I have some need for such a base API in the Tiks framework and >plan to implement this at the Neckar sprint if possible. > >Proposal >http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ContentProv >iderAPIForSkins > >Regards >Roger Ineichen > > >
Hi Roger, If I got it right, you are proposing a generic API, a generic lookup mechanism to find the objects located in a given region of a page (i.e. a "slot" in cpsskins) that could be used by any portlet, viewlet, pagelet provider and that is independent of the implementation (viewlet, pagelet, portlet, ...)? It could be that the viewlet implementation is already covered by the notion "global portlet" in cpsskins and that the use of slots in that case is redundant, since cells (columns) in cpsskins can act as containers already. So my question is: will there be some support for more contextual lookup mechanisms in the API that you are proposing, or will the same set of objects always be displayed inside the same region? Anyway, if the goal is to reuse portlets, viewlets, ... written for other applications inside cpsskins there are two options: 1) one is to create a third type of slot (beside the "by-folder", and the "by-perspective" kind of slot), this one relying on an API external to cpsskins to collect the viewlets. As far as I know any lookup mechanism will work in cpsskins as far as the objects located in the IRegion (slot) are uniquely identified. They do not need to be ordered; indeed cpsskins separates the lookup mechanism from the actual portlet display, which means that what is called "weight" in the viewlet implementation (a very approximate replacement of the notion of "order") is neither stored in the objects themselves nor inside the slot but in the slot's *display*. The display acts as a sort of visual proxy for the slot's content and portlet ordering is managed there instead. 2) I think that TTW development is very important when doing page design. So I'm currently working on refactoring the "Custom portlet" implementation In the current implementation the Custom Portlet looks for a ZPT, DTML, PythonScript object (or any object with a location that can be rendered) and renders it (see [1]). I want to extend the implementation to make it possible for page designers to write the template or script code directly in a text area and specify the format (ZPT, DTML, ..). Then the Custom portlet will create a template with the text code on-the-fly and render it. This is the equivalent of TTW programming, but without the need to use the ZMI. In that case the ZPT code written for the viewlets, pagelets, ... could be pasted directly in the text area of the Custom Portlet. Of course, the custom portlets can then be duplicated, modified, stylized, placed anywhere on the page. This solution would I think be more appealing for page designers since they won't need to get access to the file system to write the code. [1] http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/portlets/custom/__init__.py regards /JM _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
