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 div, it'll be unmanageable. So there will always be some need for tinkering with templates. And the tinkerer type new/quickdirty 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 point-and-click way than
Re: [Zope3-dev] Retaining ease of customisation
Stephan Richter wrote: On Wednesday 23 November 2005 16:41, Martin Aspeli wrote: I think there needs to be a solution for making quick, preferably TTW customisation of UI templates. As Tres pointed out, this shouldn't add a performance overhead and lead to maintenance woes for those who know what they're doing. Ideally, the site admin should be able to switch this off. Or even, the view creator should have to turn it on (e.g. by using a ZCML directive that makes a template TTW customisable. Or something). I know this strays away from best practice, that people will slap in crazy python: statements in TAL etc. Having a way of dumping this stuff to real views would be good, even necessary. But I think ignoring these users because the approach that's most accessible to them doesn't fit with the purity of our framework will seem to them elitist, and it'll probably drive more people to ruby-on-rails, who sell themselves on how easy it is to get started. You should have a look at CPSSkins for Zope 3 (developed by the Z3ECM project). Regards, Stephan Hi Martin, Stefan! There's a lot of work going on just to solve these issues (TTW / filesystem, customization, creating settings, exporting resources to the filesystem, ..), but on an application level and not in the way you think. What is made customizable is not an entire template, but only the resources used by the template. Also the page composition is done entirely TTW. So the need for a template to create an manage entire sites disappears. see for instance: Unified model for managing application resources http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2005_11_10_unified-model-for The separation of concerns (the site manager manages filesystem and TTW resources, page designer manages pages, content author manages content , ...): http://www.z3lab.org/sections/front-page/design-features/editing-screens/ Using ZPT pages to create portlets through-the-web http://www.z3lab.org/sections/front-page/design-features/custom-portlet/ my impression is that if you want TTW editing you'll have to do it on an application level using what's available in the framework (utilities, ZPT, ...) Zope3 allows you to do this already and in a much cleaner way than with zope2.. Regards /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Retaining ease of customisation
Jean-Marc Orliaguet wrote: Stephan Richter wrote: On Wednesday 23 November 2005 16:41, Martin Aspeli wrote: I think there needs to be a solution for making quick, preferably TTW customisation of UI templates. [snip] You should have a look at CPSSkins for Zope 3 (developed by the Z3ECM project). [snip] my impression is that if you want TTW editing you'll have to do it on an application level using what's available in the framework (utilities, ZPT, ...) Zope3 allows you to do this already and in a much cleaner way than with zope2.. That's great! How to make this work in the context of a Zope 2/CMF setup, the one Martin is working in? Remember the legacy codebase here; it's not an option to throw it out just like that. The task of porting CPSSkins for Zope 3 into Plone seems a bit daunting at first. I'm sure there are bits and pieces that can perhaps be taken without the whole framework though. Where should people start to look? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Retaining ease of customisation
Martijn Faassen wrote: my impression is that if you want TTW editing you'll have to do it on an application level using what's available in the framework (utilities, ZPT, ...) Zope3 allows you to do this already and in a much cleaner way than with zope2.. That's great! How to make this work in the context of a Zope 2/CMF setup, the one Martin is working in? Remember the legacy codebase here; it's not an option to throw it out just like that. Hi, through Five I guess :-) I don't have the competence though or the exact vision on how to do it. What I'm doing though as a matter of philosophy is to stick as much as possible to standard Zope3 concepts (adapters, utilities, ZCML, event subscribers, views, ...), to make the backporting from zope3 to zope2 easier. The difficulty is to do the first plug into zope2, but then since the application make a *huge* abstraction of what's underneath it shouldn't make much of a difference if it's plone, cps, zope3. The zope2 version was already trivially ported between CMF, CPS2, CPS3, Plone1, Plone2, .. thanks to the abstraction. The task of porting CPSSkins for Zope 3 into Plone seems a bit daunting at first. I'm sure there are bits and pieces that can perhaps be taken without the whole framework though. Where should people start to look? Regards, Martijn It's very much a prototype right now which does a lots of things, but a lot of the work is still being done on a conceptual level. The best contribution right now is in term of use cases, design, separation of roles, workflows, use of resources (I'm not convinced about Martin's TTW approach to TTW views for instance), and in basic framework modules (such as exporting data from ZODB to the filesystem, etc.. such as fsync, or any CMFSetup type of IO function that would be shared between Zope2 and Zope3) 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
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
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: [Zope3-dev] Retaining ease of customisation
On Wednesday 23 November 2005 16:41, Martin Aspeli wrote: I think there needs to be a solution for making quick, preferably TTW customisation of UI templates. As Tres pointed out, this shouldn't add a performance overhead and lead to maintenance woes for those who know what they're doing. Ideally, the site admin should be able to switch this off. Or even, the view creator should have to turn it on (e.g. by using a ZCML directive that makes a template TTW customisable. Or something). I know this strays away from best practice, that people will slap in crazy python: statements in TAL etc. Having a way of dumping this stuff to real views would be good, even necessary. But I think ignoring these users because the approach that's most accessible to them doesn't fit with the purity of our framework will seem to them elitist, and it'll probably drive more people to ruby-on-rails, who sell themselves on how easy it is to get started. You should have a look at CPSSkins for Zope 3 (developed by the Z3ECM project). Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
