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

Paul Winkler pw_lists@slinkp.com
Thu, 12 Sep 2002 12:53:40 -0700


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