Ross Boylan writes:
 > ...
 > I would prefer a more elegant approach.  Perhaps I can define some
 > method in A that the dtml will reference, and then B can override the
 > method to add some extra stuff (the method would return a DTML
 > snippet).
That sounds good. It is how the ZMI works...

 > First, I'm not exactly sure how to pick up the method from the DTML.
There are two cases:

  *  view of an existing object
  
     then the object is the client of the primary view.
     Make all you snippets attributes of the object
     and you can simply access them by name.

     The ZMI does this. If necessary, look how it does.

  *  object creation form
  
     That's much more difficult. ZMI does not reuse fragments for
     this case.

     There is a partial solution for DTMLFiles, but it is not nice
     and restricted to DTML.

     "DTMLFile" constructors accept a dictionary with default
     name bindings. This way, you can customize your
     DTMLFile with different bindings according to context,
     e.g.

        addAForm= DTMLFile('dtml/addForm', globals(),
                           comp1= AComp1
                           comp2= AComp2
                           ...)
        addBForm= DTMLFile('dtml/addForm', globals(),
                           comp1= BComp1
                           comp2= BComp2
                           ...)

 > Second, I'm not sure if this is the best solution.  For one thing, I
 > would prefer to keep all my dtml in separate files, rather than
 > defining it into my methods.
You can have separate files and do something like:

    class YourProduct:
      ....
      mySnippet= DTMLFile('dtml/mySnippetFile',globals())
      ....


Dieter


_______________________________________________
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to