Fw: [Zope-dev] Nesting Forms
Adrian Hungate
adrian@haqa.co.uk
Fri, 19 Jul 2002 11:06:35 +0100
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 )
> >
>