[Zope3-dev] Re: RFC II: pre-creation view solution [was Re: [Zope3-dev] RFC: preCreation view, postCreation view use cases]

[Gary Poster]

From: "Stephan Richter" <srichter@cbu.edu>
> At 01:45 PM 4/2/2002 -0500, Gary Poster wrote:
> >On Thursday 28 March 2002 10:17 am, Guido van Rossum wrote:
> > > I'm curious how you can provide a
> > > general framework for this feature -- maybe a look at the jobboard
> > > example (checked in as Packages/JobBoardEx on cvs.zope.org) would help
> > > you.
> >
> >OK: I've built one.
>
> +1; this is a really cool thing. BTW, you might want to consider joining
us
> on the #zope3-dev IRC channel, since responses can be faster.

Cool. :-)  I would IRC, but I'm in and out for the afternoon. :-( I'll drop
by really quick for a sec if I have time

> Oh, I just ran your example (not the JobBoard) and it is cool. I love it!
> BTW, where does it store the data during the Wizard process; in a
MomentoBag?

There is no need to store data in this example: the creation view appears
from nothing but the Addable (to let the default view work).  If you wanted
to create a multi-page wizard *now* you could do the old hack of storing the
data in hidden fields on the form and *later* when we presumably have
session objects you could use them.  You wouldn't want to use a memento bag
here, because the Addable in the traversal is the same addable for all users
and all cases of the represented addable class.

> >I need to have a general blessing, particularly from ZC but also from the
> >community, before I merge this into the head.  It changes a few
fundamental
> >pieces of code.
>
> You have at least one community member's backing. :-)

Cool.

> >   I would like to have some kind of approval very soon, so
> >that my merge (already before Steve A.'s And Stephan's recent
mega-checkins)
> >isn't too nightmarish.
>
> I think my checkins (other than the one from yesterday, which corrected
all
> the headers - you can do that yourself on your branch, since the script is
> available in ZopeRoot/utilities) should not interfere with your stuff at
all.

Also cool.

> >Cons
> >
> >  * THE BIGGIE: I use the Addables as the traversed objects to get the
> >creation views.  This has a lot of advantages, in that the creation view
then
> >has all of the necessary Addable creation information available up the
> >acquisition chain.  In order to have this work, I perform, arguably, a
hack:
> >I attach marker interfaces to the Addable *instances* in __implements__,
as
> >they are being added from the zcml.  This conflicts with nothing at the
> >moment, and I tried to accomodate future changes (i.e., adding a true
> >__implements__ declaration to the Addable class).  However, it is a hack,
> >since __implements__, even for these marker interfaces, is for classes...
>
> maybe using a different attribute or registry might solve that.

We must use __implements__ somehow if we want to use the view machinery
(which is the big advantage to this).  The two options are to take my
Addable approach, which has significant practical advantages, or to have the
"create" namespace actually build a quick class on the fly that implements
the marker interface and then build a quick instance of it, and then return
that for traversal.  You would then also want to tack on a lot of the
Addable information (particularly the id) to the created instance.  So just
using the Addable is darn convenient.

> >  * The approach requires you to create a marker interface *if* you need
a
> >special creation view (if you want to use the default then no marker
> >interface is needed).  Very easy, but yet another thing to have to do.
>
> Oh well, as long as you are *not required* to do it, it is fine. Wizards
> can help with this stuff later in anyway.

Yes.

> >  * the zcml property name "marker_interface" is not descriptive enough,
both
> >because it is a pre-creation marker interface, and because in terms of
the
> >implementation it could also be a tuple.  Ideas?
>
> creationInterfaces, initInterfaces, initializationTypes

of those, creationInterfaces (or "creation_interfaces", since that seems to
be the convention ZC is using for zcml attributes) sounds good to me,
maybe....  It is important that they be only markers, though... Whatever is
fine with me.

> >  * It would be nice if one could automatically create marker interfaces
from
> >the associated (created) class __implements__ so that creation views for
> >superclasses could be automatically available.  I don't see an easy clean
way
> >of doing this, though.
>
> A wizard can do that later.

Maybe.  A bit tricky to do effectively.  It might need some work inside the
Interface package to make it happen, or a subclass of Interface for all
objects in Zope, which would be problematic... Punt. ;-)

> You planned features look good too.

Cool.  Thank you very much for your feedback.

Gary