Jochen,
At 19:02 Uhr +0100 12.09.2002, Tim Hicks wrote:
given, that your html fragments _really_ are the content and not part of the presentation (for example because you're working on a Site on "best practice HTML") and no other object types than the basic ones you're right, there's no document that fits.
I'm not working on a site on 'best practice HTML' ;-). I simply need to present many pages to viewers with a consistent look-and-feel.
Well, you should not do it that way, I guess. Given you have many similar pages you can probably identify common properties. Take those out and put them in object properties.
This seems like over-complexity for this case. It would make it far more complicated to use my java ttw html editing widget. I think I understand the idea of having properties on objects and building pages dynamically, it's just in this case, it seems that I only really want one property, and that consists of html content.
If you just want to do a basically static site but with a common look an feel, you could use PageTemplates. The common parts would be put into the mass of your pages with metal:macros. But the start of our discussion was to seperate template from content so we're not really getting anywhere here...
That's still what I'm talking about, it's just my content happens to already be html. I have no need or desire to break it down into separate properties on a folder for it to simply be reconstructed on rendering into the exact same form as it was generated in. In this project (and in many others I am/have been involved in), all I want is a content object that renders with a standard look-and-feel (i.e. a header and a footer), but that doesn't require explicitly embedding this look-and-feel code into the actual content (this is what I mean by separating template and content, in this case). Products such as StructuredDocument and HTMLDocument do this, but use dtml headers, whereas I want to use zpt for my templating. I think this is a common use case, and find it surprising that there isn't a built-in (to zope) solution for this.
The pages need only be available in html (as opposed to anything else like pdf, wml, or whatever), so I don't need to store XML or some other more data oriented format that must be converted to html. I also have access to rather a nice ttw java applet for editing this html content in a wysiwyg way. Storing html fragments (i.e. those that can't be abstracted out into the header/footer because they change from page to page) seems to be the way to go... but then I'm coming from the <dtml-var standard_html_header/footer> way of doing things.
Given this, do you have any other ideas for a setup?
If CMF was an option, that holds several content-types that would _exactly_ fit your need...
I don't have access to CMF on the production server.
Could you please explain what kind of a beast this Zope is that you will be using???
It's Zope 2.5.1 with BTreeFolder, HTMLDocument, PhotoFolder, ExtFile/ExtImage and ZUBB as additional products. I do not control the server, and cannot get any more products onto it. all the best, tim