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

Stephan Richter srichter@cbu.edu
Tue, 02 Apr 2002 13:51:59 -0600


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.

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?

>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. :-)

>   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.

>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.

>  * 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.

>  * 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

>  * 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.

You planned features look good too.

--
Stephan Richter
CBU - Physics and Chemistry Student
Web2k - Web Design/Development & Technical Project Management