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 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

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. :)


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:

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.


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.


Zope3-dev mailing list

Reply via email to