RE: Suggestion:Taking the Servlet out of Action and ActionForm
Good point, were still developing our first Struts system. The Transport object could just store the DataSource, retrieved from the servlet context and let the actions get and close connections from the Transport object, if thats an issue for you. With the number of users we are planning for and the processing most of our actions do, I don't think this will be an issue - we certainly won't have any 3 hour reports. If we do though they would probably deserve some individual coding. Niall > -Original Message- > From: Hicks, James [mailto:[EMAIL PROTECTED]] > Sent: 19 May 2001 21:14 > To: '[EMAIL PROTECTED]' > Subject: RE: Suggestion:Taking the Servlet out of Action and ActionForm > > > I see one problem with Niall's Transport object. The Transport has a > reference to a Connection object. This could cause severe scalability > issues in the future. Let's say for instance you are using a connection > pool with an initial 5 connections and a max of 20. If your > Action.perform > method does a lot of processing and you have a high traffic sight > you could > run out of connections very fast. > > The way I would recommend is using a Singleton to get a database > Connection > from the pool, this way you could release it when you don't need it. > > For example, your Action.perform(..) is responsible for getting > info from a > database, and drawing a graph to visually display the data. > Let's say there > are 5 million records returned from the query. The records hold data to > determine how many hours an employee has worked this month. You want to > create comparison reports for each employee, department and location. For > the purpose of the example, the reports would take over 3 hours. With > Niall's implementation, you would have to keep that database connection > around for the entire time. If you had direct access to the > pool, you could > release the connection after the query was finished. This would allow > someone else to use the connection. > > Now in real life, you probably wouldn't grab all 5 million > records at once. > Even if you did do over 100 queries on the database, if you were releasing > the Connection when it wasn't used and getting another when needed, the > overall application speed would be a lot faster than if you were > to keep the > connection around. > > Just My Opinion > James Hicks > > -Original Message- > From: Michael Binette [mailto:[EMAIL PROTECTED]] > Sent: Saturday, May 19, 2001 2:18 PM > To: [EMAIL PROTECTED] > Subject: RE: Suggestion:Taking the Servlet out of Action and ActionForm > > > 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.
RE: Suggestion:Taking the Servlet out of Action and ActionForm
Michael, First thing to say is we are only just starting to devlop our first Struts app after first prototyping vanilla Struts and then trying out various customizations to create a more productive environment. I try to answer your points in the message below. > -Original Message- > From: Michael Binette [mailto:[EMAIL PROTECTED]] > Sent: 19 May 2001 20:18 > To: [EMAIL PROTECTED] > Subject: RE: Suggestion:Taking the Servlet out of Action and ActionForm > > > 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? So far we have one Transport object for the entire app (although most of it isn't yet written!). It contains mechanism for getting a Connections object, storing error messages and altering the control flow (if "success" and "failure" are not enough). Addtionally I have also provided getters/setters for HttpServletRequest, HttpServletResponse & ActionMapping in case I meet a scenario I have to access them - although I may hide these by adding appropriate methods in the future e.g. getUser() could access the HttpServletRequest to pass back a User object. Currently the only thing we plan to store in session scope is a User object and currently we have a separate logon action that doesn't inherit from our standard action - we haven't finished developing it yet and I think I'm going to do what I said in the previous paragraph and put a setUser()/getUser methods in the Transport object. Besides the User, the only other things we plan for are Connections and the ActionForm. Connections are being handled by a generic Action and the Transport object. I have two generic actions - one that requires a Database connection, one that doesn't. > 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. Yes. > 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? Yes, but I think its more complex. If you just consider "database update" I see (so far) the following scenarios: - Query a single row - Query a list of rows - Master Detail Query - Create a single row - Create children for a parent - Update a single row - Update a Master Detail - Delete a single row - Delete a Master Detail On the query side you need to specify the query and criteria, map from the DB to the view and forward to the correct JSP. On the update side you need validation, mapping to the database and forwarding to the correct query action when successful. Probably there are more but I hope this will cater for most. > -- > 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
RE: Suggestion:Taking the Servlet out of Action and ActionForm
I see one problem with Niall's Transport object. The Transport has a reference to a Connection object. This could cause severe scalability issues in the future. Let's say for instance you are using a connection pool with an initial 5 connections and a max of 20. If your Action.perform method does a lot of processing and you have a high traffic sight you could run out of connections very fast. The way I would recommend is using a Singleton to get a database Connection from the pool, this way you could release it when you don't need it. For example, your Action.perform(..) is responsible for getting info from a database, and drawing a graph to visually display the data. Let's say there are 5 million records returned from the query. The records hold data to determine how many hours an employee has worked this month. You want to create comparison reports for each employee, department and location. For the purpose of the example, the reports would take over 3 hours. With Niall's implementation, you would have to keep that database connection around for the entire time. If you had direct access to the pool, you could release the connection after the query was finished. This would allow someone else to use the connection. Now in real life, you probably wouldn't grab all 5 million records at once. Even if you did do over 100 queries on the database, if you were releasing the Connection when it wasn't used and getting another when needed, the overall application speed would be a lot faster than if you were to keep the connection around. Just My Opinion James Hicks -Original Message- From: Michael Binette [mailto:[EMAIL PROTECTED]] Sent: Saturday, May 19, 2001 2:18 PM To: [EMAIL PROTECTED] Subject: RE: Suggestion:Taking the Servlet out of Action and ActionForm 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
RE: Suggestion:Taking the Servlet out of Action and ActionForm
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. &g
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
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 a
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 > >
Re: Suggestion:Taking the Servlet out of Action and ActionForm
Mikkel Bruun wrote: > > 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... Doesn't J2EEUnit , now known as cactus attempt to do the testing thing? It uses JUnit. find it in the jakarta commons project area. Jari -- Jari Worsley Senior Programmer Hyperlink Interactive Ltd
