[Zope-dev] Nesting Forms

[Ross Boylan]

On Thu, Jul 18, 2002 at 08:41:02PM +0200, Dieter Maurer wrote:
> 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...

ZMI = Zope Management Interface (i.e., in the core app), or is this
something else?  At any rate, I'm not sure what you're referring to,
or where to look.

> 
>  > 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.

The problem isn't just accessing them, but combining them.  Say C is a
subclass of B is a subclass of A.  Each subclass has the entire user
interface of its base class (aka superclass) and some extra stuff.

Either each class implements its novel stuff with a unique name.  In
that case, I still have to make a separate dtml file for each,
referencing the appropriate names (though your suggestion below helps
on that).

Or each has the same name.  Then the problem is how to get the
subclasses method to return its unique stuff plus everything in its
base class.  For vanilla methods that's not a big deal, but if each is
a DTMLFile, I don't think it will work.  More about that at the very
bottom.

> 
>   *  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
> 			   ...)

This suggests one semi-refined strategy: the file defines the maximal
interface, and then parts of it are guarded by <dtml-if ... > tests on these
extra variables I pass in. I could even pass the class in, but I
suppose if I try to do issubclass(PassedInClass, MyApplicationClass)
in the dtml-if I will find that I lack security to access
PassedInClass, issubclass, or MyApplicationClass.


> 
>  > 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())
>       ....
> 

The problem comes if I stick the different interface segments in
different files, so A.dtml has the user interface for A and B.dtml has
just the added interface for B, a subclass of A.  But I want the user
interface for B to be the combination of the A and B parts.

> 
> Dieter
>