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

[Jean-Marc Orliaguet]

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/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 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".
>
>
> It sounds quite cool. Do you have any understanding of how applicable  
> this may be for something like Plone? That is, an existing Zope 2  
> application that uses a structured set of templates (basically,  
> main_template has a main_slot that things like document_view will  
> fill in with content, and it includes a bunch of macros for the  
> various elements of the UI).
>

the architecture is quite different actually since it is a complete 
redesign of the template / macros machinery but without ZPTs ..

> Is it accessible in Z2/Five?
>
no idea, yet.

> Is it possible to re-use existing structures?
>
> Would it require a complete UI rewrite?
>
> Would it be possible to make products that use the "old" structure  
> (basically, call main_template and fill a "main" content slot in 95%  
> of the cases) still work?
>

The only thing that's left from page templates is the ability to display 
the content of the "main" macro slot used in the master template. In 
this way the main content area of existing applications can be 
preserved, but everything around it (boxes, navigation, images, actions) 
is replaced.

Best regards..
/JM