[Zope-CMF] Composite Content

Kent Polk kent@goathill.org
Thu, 19 Apr 2001 16:23:13 -0500 (CDT)


seb bacon wrote:
> On this topic, I'm finding a big stumbling block is something which is
> probably quite simple: CMF Types only provide for rendering themselves
> through methods, but if they are to be part of a CompositeContainer,
> they must also know how to render themselves within a DTML Method.
> 
> Furthermore, CompositeComponents must render themselves in a manner
> dependent upon the action performed on the CompositeContainer.  If the
> container is being viewed with an Edit action, for example, its
> components must know how to display themselves accordingly.
> 
> I guess the best way is to add an extra action mapping for Types in
> the CompositeContainer properties, which maps an optional number of
> its actions to those of each Component, e.g.
> 
> Container      Component1    Component2
> view	       view	     view_foo
> edit	       edit_foo	     edit_foo
> 
> If I'm onto a Good Thing, I'm OK with implementing the mappings, I
> think, but I have no idea how to map actions to the way a component
> renders itself as part of a template: do I have to override __call__,
> or something?  Are there any pointers for this?
> 
> What does anyone else think?  I'm really tired and have to go home, so
> that may not have made any sense ;)

I've been struggling with this, in context of the CMF, also. As
I've mentioned before, most of my objects are meta-data containers
whose actual 'text' is a tabular query. In my case, a SQL method.
Now there are problems with CMF documents or Components being
folderish and containing SQL methods, etc and it really isn't
necessary in the first place. With normal Zope objects, objects
can acquire SQL methods, but there's a problem with CMF in that
respect, so I wrote a series of proxy objects which behave like a
SQL_connection. When the CMF (non-folderish) object is created,
the appropriate proxy object is located. <dtml-with Proxy> is used
to call the sql method in the context of the object's proxy. This
gets around some of the acquisition problems but I still need to
have specific code to render that object.

I was trying to get around the dtml-with using __of__ in the proxy
client so the renderer could be a little more controlled, but I
can't figure out how to constrain __of__ to just use the proxy when
the object itself doesn't have the appropriate attribute - like
acquistion does. __of__ calls the proxy on everything. Appears I'm
in over my head here.

Result is that I would still need to maintain Component-specific
dtml for rendering my objects when they become Components. My
Components could use proxy methods to control how to render themselves
instead of the component properties on a site-wide basis, but the
component properties is a more general mechanism.

I don't think __call_ would get you anywhere because you could only
have one method available - by calling the object itself, which I
don't think fits in with the skins concpt. __getattr__ might be
useful if you can figure out how to render the object by attempting
to call the object.method() itself, instead of a rendering method
contained in some other object. Sounds like __of__ is again what
you would have to use, but as I mentioned, I'm too dumb to figure
out how to constrain it. I suspect the fsdirectory/skins stuff is
close to being able to do this, but I'm lost.

----------

BTW, I've written a fairly generic table proxy/client product which
allows one to create a proxy, automatically or manually create sql
methods for it, then create a proxy client which lets you select
from a list of proxy items, select from a list of sql methods, then
read a csv file and load tabular data into the sql method after
validating the argument list against the column names in the csv
file. Probably not useful to anyone else :^) but is the basis for
how I'll load some of these tabular Components.