erik wrote:
Hi,
HI!
I'm just a tiny little bit confused here, what is a view and what is a resource
- in Zope2 and in Zope3 ? ;-)
there's a notion of resource already in Zope3 that encompasses: images,
files and templates
in cpsskins (zope3) the notion also encompasses more cpsskins-specific
objects such as styles, perspective, access keys, portlets, ...
resources are registered as utilities (and called settings to have
more meta-information about the resource)
in cpsskins (zope2) resources would be the palettes, styles and
images.
The idea is that a resource is used by the application in the way that
the application chooses to use them, but unlike a view it has no
specific view logic associated with it. A view in zope3 is linked to
some presentation logic, i.e. an object is being presented, viewed for
instance in a browser . So a view is noth a context (the object viewed)
+ a request (the user's context).
In zope2 a view would grossly correspond to a ZPT and some pythonscripts
related to a class, but there is no explicit view registration.
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.
yes, see above, others may have more details...
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.).
these would be achieved with a portlet (actions) and a widget (dropdown
menubar) in cpsskins.
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)
this would be called a page in cpsskins, but the idea is the same. The
information stored in the page is used to create the final view.
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.
this is because the Plone version of CPSSkins directly calls the Plone
template macro that draws the bar ... Since there's no separation
between style and widget, there's nothing to do except to edit the CSS
file by hand. The zope3 version of cpsskins separates:
- portlet
- widget
- style
but not the zope2 version. In the case of CPS3 this involved the
creation of a new product: CPSPortlets that only takes care of rendering
the portlet (semantically) with a given widget but not rendering the
portlet's style.
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...
[...]
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.
the idea is that you'd define:
- the actions to display and group them in a category (currently this
cannot be done TTW in zope3 ...)
then you'd put together:
- the action portlet (displaying the actions by category)
- the widget (horizontal drop down bar)
- the style to use (green, blue ...)
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
