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

[Gary Poster]

On Thursday 28 March 2002 10:38 am, Chris Withers wrote:
[pre-creation views]
> Well, Zope 2 has this although I don't particularly like the way it's done,
> I can't think of a better alternative.

For my take on an improved alternative, see below.

> BTW, the pre-creation view is often the normal edit view + an id field. IS
> this a pattern we can enhance for? The CMF does a pretty good job, but it
> doebns't let you edit objects before you create them, which kinds sucks for
> simple apps like Squishdot/Swishdot...

One possibility for improvement in a Zope 3 direction is making registered 
views for the purpose: this would allow multiple pre-creation views, 
development of pre-creation views TTW, selection of default pre-creation 
views TTW, and all the other good customization and flexibility that Zope 3 
views (will) provide for both developers and site managers.  

(As I note in the wiki, the only problem to using normal Zope 3 views for 
this purpose is that a view needs a context, and the only pre-creation 
context is the container, and so standard Zope 3 views would have to be 
registered to the Container interface, which would muddy up the Container 
view namespace with lots of mini-adder views.  Not good.  I have some ideas 
on solving this but they are not thought through yet.)

[post creation default view]
> ...the CMF way of tackling this was pretty cool. I really like the Types
> Tool. Whats' gonna be the Zoep 3 equivalent?

While the pre-creation views idea may require some thinking within the core 
component machinery, a default post-creation view could rely on the container 
for implementation--and thus could also rely on a layered system, as the CMF 
is layered on top of Zope 2.  It would be nice if this *were* part of the 
Zope 3 core, though, IMO.  Yes, basic Zope 3 content integration with a 
service similar to the Type tool would be cool, it seems, at least on first 
blush.

Gary