[Zope3-dev] Re: A possible component architecture interpretation of workflow

[Jim Fulton]

yuppie wrote:
> Hi!
> 
> 
> Some thoughts regarding the 'user events' section:
> 
> Jim Fulton wrote:
> 
>>   User events
>>
>>     We need some way to convert user actions to events. Why? Because
>>     we want to decouple the logic for responding to user events from
>>     the logic for displaying user interfaces. This is the "controller"
>>     part of form controller and of the original
>>     "model-view-controller" pattern.
> 
> 
> There are different kinds of buttons. While most buttons are used to 
> invoke controllers, there are other buttons that just modify views or 
> redirect to other views.
> 
> I guess the most common case is the "Search" button. Other examples are 
> the 'Import/Export' button in Zope 2 or the 'New...' button in CMF.

But typically these buttons would point at different pages anyway, so
they wouldn't affect the form.

> 
> While I'm not sure 'event' is the right category for them, they should 
> nethertheless share the validation and redirect machinery with them.

Sure, unless the point somewhere else entirely.

>>     We Will compute user events by adapting a published object and a
>>     request to IUserEvent. If we can find an adapter, we'll then
>>     publish the event in the usual manner.
>>
>>     I'm unsure exactly when this should happen, or what code should be
>>     responsible for it.  It might be done by workflow aware views, or
>>     it might be done during the publication process, perhaps in
>>     response to a publication event.  I don't think we'll know the
>>     best approach here without some prototyping.
>>
>>     The most common sort of user event is someone submitting a form.
> 
> 
> But please don't forget events triggered by links. The 'Undo!' link 
> would be an example.

Sure.  Remember the document I sent, while long, was just a sketch.
It wasn't a proposal. In particular, if this seems to be a good idea,
the next step is to start fleshing out some details with prototypes.

...

> Wouldn't it be better to configure the UI detail 'button' somewhere else 
> and to define events for form variables?

I dunno.  This is a UI we're defining here.  This was just a very
rough suggestion.  I do think it's a good idea to provide ways
to specify forms in one place.

>>     I've also shown a directive that might be used to control what to
>>     do next.  I'm waving my hands here. :)
> 
> 
> I guess the use case (without using tokens/sessions) would look like that:

(I expect non-trivial forms will use sessions.)

> - Forms should always be POSTed to themselves. This is the only way to 
> keep the URL consistent if we response with validation error feedback. 
> Redirecting to the original location is no option because we can't get 
> the POST data through a redirect.

Yup

> - If a form submission was successful (means triggered a database 
> change), the response should always be a redirect. See this link 

Yup

...

> I like the idea to use events to signal that a redirect is necessary, 
> but as mentioned above that would mean we use events for all kinds of 
> buttons, not only those that trigger controllers.

Sure.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org