Niall (and anyone else who has done something similar),
I have been looking into doing a similar thing as you have done,
sub-classing Action and creating an abstract execute method or as you have
done, an abstract processForm method. The main reason was to eliminate the
handling of HttpServletRequest, HttpServletResponse, current action, next
action, etc.
What types of things are you using the Transport object for? Do you have
one generic Transport object for your entire app? You mention that your
"Action" classes do not reference any Servlet methods. How do you handle
putting or getting things from request scope or session scope such as a
logged in user object?
When you have a form that takes user input, do you use the same Action class
for setting up that form as well as for the submit action of that form? We
have run into a lot of cases where I have one action class to setup a form,
such as a User Edit Profile screen. Then, I use a second action class to
save the User. This gives me something like EditUser.do and SaveUser.do,
both going to separate Action classes.
It seems like there are a lot of cases where you have two actions "view" and
"submit". I was thinking about handling those two scenarios in my
sub-classed Action class, calling processView or processSubmit
automatically. Have you done anything like that or does it sound
reasonable?
--
Thanks,
Michael Binette
-----Original Message-----
From: Niall Pemberton [mailto:[EMAIL PROTECTED]]
Sent: Thursday, May 17, 2001 6:06 PM
To: [EMAIL PROTECTED]
Subject: RE: Suggestion:Taking the Servlet out of Action and ActionForm
Mikkel
OK I agree, its never so black & white and your user example looks fine to
me.
I'm wondering about your "inner" controller - sounds like some great
integrated framework, in which case I agree its probably a level of
abstraction I wouldn't want to go to. But what about lots of small
controllers which tie together your logic outside the action.
Anyway, I was probably misleading in saying "thats what we've done". What I
have actually done is this:
We have sub-classed Action and created some abstract standard classes, our
database action does something like this:
1) Get a database connection
2) Create a "Transport" object and store the ActionMapping,
HttpServletRequest, HttpServletResponse & Connection.
3) Set the default "nextAction" to "success"
4) call a processForm(ActionForm, Transport) method (implemented as an
abstract method) catching and handling exceptions.
5) Check the Transport object for error messages. If there are errors create
ActionErrors and save and if a "nextAction" returned by the Transport object
use it otherwise set the nextAction to "failure".
6) Close the Connection
7) Find the mapping for "nextAction" and forward to it.
All out actions then inherit from this ActionFramework class overriding the
processForm(ActionForm, Transport) method. This means that our "Action"
classes have no references to the servlet world, meaning we can test them
independantly.
Now I know straight away you are going to say that I am storing the
ActionMapping, HttpServletRequest & HttpServletResponse in my Transport
object - so far I haven't used them anywhere, it was just in case I ever
needed to. Also if I ever do I will try to hide this in a new method in the
Transport object.
What do you think?
Niall
> -----Original Message-----
> From: Mikkel Bruun [mailto:[EMAIL PROTECTED]]
> Sent: 17 May 2001 20:58
> To: 'Niall Pemberton '; '[EMAIL PROTECTED] '
> Subject: RE: Suggestion:Taking the Servlet out of Action and ActionForm
>
>
> Hi Niall,
>
> I not sure I agree with you, although you have som good points.
>
> When looking at the MVC pattern we can easily identify two of the
> elements,
> namely the view (jsp) and the model (usually persistent object)...
> However, where is our controller??? As you point out, in the
> struts context
> the controller would be (partly) the Action, and probably some kind of
> Facade pattern towards the Model...
>
> However, in the classic sense of the MVC, the Controller should
> be reusable
> between many applications, and the Action dependence to the Servlet API
> doesn't (strictly speaking) make this possible.
>
> The solution to this is ofcourse to build a "inner" Controller, with close
> ties to the Model, such as an Facade or a (none Servlet specific) Command.
> However, I Feel that this just introduces another level of
> abstraction, and
> this abstraction should/could be made by the Action
>
> To give you a clue of the granularity of my Actions I give you
> the following
> example, please comment and tell if you think I have to much Model in it,
> and if, how to avoid it.
> This is probably not the best example, but here it comes...
>
> My Current Project deals with financing...Users has to LogOn to the System
>
> Model : User
> Controller: LogOnAction
>
> The Action makes use of an UserModelFacade. The UserModelFacade has a
> getUser(String uname, String pw) method...
>
> Pseudocode:
>
> User theUser= UserModelFacade.getInstance().getUser(name,pw);
> if(theUser==null)
> return(mappings.findMapping("failure")
> request.getSession().setAttrubute("myUser", theUser);
> return(mappings.findMapping("succes")
>
> This is the basic architecture and strategy we will be using in the
> development.
> When I said that this was a bad example, its because it only access the
> Model once...
> But some of our processes is more complicated than that...
> Sometimes we need to
>
> get the CurrentUser
> get other possible customers in the household
> get number of cars in the household
> get the "new" car
> make a finance calculation based on the above
>
> The following will result is 20-30 lines of code in the Action. LOC's I
> would like to be able to reuse...
>
> I haven't heard of Cactus or HttpUnit before this thread, and I
> will surely
> look into them (souds like great tools)
>
> nice thread btw ;-)
>
> regards Mikkel
>
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Niall Pemberton
> To: [EMAIL PROTECTED]
> Sent: 17-05-2001 17:11
> Subject: RE: Suggestion:Taking the Servlet out of Action and ActionForm
>
> I don't agree - Actions are part of the controller in MVC and need
> access to
> the servlet API to do thing such as retrieving and storing objects under
> the
> appropriate context. Sounds to me like 1) Your using the wrong tool and
> 2)
> You've put your Model in the Actions.
>
> 1) Cactus is a simple test framework for unit testing server-side java
> code.
> It uses JUnit and extends it. It's primary goal is to be able to unit
> test
> server side java methods which use Servlet objects such as
> HttpServletRequest, HttpServletResponse, HttpSession etc.
> http://jakarta.apache.org/commons/cactus/
>
> HttpUnit is a Java library for the automatic stimulation and testing of
> web
> applications - which is supposed to be complimentary to Cactus.
> http://sourceforge.net/projects/httpunit
>
> I haven't used these tools, but I'm about to download them and try them
> out.
> Also I know Struts is in the process of setting up Cactus test suites so
> it
> sounds like is more appropriate than JUnit for this environment.
>
>
> 2) If you succeed in separating your Model from the controller then you
> should end up with a set of small Action classes. Testing your model
> outside
> of the servlet enviornment should then be pretty straight forward. This
> is
> what we've done and it works well.
>
> Niall
>
>
> > -----Original Message-----
> > From: Mikkel Bruun [mailto:[EMAIL PROTECTED]]
> > Sent: 17 May 2001 10:02
> > To: '[EMAIL PROTECTED]'
> > Subject: Suggestion:Taking the Servlet out of Action and ActionForm
> >
> >
> > Hi guys,
> >
> > Here's a little design suggestion. I don't know if you have already
> > discussed this.
> >
> > As we all know Action and ActionForm makes use of parts of the Servlet
> API
> > (HttpRequest).
> > This ties the execution of Action and ActionForm to a servlet
> enviroment.
> > This is not bad, but (imho) it isn't good either...
> >
> > * We are not able to test our Actions in other enviroments (JUNIT for
> > instance)
> > * It's not possible to port our Action and ActionForm implementations
> to
> > other types of applications (applet, console)
> >
> > A couple of month ago I implemented my own Model2 framework that
> > worked with
> > a socalled RequestContext.
> > The RequestContext contained three HashSet's, representing
> > request-, session
> > and applicationattributes
> > In the Servlet's service (post/get) method we would populate the
> > RequestContext with all request, session and applications attributes
> and
> > pass it along the our viewvalidator (in this case an ActionForm
> object),
> > that would extract the needed parameters and react to them (this
> > could still
> > be done with reflection as in struts).
> > Any output from the validation would then be placed in the
> > RequestContext's
> > Collection (as a proxy to the *real* HttpRequest, HttpSession, etc,
> > objects).
> > If the validation was succesful the Servlet would then pass the
> > RequestContext to a Command (or Action). The command would then
> extract it
> > needed parameters and work on them.
> > Once again, output would be place in the RequestContext's
> > representation of
> > Request, Session and Application.
> > When the Command (or Action) was completed, the Servlet would iterate
> > through the RequestContext and place all the attributes into their
> > respective scope.
> >
> > The important point here is that the RequestContext wasn't tied to the
> > Servlet API, although it could be initialized with HTTPRequest as
> > parameter.
> >
> > By doing the above we were able to create validations and actions that
> we
> > could easily test and reuse.
> > What we usually did was that we created JUNIT testcases where we
> created
> > instances of RequestContext and passed it to our Actions and eveluated
> the
> > return values...These JUNIT cases could then be run from anywhere.
> > We actually had our deployment done by Ant, and our deployment
> > scripts would
> > run all our testcases before deploying...
> > We could actually test "all" of our application from the
> commandline...
> >
> > Just my two cents...
> >
> > Mikkel Bruun
> >
> >
>
>
