[Zope] zpt, metal and missing content objects (bit long)

[Paul Winkler]

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!"