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

[Jochen Haeberle]

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.

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

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

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...

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/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
>
>
>_______________________________________________
>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 )