Ooops, I meant this to go to the list as well... Adrian...
----- Original Message ----- From: "Adrian Hungate" <[EMAIL PROTECTED]> To: "Ross Boylan" <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > Web: http://www.haqa.co.uk > > ----- Original Message ----- > From: "Ross Boylan" <[EMAIL PROTECTED]> > To: "Dieter Maurer" <[EMAIL PROTECTED]> > Cc: "Ross Boylan" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > 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 - [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 ) > > > _______________________________________________ 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 )