Roger Ineichen wrote:

>Hi together
>I added a proposal where is important for the CPSSkin work and the
> 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.
>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.


regards /JM

Zope3-dev mailing list

Reply via email to