[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