Hi Tim, 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. If CMF was an option, that holds several content-types that would _exactly_ fit your need... Doing a ZClass for what you need should not be too tricky, as it just should hold properties, no special functionality... But nevertheless, from your original post I replied to, I still have the feeling you might not have the correct notion how some things in Zope work... Jochen At 17:50 Uhr +0100 12.09.2002, Tim Hicks wrote:
Jochen,
thanks for your reply. See response in line below.
At 15:23 Uhr +0100 12.09.2002, Tim Hicks wrote:
So, with that little issue overcome, I guess the only thing I'm left wondering is why my content objects need to contain any explicit use of zpt *within their source* (as opposed to as a property on the object). Using only standard zope objects, the only ways I can see of overcoming this require nasty url mangling that locks me into a specific site system (due to embedded links). By this I mean, if I want to have a zpt called as a method of my object when it's rendered, I could do one of:
/render?id=content_object /content_object/view
where 'render' is some sort of script that does something like standard_template.__of__(content_object) and where view is an alias to 'standard_template'.
No, you don't need such things. All objects in Zope, that need this, have their own view method... folderish objects on the other hand, look for an index_html for default. This way you can achieve the rendering of an object (a folder is an object, too) using the given template.
I know what you are saying here. 'All objects in Zope, that need this, have their own view method' - well, I want to be able to define the view method, but I don't think I can without one of the two schemes I detailed above.
This idea is abit difficult to grap at first and is quite different from what other AppServers do!
Did you have a look at the Zope Book (http://www.zope.org/Documentation/Books/ZopeBook/current), especially the part on acquisition and ZPT already? You need to graps the idea of acquisition, first...
I have seen this (and while I don't claim to have read it all - or even remembered all I've read), but I still seem to be coming up against this issue of content.
You would _not_ use a zpt as a content object! A ZPT is a template for viewing content. It holds placeholders where your content is put in. Your content would be stored in specialised objects that fit your needs for that. those objects hold the content usually in properties.
I think we agree here, ZPT is _not_ a content object. It seems to be a very good way of templating actual content objects. My problem is apparently a lack of a 'specialised object' that fits my needs. This seems surprising given that all I want to do is store html fragments and sandwich them with standard headers and footers. I would have thought this was a very common use case.
You are right, there is no Basic-Zope object besides fodler that work this way :-( But you can experiment further with more objects.
I realise that Folders could be used, but this is fairly unattractive to me as it would make a bit of a mess of the ZMI tree, seem rather unintuitive to naive users ("how can the page be a folder?") and because they do not provide the sort of easy TTW editing interface that DTML Documents / ZPTs and the like have in the ZMI.
I have experimented with other objects (both standard zope and third party - including my own). Given my current requirements are for an object from the base zope install (which is looking increasingly unlikely to fit with what I want), the best I could find was the 'File' object. For plain text under 64KB (I think), they provide nice textarea editing (well, as nice as that can be ;-) ) in the zmi. Evan Simpson posted a method whereby I could use a mixture of 'Folders' and 'Files' to get around my default view method problem (http://zope.nipltd.com/public/lists/zope-archive.nsf/ByKey/E56D8933FDE6BDA2 ). This would work, but seems like a hack to me and leaves me with a folder and a file for every logical content object :-(, and to some extent, similar issues to what I had with just using Folders as content objects. This still seems like a better solution to me though, and may be what I do for now in the knowledge that it should be fairly easy to produce a script to convert this messy folder structure into something more coherent in the future.
I guess the best way for you would be to create a ZClass. In it you can define the properties that make up your content and you can define the view- and edit-methods needed, even based on ZPT, but you probably need to learn some more things first ;-)
I'm stearing clear of ZClasses after getting my fingers slightly burnt and reading other posts regarding them. Even if that weren't the case, I can't use custom products (be they zclass or python) in this project as I can't get them onto the zope instance I must use :-(.
thanks again for your reply.
tim
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )