Paul,
You've done a pretty good job of ruling out all your options. ;-)
I was starting to realise that ;-). I think I was hoping someone was going to come in and tell me something obvious that fixed all my problems :-).
/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.
This got me thinking. "I can get the right one just by calling a URL that acquires the appropriate view." - by this I presume you mean you have your two views (say 'view1' and 'view2') as objects at the root of your site, but you still must append /viewX to the url to get the appropriate one. I'm not mad keen on forcing the /viewX to be appended because, while navigational links are constructed automatically, (naive) users will be editing content and embedding links into it. Then, I have the twin problem of getting them to remember to append /view on all their links, and hard-coded links in this format making it difficult to change. But!! I thought, how's about I force the view further up in the url. So, while my structure is actually /site/foo/bar.html, my url would look like /site/new/foo/bar.html. 'new' is a python script that traps the traverse_subpath and does the following: ---- import string physPath = list(context.getPhysicalPath()) path = string.join(physPath+traverse_subpath, '/') + '/content_template' ob = container.restrictedTraverse(path) print ob(context, context.REQUEST) return printed ---- Just in case the url in the browser stops on a folder and not a file, I've added a script in /site called 'document_src' looking like: ---- return context['index_html'].document_src() ---- I've verified that this works, although I haven't tested with things like images etc (although I'm sure I could make the 'new' script flexible enough to deal with whatever I need for this site). I'm just not sure if there are any security, performance or any other issues with such a setup. It does seem slightly convoluted to me. Do you (or anybody else) have any views on this?
With all that said, I think you might reconsider your objections to using Folders:
<snipped lots of interesting Folder chat> Ok, you've partially brought me round to the benefits of folders ;-). My choice now appears to be between the system outlined above, and 'folders man' ;-). Any comments on relative merits would be greatly appreciated. Thanks very much for your post, it was really useful. And yes, I know, I've got to stop moaning at some point and actually do something ;-). cheers, tim