[Zope3-dev] Zope 3 Web Content Management

[Max M]

Janko Hauser wrote:

> But the structure you declare in your skin mechanism will not solve all 
> the different design needs different customers have. Nesting should not 
> be allowed?

No! if you have a mehod called emp() it should not be nested with other 
methods. The code that emp() generates can easily generate nested markup 
though.

def emp(content):
     return '<font size="-1" face="verdana"><i><emp>%s</emp></i></font>' 
% content

etc.


> I do not like the approach to introduce another programmatic layer for 
> the generation of layout. PageTemplates are useful to generate views for 
> the components.


Perhaps Pagetemplates can be used to implement the ideas. It isn't 
mutually exclusive.

> In a CMS are at least three different areas of Layout. First there is 
> the layout of the content-objects. Here we have found it is important to 
> connect different layouts to objects of the same content-type. For 
> example we have articles with pictures, without, one or two columns, etc.
> This can be changed during the lifetime of an object. With modern 
> WYSIWIG approaches it's perhaps possible to neglect the next area of 
> layout, namely the input of content in the different content-areas of an 
> actual document. We call it mask in contrast to the template, which 
> presents the content.


But this is exactly the problem. It should not be nessecary to change 
anything with wisywig tools. Ideally we should have a system that can be 
skinned just like KDE & Gnome. Those implementing a site should not have 
to change layout themself. They should be able to select from a list of 
possible skins.

And those implementing products should not have to think about the look 
of the site.


> Then there are functional documents, which are placed as objects in the 
> tree, like news-listing, contact-formulars, subscription forms, they 
> also need to be editable, so there does also need to be a way to input 
> information. Here the template is directly connected to the content object.


And that could also be done with the methods in my skinning rant.

> Then there is a hole slew of managment screens for other site functions, 
> here we are touching the old Z2 problem, that it needs a big amount of 
> dirty work to change these screens. This looks much better in Z3 with 
> the help of the zcml-files.


The Zopetop should ideally be able to take on the skin that the site is 
using.


> So what I see, that before we discuss the actual implementation of a 
> template system, we need to define a way, how views can be connected to 
> objects. The current way in Z3 is path based, but this will probably not 
> work for a CMS, as the knowledge of the view needs to be present in the 
> content-object, at least for pure layouts.


I don't understand what you mean...

> Related to this is the question, where are the skins/templates? I like 
> the staging approach of the CMF, first different layouts in the 
> filesystem, handled like code, maintained as one basic package. Then the 
> possibility to refine the layout for actual uses and have this in the 
> ZODB. I haven't used the CMF a lot, so I'm not sure, if this approach 
> scales.


 From browsing the code it seems to me that the cmf have this big 
massive block of intertangled layout/skins and if you want to add 
another component to the cmf you have to create custom views for it, 
giving it it's own stylesheets etc. This does not scale well at all.

My suggestion is that if we really want 10x usage of Zope we need to 
make it possible to skin products on a global level using a solid api. 
Or else we will simply have this situation where there will be big 
implementation issues every time a new product is added to the system.

If you have to change the skin because a new product is added you are 
doing it wrong!

If you have to change your product when a new skin is used you are doing 
it wrong!

If KDE or Gnome worked Zope does now, they would have to write a new 
skin every time a new application was written for them ...


regards Max M

the Law of Inverse Squares. With sound, for example, a source twice as
far away from the detector (an ear?) provides just one-quarter of the
strength of signal. ESP has been said to show no fall-off at all, let
alone any diminution of strength. Well, we must admit that zero signal
won't show any change...