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

[yuppie]

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.

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

>     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.

>     Perhaps browser view directives (view, page, pages, xxxform, ...)
>     will grow button directives::
> 
>        <page
>           name="foo.html"
>           ...
>           />
> 
>           <button name="update"
>                   event=".FooUpdate"
>                   subscriber=".myupdatehandler"
>                   />
> 
>           <on event="zope.app.form.browser.Updated"
>               redirect_to="index.html" />
>           ...
>        </page>
> 
>     Where the event values are names of event factories called
>     with the view and the request. Subscribers to the resulting
>     event are then notified.

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

>     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:

- 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.

- If a form submission was successful (means triggered a database 
change), the response should always be a redirect. See this link 
(Post/Redirect/Get pattern) for the reasons: 
<http://www.theserverside.com/patterns/thread.tss?thread_id=20936>

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.


Cheers,
	Yuppie