On Thu, Sep 12, 2002 at 09:56:56PM +0100, Tim Hicks wrote:
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 :-).
Me too, secretly :)
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.
Close, but it's not view1 and view2, it's just view. I've got something like: /site1/view /site2/view /shared/ (content objects go here) To view a content object foo, a proper URL would be /site1/shared/foo/view or /site2/shared/foo/view This way, I get a different view of the same content, depending on the context; and the URLs are identical except for the leading context, which makes managing the navigation code easier. Yes, it's annoying to have /view on the end of everything, but /site1 and /site2 were built before I got here and my requirements were "get this shared content to fit into the presentation of both these sites, ASAP."
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.
Yeah, that is annoying.
But!! I thought, how's about I force the view further up in the url.
(snip)
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?
Security? No idea. Performance? Considering the amount of acquisition magic that happens on a typical zope site, probably not a worry. Convoluted? A bit. I'd want to test this really, really thoroughly before going live with it. Acquisition is hard enough to understand without customizing it. :-/
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.
The folders approach doesn't do any magic that's not standard zope, so it's easier to be sure it works. OTOH, I understand the interface concerns. It's really too bad you can't add custom products; that would let you do exactly what you want. I would recommend zclasses, except that I won't touch zclasses. :-} I've made my folderish objects easier to work with by presenting a custom interface, which is a lot more luser-proof (he said as he contemplated writing a script to rename a couple hundred images with spaces in their IDs). --PW Paul Winkler "Welcome to Muppet Labs, where the future is made - today!"