Tim, You've done a pretty good job of ruling out all your options. ;-) Comments inline... On Thu, Sep 12, 2002 at 05:50:23PM +0100, Tim Hicks wrote:
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
The former, IMHO, is really ugly and will only get worse as your site gets more complex. I've done the latter in a recent case that involved putting the same content object (a custom Product) into two different views in different places, when I didn't have the luxury of building the context from the ground up but had to fit the views into two very different existing template systems. So I just created two different "view" methods, and I can get the right one just by calling a URL that acquires the appropriate view. I'm not too worried about "locking into a specific site system", because all the URLs that do this are automatically generated in a few navigation methods, so I can just modify those if need be. With all that said, I think you might reconsider your objections to using Folders:
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.
So: topfolder/+-index_html | +-subfolder1/+-content | +-subfolder2/+-content Then index_html can be something like: <html> <head><title tal:content="here/title"> or maybe you want template/title? </title></head> <body> <div tal:replace="here/content | nothing"> content goes here </div> </body> </html>
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.
Yes you can: either use custom products, which you say are off-limits for this project, or use index_html on folders.
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.
I'm telling you man, folders... :)
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 understand these objections, but think you've exhausted the alternatives that don't involve creating or installing products, and IMHO folders are probably the best approach. I can relate, I've faced similar issues; but sooner or later you'll have to stop painting yourself into a corner and pick one of these solutions.
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 :-(
True, but here we go again - there is no standard zope object that does what you want. And it'll seem less strange if your requirements expand such that other elements of the presentation may change, or the content wants to be in more than one file. Example: topfolder/+-index_html +-navigation_bar +-image1.gif | +-subfolder1/+-content | +-subfolder2/+-content | +-image1.gif | +-subfolder3/+-content +-navigation_bar We've still got one master template, but we've got localized changes: if we view subfolder2, we get a different image; if we view subfolder3, we get a different navigation bar. As sites get more complex, it gets really nice to be able to break these things out from index_html and structure both your presentation and your content more logically. -- Paul Winkler "Welcome to Muppet Labs, where the future is made - today!"