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

[Tim Hicks]

Jochen,

thanks for your reply.  See response in line below.

> 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
> >
> >where 'render' is some sort of script that does something like
> >standard_template.__of__(content_object) and where view is an alias to
> >'standard_template'.
>
> 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.

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.

> This idea is abit difficult to grap at first and is quite different
> from what other AppServers do!
>
> Did you have a look at the Zope Book
> (http://www.zope.org/Documentation/Books/ZopeBook/current),
> especially the part on acquisition and ZPT already? You need to graps
> the idea of acquisition, first...

I have seen this (and while I don't claim to have read it all - or even
remembered all I've read), but I still seem to be coming up against this
issue of content.

> You would _not_ use a zpt as a content object! A ZPT is a template
> for viewing content. It holds placeholders where your content is put
> in. Your content would be stored in specialised objects that fit your
> needs for that. those objects hold the content usually in properties.

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.  This seems surprising
given that all I want to do is store html fragments and sandwich them with
standard headers and footers.  I would have thought this was a very common
use case.

> 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 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 :-(, and to some extent, similar
issues to what I had with just using Folders as content objects.  This still
seems like a better solution to me though, and may be what I do for now in
the knowledge that it should be fairly easy to produce a script to convert
this messy folder structure into something more coherent in the future.

> I guess the best way for you would be to create a ZClass. In it you
> can define the properties that make up your content and you can
> define the view- and edit-methods needed, even based on ZPT, but you
> probably need to learn some more things first ;-)

I'm stearing clear of ZClasses after getting my fingers slightly burnt and
reading other posts regarding them.  Even if that weren't the case, I can't
use custom products (be they zclass or python) in this project as I can't
get them onto the zope instance I must use :-(.

thanks again for your reply.

tim