Re:[Zope-CMF] Re: [Zope3-dev] Retaining ease of customisation

erik erik at mmmanager.org
Thu Nov 24 10:11:15 EST 2005


Hi,

<snip>

> Jean-Marc Orliaguet wrote:
> 
> Hi,
> 
> What I'm claiming is that is that TTW customization is valuable and that 
> Zope3 has to leverage this in a way or in another. What I question is 
> the idea of customizing "views". What CPSSkins does is that it allows 
> every resources to be customized TTW, but the view that does the final 
> composition is a standard filesystem view. This is why I'm saying that 
> Zope3 supports this already, provided you don't customize the view but 
> the resources used by the view. This may have been misleading to express 
> it that way, but the goals and the results are the same.
> 
> When looking at TTW possibilities I started with trying to emulate the 
> portal_skins filesystem directory view approach that is used in Zope2. 
> My conclusion was that only resources, or templates understood as 
> resources need to be customized, the actual view mechanism can stay on 
> the filesystem and it can call the resources instead.
> 
> can't just a view be created that calls resources (ZPT, etc)? why does 
> the entire view itself have to be customized TTW?

I'm just a tiny little bit confused here, what is a view and what is a resource - in Zope2 and in Zope3 ? ;-)

Maybe I just don't know enough about Zope3 (or 2), but to me what JM calls a view is a resource, and vice versa... anyway, I think it's a good idea to have the conceptual discussion now based on use cases, and here's my 2 cents. Hopefully someone can then explain what's what.

I'm playing around with Plone2.1 and CPSSkins at the moment. Plone has some very nice new features like LinguaPlone and the new extended content_actions bar (the bar containing the dropdown menus for workflow actions, cut/copy/paste, add content and manage translations etc.).

The page I would like to construct in CPSSkins has for the sake of argument only horizontal sections - no slots - and using todays Plone it looks like this:

-----------TOP SECTION---------------------
[logo]                                       [search box]
&acute;
BREADCRUMBS | USER+GLOBAL+SITE ACTIONS

-------OBJECT CONTROL SECTION-------------

[object / folder action tabs]

[content action menus bar]

---------MAIN SECTION-----------------------
[document title]                  [document action]

[document description]

[document body]

[content byline] [history thingy]

[discussions]

------------------------------------------------

(to me that's a "view", but correct me if I'm wrong)

Now, what I would like to do, is to split document actions and content bar, and move the elements around.

My problem today is, that the Plone content bar is heavily hard coded, and allthough I can insert it in a CPS slot templet, I can't control the styles used to render it through CPS's normal styling mechanism. And, I can only use the complete content bar or none of it, where I would like to exclude the cut/copy/paste-dropdown menu and put these back into folder contents.

The document actions, on the other hand, can be inserted in a slot templet by defining document_actions as the slot to included. But by doing this I can only display the actions in text, and not by their icons... 

What I would like to do, is to move the Language flags from the document "area" to the top right corner of my site and move the print-this-page and mail-this-page icon above the content bar.

But once again, I have to take it all or none, because allthough I can define a new action category in the ZMI (i.e. "new document actions"), and apply this new category to a selection of actions formerly categorized as document actions, and thereby splitting one "group" of actions into seceral action groups, this wont give me a template or a slot to can include and render in a CPS templet, like I have the document_actions script/macro that came with Plone. Yes, I can dig for this script and create a copy and rename it to my new category - but the amount of diging in Plone's myriads of skins and templates this would involve, makes the advantages og TTW editing almost obsulete, as I now have to be an experienced programmer anyhow, to know what to look for ;-)

To me the elements of the "content action bar" and the "document action slot", are resources that ideally should use a some sort of standard API for configuration, so that I could configure i.e. to present the actions by text or icons or both, but still use the Plonish logic, in a CPS templet. Somewhat similar to what I can do today by including an action category in an action templet in CPSSKins, but here I miss the LinguaPlone logic if I use the CPS language selector, and I really dont see any reason why CPS should need to build its own logic-module for the dropdown menus for the content actions, when the logic is allready done in Plone.

Oh - and then Plone's "isEditable" condiition should ofcorse be a condition I can apply to any of my templets, in the same manner as I today can apply an "if authorized" or "is anonymous" condition to control whether to display a templet or not in CPSSkins... also the "object/displayContentsTabs" condition springs to mind here... and there are probably more or there will be, so these conditions should be easy to integrate as extensions to CPSSkins' existing conditions.

So what I believe is missing is maybe a minimal framework that Plone could have used to produce the individual resources for each action presentation type, so that these resources could be used in their purest form out side of the very-hard-to-figure-out Plone GUI...  

Well, back to the resource/view debate; is what I'm talking about configureable "views of the resources", where the resources are the script generating i.e. the content action menus, and views beeing the templates that are rendered as templets composited in a CPSSkins page ?

Or have I understood just about nothing at all ? ;-)

In Zope3, which parts of the above mentioned views and resources corrosponds to Content, Factory, View and the Adapter ?

(I don't see any resources mentioned in the componentÁrchitechtureOverview at ZOpe.org...)

Kind regards,
Erik Lange


More information about the Zope-CMF mailing list