Despite that your message is related to SAF2, I would like to comment it, explaining how similar mechanism works in SAF1.
On 6/5/06, David Evans <[EMAIL PROTECTED]> wrote:
Hello all, On this page: http://wiki.apache.org/struts/StrutsActionRelease200 There is, under the new features heading a reference to the validation/workflow issues brought up on this page: http://wiki.apache.org/struts/RoughSpots?action=show Under the main list, item number 16, and under Patrick's list, item number 4 and 5, there is discussion of the default workflow and its relation to the idea of view vs. update requests to the same action.
The point is not just processing update/view requests in one action. The point is embracing a different concept to request processing. Consider that one action controls a web resource. What is a web resource? Usually it is something closely related to the business object that you are working with, say you want to add a new employee, this means you work with Employee business object, this means that your web resource is Employee. This web resource can allow you to view employee info, to update it, to add a new employee or to remove it. Typical CRUD stuff. So, the action controls all operations relevant to this web resource.
From my own experience and from experience of portlet spec designers
;) a web resource can usually respond to several input commands/events. So you have Add, Update, View, Delete commands/events. Seems like dispatch action to me. Then you want to render a web resource. You do not want to display a specific view, naah, you want to display a view that corresponds to web resource state. Say, you are in the process of updating an Employee. Then in the view phase you should see update form with "Updating employee" in the header. If you are creating a new employee, you would want to see a similar form, initially empty, with "Adding employee" in the header. Therefore in most cases you have only one event corresponding to view phase, "Display web resource in its current state". This means that dispatch-style processing is appropriate for input phase, and regular action is appropriate for render phase.
I haven't seen any discussion of this on the dev list, and i'm wondering if anyone is actively working on this and what directions are being considered.
I haven't worked on SAF2 yet, but if you want to see similar ideas implemented for SAF1, take a look at Struts Dialogs: http://struts.sourceforge.net/strutsdialogs/
In trying to work this out for myself, i came up with a simple solution for the main use case, and i would like to share it here and ask for comments. The main idea is that the Prepareable interceptor is used to setup the view, and another interceptor called SubmittableInterceptor is added to the end of the default interceptor stack and is used to determine if a form submission has occured. A marker interface called Submittable allows the user, via a boolean wasSubmitted method, to determine how the action will determine if a form submission has occured, whether it be the POST vs GET idea, the inclusion of a hidden flag field, or the presence of a submit or button parameter. It also has a "submit" method that can be used optionally to process the submission and return a result string.
Input phase usually allows for several commands/events, so one submit method does not make a lot of sense to me. Dispatch-style action is much better in this respect. This makes an action looking similar to code-behind class in .Net.
The SubmittableInterceptor will see if wasSubmitted returns true, and if so, run the submit method. If the submit method returns a result string, the interceptor returns that, otherwise the interceptor stack invocation continues. If the form was not submitted, the interceptor returns the INPUT result, displaying the form, which has been setup by Prepareable.
This two-phase input/render process can be easily done without interfaces. You simply have methods that are called in event occurs, this is typically the input phase. You also have one method that is called when web resource has to be displayed, this is the render phase. I don't see the necessity for a whole bunch of interfaces. Well, on the other hand, Prepareable interface can have renderView() method, and standard action would implement Prepareable along with Submittable, this would be basically the same that I implemented for SAF1.
My BaseAction extends ActionSupport and implements Submittable and allows for the inclusion of the SubmittableInterceptor into the default stack, with default behavior that does nothing. The Validate method of the action will also check wasSubmitted to determine if it should validate
I suggest a different approach. validate() should not be called at all. You would have your event handler called, then you can validate whatever you want. If you have one validate() method for all events, call it, it is not that complex to write one line of code in an event handler. You don' t have to implement any interfaces and all process flow is right in front of you. By the way, having an event handler being called immediately allows to get rid of most interceptors, they are not really needed unless they do some global stuff like logging or checking if user logged it. My opinion that custom web resource interceptors are not really needed, they only complicate things. Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
