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.

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:

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

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.


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..
Zope3-dev mailing list

Reply via email to