[Zope3-dev] RE: Content provider API

[Roger Ineichen]

Hi Jean Marc 

> -----Original Message-----
> From: Jean-Marc Orliaguet [mailto:jmo at ita.chalmers.se] 
> Sent: Sunday, September 25, 2005 12:56 PM
> To: dev at projekt01.ch
> Cc: zope3-dev at zope.org; jim at zope.com; 'Stephan Richter'
> Subject: Re: Content provider API
> 
> 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/ComponentArchitect
> ure/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, ...)?

Yes

> 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?

I only like to define a API for call a component from the ZPT.
Right now we use for viewlets:

<metal:block tal:repeat="viewlet viewlets:tiks.regions.ICSS">
  <tal:block replace="structure viewlet" />
</metal:block>

This will invoke a IViewletManager implementation from the 
zope.app.viewlet package.

I guess we should define a different low level API where we 
can use in different concepts.

I guess something like this should work:
<metal:block tal:repeat="provider contentProviderFor:tiks.regions.ICSS">
  <tal:block replace="structure provider" />
</metal:block>

The TALES expression 'contentProviderFor' whould invoke a 
custom adapter providing IContentProvider for the defined 
region 'tiks.regions.ICSS'.

This IContentProvider adapter invokes CPSSKin components or 
viewlet components. This whould it make possible to implement 
additional concepts whitout to define how they look like. 

I mean only the integration API should be defined not a
portlet or viewlet API.


> Anyway, if the goal is to reuse portlets, viewlets, ... written for
> other applications inside cpsskins there are two options:

No, I don't mean this level. The level I talking about is to
standardize the lookup from a ZPT which will invoke a 
component where knows about the CPSSkin.

This is more a ZPT API for lookup additional HTML fragment.
Of corse this API should be used from CPSSkin or viewlets
or other implementations.

> 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.

I think every region can define it's own component where will lookup
it's 'provider' for additional content (html fragment).

> 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.

Cool

>   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.

Ok, that's cool, but don't forget there are other concepts where 
use regions.

I propose,

"Regions and their lookup are a concept on the ZPT level,
 implementations like CPSSkin or viewlets use this ZPT API" 

Let's say a region defines a area in a page template. This area
will lookup 'html fragment' and render them within the page template.

For the lookup of 'html fragment' in a region we need a component
how knows about to collect such 'html fragment'.

Can you agree if I say the region is defined in the page template 
and the lookup component is registred as a adapter for:

(context, request, view, region)  

This would make it possible to register lookup mechanism depending 
on the objects context, the view we are browsing and the region we are
accessing.

Can you agree if I say that this concept is a base concept of the 
page template and only used from CPSSkin and viewlets instead 
that CPSSkin and viewlet define their own lookup concept.

CPSSkin or viewlet will ues this API for interact in the right way 
in a ZPT.

Regards
Roger Ineichen

Projekt01 GmbH
www.projekt01.ch
_____________________________
END OF MESSAGE