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

[Tim Hicks]

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