[Zope3-dev] RFC: preCreation view, postCreation view use cases

[Gary Poster]

From: "Steve Alexander" <steve@cat-box.net>
[ pre-creation views ]
> I often want something like this.
>
> I usually implement it an object of the usual class for that content
> component, initialized with the correct values, and wrapped
> (ContextWrapper) in the context of its container-to-be, even though it
> has not yet been added to its container-to-be.

This gets at half of my issue: you don't add the object to the container
until the desired arguments have been gathered.  I was suggesting further
that it should be easily possible to *not create the object* until the
desired arguments have been gathered.  The current inability to do so
creates a number of niggles, which center around (1) inefficiency and (2)
forcing a Zope product to provide default initialization values when Python
itself does *not* require a class to provide default initialization values.
I believe the first niggle is valid, if not necessarily pertinent; the
second, because one of Zope 3's goals is the easier integration of non-Zope
Python classes, is both valid and pertinent.

> An alternative way of doing this is to extend containers to have to sets
> of contents: one is the usual set of persistent contents. Another is a
> set of subjunctive contents, which either become real persistent
> contents when properly added, or get removed if the adding process is
> aborted (explicitly or by timing out).

This doesn't seem appealing to me as a design, but it might work, and maybe
it's the way we should go.

I think the best solution might be another namespace that returns class
objects, which then have associated views.   Therefore,
"myFolder/.NaiveFile.;factory" would get the .NaiveFile. class (factory) and
then the default factory view for that class; and
"myFolder/.NaiveFile.;factory/specialFactoryView" (or, explicitly,
"myFolder/.NaiveFile.;factory/specialFactoryView;view") would get the
.NaiveFile. class and then the factory view named "specialFactoryView"
registered for instances that implement INaiveFile (or whatever).

Leveraging the view machinery seems like a very good idea, and a clear
namespace sounds like a good idea, and using class/factory objects as the
connector seems like a reasonable idea.

This sounds pretty, I think, but actually making this work with the current
design for views would require some careful thought.  Since we want to get
factory views as registered for instance interfaces (not class interfaces)
that means we can't just return a class object from the factory namespace
and have the view service return the a view registered to a corresponding
instance unless we engage in tricks.  My imagination has not come up with a
graceful, non-hackish solution for this yet.

Thoughts?  I was going to try to throw together a proof of concept for this
this weekend until I realized the class vs. instance interface problem with
using the view machinery.

> >   * we ought to be able to specify a default post-creation view of an
object,
> > to which the creation process will automatically direct the user after
object
> > creation.
>
> Do we need this in addition to a normal default view?
>
> There's already a directive to state that a particular view is the
> default view for a content component.
>
> Then again, perhaps you're taking about a specific post-creation view
> that may be different than the normal default view.

Yup, that's what I'm talking about. :-)  The default view currently
implemented is primarily part of use cases for actors that are site visitors
or site members; the post-creation default view I suggest is primarily for
use cases involving the content manager actor.

Gary