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

[Tim Hicks]

> Hi Tim,
>
> given, that your html fragments _really_ are the content and not part
> of the presentation (for example because you're working on a Site on
> "best practice HTML") and no other object types than the basic ones
> you're right, there's no document that fits.

I'm not working on a site on 'best practice HTML' ;-).  I simply need to
present many pages to viewers with a consistent look-and-feel.  The pages
need only be available in html (as opposed to anything else like pdf, wml,
or whatever), so I don't need to store XML or some other more data oriented
format that must be converted to html.  I also have access to rather a nice
ttw java applet for editing this html content in a wysiwyg way.  Storing
html fragments (i.e. those that can't be abstracted out into the
header/footer because they change from page to page) seems to be the way to
go... but then I'm coming from the <dtml-var standard_html_header/footer>
way of doing things.

Given this, do you have any other ideas for a setup?

> If CMF was an option, that holds several content-types that would
> _exactly_ fit your need...

I don't have access to CMF on the production server.

> Doing a ZClass for what you need should not be too tricky, as it just
> should hold properties, no special functionality...

It's still not a runner.

> But nevertheless, from your original post I replied to, I still have
> the feeling you might not have the correct notion how some things in
> Zope work...

I'm sure you're right there, but could you elaborate so I might see how
others use zope?

cheers,

tim

> Jochen
>
> At 17:50 Uhr +0100 12.09.2002, Tim Hicks wrote:
> >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/E56D8933FDE6BDA
2
> >).  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
> >
> >
> >_______________________________________________
> >Zope maillist  -  Zope@zope.org
> >http://lists.zope.org/mailman/listinfo/zope
> >**   No cross posts or HTML encoding!  **
> >(Related lists -
> >  http://lists.zope.org/mailman/listinfo/zope-announce
> >  http://lists.zope.org/mailman/listinfo/zope-dev )
>