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

[Casey Duncan]

The way Zope2 does this is horrible. Stuffs all the constructor forms 
and methods into a namespace. Some of them are set directly as 
attributes of objectmanager, eeee!. And, it is not possible to create an 
instance of an object very generically. This may be improved by me in 
2.6, but I have a feeling whatever I do will be more of a hack than a 
general solution.

So, I do think, given the service/utility infrastructure of Zope3, you 
should be able to throw out an interface or class and have it return the 
correct view component to instanciate it TTW. This view component would 
be called in the context of the container (like in Zope2), since the 
instance wouldn't exist yet.

In light of that, what may work is an adapter implementation that wraps 
the view component necessary to instanciate an object around the 
container. You would simply get the correct adapter and then display the 
appropriate page template in it, starting with the default one for that 
view.

-Casey

Chris Withers wrote:
> Guido van Rossum wrote:
> 
>>>* we ought to be able to specify pre-creation views (plural!) of an
>>>object, that will let us provide TTW the values needed to
>>>instantiate an object (including a file upload).  This seems
>>>particularly important to me to be able to use non-Zope specific
>>>classes.
>>>
>>Very interesting.  That need came up in the jobboard example too!  It
>>has two pre-creation views: one is a form that lets you enter the
>>content fields, one is a preview page that lets you see how the object
>>would be shown after creation.  IMO this is a pretty useful pattern; I
>>used it in the Python FAQ wizard.  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.
>>
> 
> Well, Zope 2 has this although I don't particularly like the way it's done, I can't think
> of a better alternative.
> 
> 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...
> 
> 
>>>* 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.
>>>
>>Also very interesting.  The jobboard example has the need of a default
>>view (also for the whole jobboard itself).  We discussed this with Jim
>>over lunch yesterday, and he agreed that a default view was a good
>>idea.  But then he hopped on a plane to Europe where he'll stay for
>>three weeks, so it may be a while.
>>
> 
> ...the CMF way of tackling this was pretty cool. I really like the Types Tool. Whats'
> gonna be the Zoep 3 equivalent?
> 
> cheers,
> 
> Chris
> 
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev@zope.org
> http://lists.zope.org/mailman/listinfo/zope3-dev
> 
>