Lennart Regebro wrote at 2004-4-23 10:57 +0200:
>From: "Dieter Maurer" <[EMAIL PROTECTED]>
>> I do not believe you.
>But I believe him. :-)
>If Zope has a steep lurning curve, that's nothing compared with CMF.
Usually, I am able to explain CMF to my colleagues in something
like a few hours (I do this occasionally for different teams).
>portal_skins are a fundamentally flawed idea and has the tendency to move
>logic out from the products into the skins, instead of facilitating a
>separation between logic and design.
It is one of our favorite tools...
It provides a flexible way to contruct a namespace (badly termed "skin") from
components ("layers"). This is very useful, whenever
you need several namespaces which large common parts but various
small differences. We use it to describe hierarchies similar
to an inheritance hierarchy:
ShopPortals/ # overrides (or adds) things special for "ShopPortals"
ShopPortal1 # overrides (or adds) things special for "ShopPortal1"
It makes it very easy to add new portal grous or new individual
We will soon use it as a main component for a production environment
to produce many related products (they are described by
a similar hierarchical structure).
Logic, too, can make use of the flexibility provided by the "SkinsTool"
The production system mentioned above will use the "SkinsTool"
for logic only.
>Other evidence that the thinking is
>wrong is that skins are stored on disk, but through some clever predenting
>on Zopes part they look like they are in the ZODB. This shows that somebody
>has been thinking backwards. :-)
You look at this in a funny way -- in the sense that I see it
That Zope can use the objects in the file system, they must
be mapped to Python objects. As the mapping is non-trivial,
it is very helpful that you can check the result via
What the "DirectoryView" does here, is similar to what "LocalFS"
does -- and it is very senseful...
>The skins that come with CMF are incomprehensible, and stopped me from using
>CMF before I was forced to (something which is solved by using Plone or CPS,
>but that's not obvious first of all, and secondly, none of them were
>available when I started looking at CMF).
Here, you blur the distinction between "CMFCore" and "CMFDefault".
"CMFDefault" is nothing more than an example for "CMFCore"
(in my view).
While we use "CMFCore" very successfully and very profitably,
we do not use "CMFDefault" at all (other than as some example code).
>And the member management is a complete mess with gazillion tools involved.
This provides for a great deal of modularity...
>A lot of the things that are CMF should have been put into Zope core.
We consider "CMFCore" (and "DCWorkflow") as part of the "Zope core".
Nothing prevents you to do the same...
>acl_user folder should have been extended
>with property management and other member management instead of shimming
>tools and wrapping user objects as is done now.
When CMF was designed there were already several dozens of
UserFolders around. It is not too bad an idea to use existing
components and wrap them with new functionality...
>And even if portal_skins
>would have been included, they should have been empty of skins, instead of
>sending with a bunch of skins that makes CMF look like it almost is a
>finished product, when in fact, it just a bunch of handy tools.
Disregard "CMFDefault" (when you like) and just use "CMFCore"
as a bunch of handy tools. In fact, this was the main purpose.
Again: "CMFDefault" was considered as an example how to use
the framework "CMFCore".
>But ah well, what is done is done. Too late to change the past now. :-0
There is no need to change the past.
You can start using "CMFCore" profitable in the future :-)
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -