[Zope-CMF] Hmmm... problems with dependencies ...

alan runyan alan runyan" <runyaga@runyaga.com
Sun, 7 Apr 2002 23:47:40 -0500

comments below

>  File
> line 39, in call_object
>     (Object: index_html)
>   File
> line 127, in __call__
>     (Object: index_html)
>   File
ng.py, line 473, in __call__
>     (Object: index_html)
>   File
> line 76, in render
>     (Object: folder_url=absolute_url)
>   File
> line 695, in renderwob
>     (Object: objectValues( [ 'Folder', 'Portal Folder' ] ))
> KeyError: Id
> which stikes me as a dependency error.  The DTML index_html invokes stuff
> apparently defaults to templates rather than the equivalent DHTML.  What
to do?
> Is there an easy way to discover the dependencies?

this is one of hte problems w/ DTML ;(  its hard to see what is being
called.  its all looks like one big namespace.  dont know if this would
help, but here is a CMF checkin:

> I would prefer to maintain the option of building a mixed site, some pages
> with templates, some with DTML, yet others with python scripts and
external procedures.
> The skin mechanism and the associated defaulting seems to get in the way
of this.
> Is there any reasonable way to accomplish this?  For example, how do I
keep the
> same basic layout and skin when some pages are rendered using templates
> others using DTML?

ah.  this means you want standard_html_header/footer to use your
main_template (elements).
Plone tries this.  you can look at CMFPlone/skins/plone_templates and look
at the standard_html_xxxxxx

> Is there a way to use the templates mechanism to create DTML?

I'm not quite sure what that means?  you want to render DTML inside a
Maybe, http://www.zopelabs.com/cookbook/1015014229  ?

> Finally, one more question.  Much of the CMF functionality is buried in
> tools layer.  To change the functionality, I have to modify the tools.
Are the
> interfaces and API specified somewhere?  What's the recommended way to
make such
> changes so that my system can track the CMF development?

Subclass the desired tool and override methods and/or add new methods.  Then
delete the old tool and creat a new instance of your custom tool.  As long
as you dont modify the source of CMF Products, you should be fine.  Unless
there is a CMF API change.  Then its usually pretty obvious what is going
wrong.  As well you will hear lots of attention grabing headlines on the cmf
mailing list.