[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