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 )