[Zope] overriding __str__ method?

Dieter Maurer dieter@handshake.de
Tue, 10 Oct 2000 10:55:17 +0200 (CEST)


Seb Bacon writes:
 > I know how to create a form that does what I want (update properties,
 > whatever).  What I don't know is how to include it as part of the rendered
 > content programmatically.  At the moment users have to go to
 > www.widgets.com/manage_content, log in, and see a set of forms loosely based
 > on the Zope manage interface.  Instead, I'd like them to go to the same url,
 > and see exactly the same website as someone who's not logged in, except they
 > have these lovely little "edit this" buttons next to each editable content
 > element (by which I mean image, text snippet, etc).
 > 
 > Now I *could* do a
 > 
 >   <dtml-if "AUTHENTICATED_USER.has_role('content manager')">
 >     <a href="edit_this">edit this</a>
 >   </dtml-if>
 > 
 > in each content element. But I'd much rather be able to subclass or mixin an
 > 'editable' class for each content element in question.  The question is,
 > what methods should I be providing to manipulate how the content is
 > rendered?  For example, I can provide a new 'view' method in the 'views' tab
 > for a ZClass, but this does not get called when an object is rendered as
 > part of another document.  The reason I was going on about __str__ is
 > because that seems to be the only place that you can interfere with how the
 > content is rendered inline?
 > 
 > Hope that's clearer,
I now do understand it better. Though, I have to admit that others
understand you first problem statement better than I did.

DTML renders an object by 
  1. looking it up
  2. calling it, if it is callable
  3. stringifying the result by calling "str"

Thus, for callable objects, changing the "__str__" will not help.
For callable objects, "__call__" would need to be modified.

However, I would strongly discourage to make such a drastic change
to Zope objects:

 * a modification of "__call__" would not only affect rendering
   but also other use of objects (e.g. if DTML methods
   are used to validation and should return "0" or "1".

 * the pages could be littered with "edit me" buttons.
   It is (in general) not easy for your content manager
   to determine the object boundary which the "edit me"
   applies to.

 * we use DTML objects sometimes to factor out common
   "object"s such as e.g. the option list for HTML <select>
   tags. Automatically adding "edit me" would produce
   invalid HTML.

I would rather suggest, you develop some method (or product), say
"content_render", that can render an object (emulation the
normal DTML rendering process) and can add whatever is necessary
to facilitate management (e.g. visualizing object boundaries,
placing "edit me").
Rather than

	<dtml-var xxx>

you would then use

	<dtml-var "content_render(xxx,_)">

at places where the result would be usefull and legal (e.g. not inside a
"select" tag).


Have you looked at the PTK?
You will find there some of your idea realized. However in a
simplified form: a document contains a single "edit me" integrated
to allow the owner to edit his content.


Dieter