Ooops, I meant this to go to the list as well... Adrian... ----- Original Message ----- From: "Adrian Hungate" <adrian@haqa.co.uk> To: "Ross Boylan" <RossBoylan@stanfordalumni.org> Sent: Friday, July 19, 2002 8:40 AM Subject: Re: [Zope-dev] Nesting Forms
Although I would probably avoid what you are trying to do, it doesn't seem that hard. Here is how I would do it (Which I think is just an extension of the other sugestions here).
Have one base class which contains (For example class _base) * a method to produce an empty, or almost empty, page - All classes will override this. * a DTML Method which contains "header", "form start", a call to the method above, "form buttons", "form end", "footer". No classes will override this.
Then each desendant class would work something like (e.g. class A(_base) ) * Override the method, get the HTML returned by _base.method() and add your new HTML to it. * Do not override the DTML Method....
All descendants of A could do the same by adding their own HTML onto the end of A.method() etc...
This should work (And could be repeated for as many screens as there are in the product), because the <head></head>, <body></body> and <form></form> elements are NOT part of the HTML returned by the base class method, so the ordering should be correct.
Of course, you will need to do the same with the form handler functions, but that is basic python, and all products do that without thinking.
I hope this is clearer to you than it is to me now I am re-reading it. :)
Adrian...
-- Adrian Hungate EMail: adrian@haqa.co.uk Web: http://www.haqa.co.uk
----- Original Message ----- From: "Ross Boylan" <RossBoylan@stanfordalumni.org> To: "Dieter Maurer" <dieter@handshake.de> Cc: "Ross Boylan" <RossBoylan@stanfordalumni.org>; <zope-dev@zope.org> Sent: Friday, July 19, 2002 6:38 AM Subject: Re: [Zope-dev] Nesting Forms
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
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )