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
_______________________________________________
Zope3-dev mailing list
[email protected]
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
