[Zope] My Way of Zope Programming
Jens Vagelpohl
jens@zope.com
Thu, 8 Aug 2002 08:39:20 -0400
> Look at the problem with the CMF. If you want to add a component it has
> to make it's own skin. And if you want the component to get a new look
> and feel you will have to change the skin.
you just have to provide views and python scripts for processing...
> The CMF is a gret big monolith that can get a new look and feel by
> rewriting the skins. But the amount of work associated with that scales
> like: n-skins * n-components. That is squared problem. Now you can talk
> about maintanance problem.
huh? i change main_template.pt and that changes my look and feel...
> The look and feel should generally be seperate from the components. Which
> they are not right now!
again, main_template.pt is separate from all those components. you just
have to use it from whatever views you need for the new component (like
its edit screens, view screens etc)
> You should be able to write a component following some interface
> specifications, and then you should be able to select a new skin from
> from a drop-down or pass a ?skin=someSkin in the url, and every component
> should be able to change their look without any further coding.
>
> As it is now with ZPT/dtml Zope will not be able to scale to an
> architecture where you just create plug'n play components that fits into
> a framework. And until then we will not see any major reuse of code.
we reuse a lot of CMF skins/code in our development work...
you are correct if your point is that it's still too hard to write new
content types for the CMF (meaning content types that require more than
just a copied-and-changed Type object in the types tool and some views).
but i don't think it's as bad as you make it out to be.
jens