Re: [Zope-CMF] Re: [Zope3-dev] Retaining ease of customisation
Martin Aspeli wrote: I think there are two cases: The first is the "tinkerer", who wants to customise primarily the template as easily as possible, preferably TTW. OK, I buy this. You want to be able to modify resources, try different options ... Then you might want to export them the filesystem. Absolutely. The "export" part is important, too. :) And the import too.. from the filesystem to the memory before you do the customization. Currently this is done via ZCML, but for resources this is not always optimal, so currently resources are imported using an xmlpickle. http://svn.z3lab.org/trac/z3lab/file/cpsskins/branches/jmo-perspectives/configuration/resources/metaconfigure.py The serious developer wants to customise/override the whole view. there I'm dubious. "Serious" developers would have a better time writing the code directly in python on the filesystem. I agree, totally. However, such developers may still want to re-use as much as possible of other people's work, e.g. by overriding only those parts of the UI they want to change. Most Plone skin products work this way, at least - provide a custom stylesheet, override a few templates that are included from main_template etc. OK, but I would count them as "serious site designers" not as serious developers. Doing site design shouldn't require so much developer knowledge (python, ZPT, ZCML, HTML...). Application design on the other hand requires that type of knowledge, but only for the application logic (not so much for the visual part). the pattern used in cpsskins which may also be useful in plone is to separate between "resources" and "settings": - resources are just objects in the ZODB that users can play with (customize, modify, ..) - settings embed resources and they are registered by site managers centrally. It means that get an "official" status resources can become settings, and settings can be used as resource factories. for instance a page designer may create a new style of box (a resource) and if the style is retained as the "default box style" for the site, the site designer will be able to take the resource and create a setting out of it and call it "the default box style". other users will be able to use the box style setting and create their own resource out of it, customize it, and so on. I think that you need to define in Plone what belongs to the application and what belongs to the user. the approach in cpsskins is to write the UI components (portlets, widgets) on the filesystem and to combine them through the web. I don't see the point in having a 100% TTW approach. Some of the components need only be written (dropdown menus, boxes, ..). and they should not be changed afterwards "Should" is relative, though. I totally agree that the "composition" use case is strong, probably much stronger. But the question is, how small are your components? And how hard is it to provide new ones? Like Erik said, he wants to customise what's inside global_contentmenu. We didn't make that piece small enough for him to customise without writing some code. And of course, if we end up with one .pt for each , it'll be unmanageable. So there will always be some need for tinkering with templates. And the "tinkerer" type new/quick&dirty developer wants to be able to do that without having to learn an obscure and complex stack. this is covered, I'm going to start writing the tutorial part for how to create new widgets next week and add it to: http://www.medic.chalmers.se/~jmo/Zope3/ecm/cpsskins/README.html It is fairly easy to write new widgets, this is done in python, the only difficulty is how to manage everything around it (registration, combination of portlets and widgets ..) http://svn.z3lab.org/trac/z3lab/file/cpsskins/branches/jmo-perspectives/engines/default/filters/widget/widgets.py however there is a use case which is not currently covered: it's the ability to write the "control" part of the MVC trough the web. but again you can also customize parts of the view (e.g. scripts) in the same way as you'd customize the template You still don't have to customize the entire view. Indeed. I think this is probably covered by existing technology (not that I know enough about it to be totally sure of all the implications). It's the "tinkerer" group I'm trying to speak up for, because frankly they don't read these lists, but they are a very important influx into our communities, and we need not to drive them away. absolutely To be honest, I haven't played with it sufficiently to know all its capabilities, but it seems likely that unless you can edit every bit of every part of the UI, right down to each tag, and changing logic (e.g. when to display a particular part) as well as presentation, someone will come up with some use case they desperately need. this is covered already and in a more flexible and po
Re: [Zope-CMF] Re: [Zope3-dev] Retaining ease of customisation
Martin Aspeli wrote: On 24 Nov 2005, at 18:53, Jean-Marc Orliaguet wrote: Martin Aspeli wrote: A lot of people go with Plone initially based strongly on how easy it is to customise and re-use elements of the UI. I really don't want to take that incentive away from them. Yet, as I understand, if global_contentmenu.pt was implemented as a View, they couldn't customise it TTW and it would be more difficult (in fact, in my journey through the Five and some of the Z3 documentation, I've yet to discover how) to override this even if they were prepared to set up a bunch of directories and XML files. then you wouldn't customize the view, you would customize the *template* used by the view.. Martin, this is why I'm asking: are you sure you want to customize the entire *view* TTW or just the resources used by the view? I think there are two cases: The first is the "tinkerer", who wants to customise primarily the template as easily as possible, preferably TTW. OK, I buy this. You want to be able to modify resources, try different options ... Then you might want to export them the filesystem. The serious developer wants to customise/override the whole view. there I'm dubious. "Serious" developers would have a better time writing the code directly in python on the filesystem. the approach in cpsskins is to write the UI components (portlets, widgets) on the filesystem and to combine them through the web. I don't see the point in having a 100% TTW approach. Some of the components need only be written (dropdown menus, boxes, ..). and they should not be changed afterwards however there is a use case which is not currently covered: it's the ability to write the "control" part of the MVC trough the web. but again you can also customize parts of the view (e.g. scripts) in the same way as you'd customize the template You still don't have to customize the entire view. I think both groups are equally important, though. Even though overriding the template may mean people put random python: expressions and make a mess, this is an important way of letting people tinker, learn, explore and ultimately commit to the platform. So, whilst CPSSkins probably is a long term better solution for many of the original use cases, it's unlikely to form a core part of the Plone UI in the near future, and indeed unlikely to be appropriate for every type of application. which use cases? To be honest, I haven't played with it sufficiently to know all its capabilities, but it seems likely that unless you can edit every bit of every part of the UI, right down to each tag, and changing logic (e.g. when to display a particular part) as well as presentation, someone will come up with some use case they desperately need. this is covered already and in a more flexible and point-and-click way than it is currently done with page templates... the page template approach gives a *feeling* a control. what you call "changing logic (e.g. when to display a particular part)" is done through "perspectives", what you call "editing of every part of the UI right down to each tag" is called "creating a widget". In the interest of evolution, I'd like to find out how to make it as easy as possible for people to override templates that are parts of views. Unfortunately I'm still lost. :) Martin Then see my previous post that explains how to customize "templates that are part of views", replacing the word "template" with "resources" ... Okay, I didn't follow that completely, but I'll try to take another look. Is this CPSSkins-dependent, though, or is it generic Z3 mechanism you were describing? the principle is independent of cpsskins (works in zope3 using utilities), and implemented for cpsskins using a resource manager to be able to write: resources = IResourceManager(setting) resources.customize(name=name, context=context) instead of writing 10 lignes of code each time here are a few pointers if you want to get the background discussion: - http://comments.gmane.org/gmane.comp.web.zope.zope3.ecm.general/466 - http://permalink.gmane.org/gmane.comp.web.zope.zope3.ecm.general/488 - http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2005_11_10_unified-model-for Specifically, I want to be able to customise a template bound to a view in Five in Plone right now. Of course, I'm also interested in the longer term view, in how this fits into Zope 3, and in better ways of doing things than what may be immediately available. Martin sure, this requires a bit of a setup but this is feasible... you need to register templates as utilities and convert them to local utilities in order to customize them. regards /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-CMF] Re: [Zope3-dev] Retaining ease of customisation
Martin Aspeli wrote: A lot of people go with Plone initially based strongly on how easy it is to customise and re-use elements of the UI. I really don't want to take that incentive away from them. Yet, as I understand, if global_contentmenu.pt was implemented as a View, they couldn't customise it TTW and it would be more difficult (in fact, in my journey through the Five and some of the Z3 documentation, I've yet to discover how) to override this even if they were prepared to set up a bunch of directories and XML files. then you wouldn't customize the view, you would customize the *template* used by the view.. Martin, this is why I'm asking: are you sure you want to customize the entire *view* TTW or just the resources used by the view? So, whilst CPSSkins probably is a long term better solution for many of the original use cases, it's unlikely to form a core part of the Plone UI in the near future, and indeed unlikely to be appropriate for every type of application. which use cases? In the interest of evolution, I'd like to find out how to make it as easy as possible for people to override templates that are parts of views. Unfortunately I'm still lost. :) Martin Then see my previous post that explains how to customize "templates that are part of views", replacing the word "template" with "resources" ... cheers /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-CMF] Re: [Zope3-dev] Retaining ease of customisation
> 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.). I agree that CPSSkins is a nice solution, and may well become more prevalent in Plone, but as you've discovered, even this won't afford total flexibility in defining exactly what you want. What I'm worried about is this: People, myself included, come to Plone (probably the same story for CPS etc.) and see that it does 80% of what they want. Then they customise the CSS and that gets them to 90%. For the last 10%. They add some templates, 95%, and then they realise that they'll have to change some of Plone's markup in a way that isn't readily customisable. The thing that makes Zope as a platform so attractive, is that they can very easily say, "global_contentmenu.pt is where the menu is" (okay, so finding that is harder than it should be, but once they know...) and they can override that bit of ZPT in a new skin layer in portal_skins. They can do this very easily with portal_skins/custom TTW. A lot of people go with Plone initially based strongly on how easy it is to customise and re-use elements of the UI. I really don't want to take that incentive away from them. Yet, as I understand, if global_contentmenu.pt was implemented as a View, they couldn't customise it TTW and it would be more difficult (in fact, in my journey through the Five and some of the Z3 documentation, I've yet to discover how) to override this even if they were prepared to set up a bunch of directories and XML files. So, whilst CPSSkins probably is a long term better solution for many of the original use cases, it's unlikely to form a core part of the Plone UI in the near future, and indeed unlikely to be appropriate for every type of application. In the interest of evolution, I'd like to find out how to make it as easy as possible for people to override templates that are parts of views. Unfortunately I'm still lost. :) Martin ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope-CMF] Re: [Zope3-dev] Retaining ease of customisation
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] ยด 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
