Re: Struts design question about maintenance screens
The standard DispatchAction can be a handy way to keep various tasks together in the same Action, where they can share code, but without getting into kludgy performs. Dispatch lets you have a separate perform for each task, but all in the same Action, where they can be easier to maintain. http://jakarta.apache.org/struts/doc-1.0.2/api/org/apache/struts/actions/DispatchAction.html -- Ted Husted, Husted dot Com, Fairport NY US -- Developing Java Web Applications with Struts -- Tel: +1 585 737-3463 -- Web: http://husted.com/about/services [EMAIL PROTECTED] wrote: Hi Folks: thanks to your help, you indicated that the Action should preload form values on a maintenance form. This works great. I have an Action object that allows maintenance on a table (call it table A). This action object handles preloading of data as well as the actual updating of data (Add/Edit/View). Another question I have: - The action object gets kind of kludgey in how I have to keep track of whether I am preloading data (called from a html:link) or whether I am Applying the data (called from the form Submit). Is it overkill if I create 2 different actions (1 action to preload the data and another to update the data)?I think by doing it this way, it may be easier for me to incorporate the sensitive form resubmit prevention by using tokens. Any suggestions are much appreciated. thanks, Theron -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts design question about maintenance screens
You dont need two actions. You can use an 'action' parameter to decide which action you are performing. On your html:link add a parameter action=view and on the submit action=add or action=edit depending on what you are doing. In your action, you can have if statements that perform different functions base on what you are doing. There is an example in the struts docs that explains this. (Cant find it now. you have to search for it) -JC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 21, 2002 11:10 AM To: Struts Users Mailing List Subject: Struts design question about maintenance screens Hi Folks: thanks to your help, you indicated that the Action should preload form values on a maintenance form. This works great. I have an Action object that allows maintenance on a table (call it table A). This action object handles preloading of data as well as the actual updating of data (Add/Edit/View). Another question I have: - The action object gets kind of kludgey in how I have to keep track of whether I am preloading data (called from a html:link) or whether I am Applying the data (called from the form Submit). Is it overkill if I create 2 different actions (1 action to preload the data and another to update the data)?I think by doing it this way, it may be easier for me to incorporate the sensitive form resubmit prevention by using tokens. Any suggestions are much appreciated. thanks, Theron -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts design question about maintenance screens
In reference to having two actions (create and update) instead of one combined action, this is exactly what I have done. While the struts-example uses a parameter, I personally prefer not to take that route. I have simplified my code/JSPs by having each do only one thing (good OO) at the slight expense of increasing the number of Java classes and JSPs. Using 2 JSP instead of 1 might seem like duplication, but there isn't that much and each JSP is much easier to read/maintain than the single JSP that is trying to pretend it's two. The extra action classes are also not a big deal as I move more and more logic out of the action classes themselves. Just my thoughts. Simon - Simon P. Chappell [EMAIL PROTECTED] Java Programming Specialist www.landsend.com Lands' End, Inc. (608) 935-4526 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 21, 2002 11:10 AM To: Struts Users Mailing List Subject: Struts design question about maintenance screens Hi Folks: thanks to your help, you indicated that the Action should preload form values on a maintenance form. This works great. I have an Action object that allows maintenance on a table (call it table A). This action object handles preloading of data as well as the actual updating of data (Add/Edit/View). Another question I have: - The action object gets kind of kludgey in how I have to keep track of whether I am preloading data (called from a html:link) or whether I am Applying the data (called from the form Submit). Is it overkill if I create 2 different actions (1 action to preload the data and another to update the data)?I think by doing it this way, it may be easier for me to incorporate the sensitive form resubmit prevention by using tokens. Any suggestions are much appreciated. thanks, Theron -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts design question about maintenance screens
thanks Simon: With all do respect to the other method (ie, parameters), I tend to favor your approach.I have just completed a maintenance screen by having a combined action and I don't like the if-else's and the action file is huge. By splitting it, I can re-use the LoadFormAction in other areas as well as the SaveAction and not have both operations (load and save) tightly coupled as I don't feel they should be tightly coupled.The only drawback I see with this favorable approach is more source files but these source files will be smaller and more maintanable/straight-forward I believe. Before I went with this approach, I just wanted to hear how others felt about this approach. thanks for your input. Theron Chappell, Simon P Simon.Chappell@lanTo: Struts Users Mailing List [EMAIL PROTECTED] dsend.com cc: Subject: RE: Struts design question about maintenance screens 02/21/02 09:38 AM Please respond to Struts Users Mailing List In reference to having two actions (create and update) instead of one combined action, this is exactly what I have done. While the struts-example uses a parameter, I personally prefer not to take that route. I have simplified my code/JSPs by having each do only one thing (good OO) at the slight expense of increasing the number of Java classes and JSPs. Using 2 JSP instead of 1 might seem like duplication, but there isn't that much and each JSP is much easier to read/maintain than the single JSP that is trying to pretend it's two. The extra action classes are also not a big deal as I move more and more logic out of the action classes themselves. Just my thoughts. Simon - Simon P. Chappell [EMAIL PROTECTED] Java Programming Specialist www.landsend.com Lands' End, Inc. (608) 935-4526 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 21, 2002 11:10 AM To: Struts Users Mailing List Subject: Struts design question about maintenance screens Hi Folks: thanks to your help, you indicated that the Action should preload form values on a maintenance form. This works great. I have an Action object that allows maintenance on a table (call it table A). This action object handles preloading of data as well as the actual updating of data (Add/Edit/View). Another question I have: - The action object gets kind of kludgey in how I have to keep track of whether I am preloading data (called from a html:link) or whether I am Applying the data (called from the form Submit). Is it overkill if I create 2 different actions (1 action to preload the data and another to update the data)?I think by doing it this way, it may be easier for me to incorporate the sensitive form resubmit prevention by using tokens. Any suggestions are much appreciated. thanks, Theron -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts design question about maintenance screens
There are a number of ways to achieve this, and again (!) it's about choice, although
I must say this can be confusing for newbie (and experienced!) struts users.
1. 2 Actions, 1 for 'pre' and 1 for 'post' processing
2. An 'action' parameter, with switch behaviour in the action class
3. 'isVirgin()' extension to the Action Form.
Option 3 is basically an added method to the ActionForm class that allows the Action
to determine if 'pre' or 'post' processing the form, without the need for an 'action'
parameter. Consider the following in the Action class, where 'sf' refers to the
instance of the form:
// determine if pre-processing, and if so continue on to the View
if (sf.isVirgin())
return mapping.findForward(ChikiConstants.ACTION_FORWARD_SUCCESS);
// getting this far indicates post-processing...
/**
* Determines if pre or post processing the form.br
* Criteria being null indicates pre-processing.
*
* @return true if pre-processing the form
*/
public boolean isVirgin () {
return ( (criteria == null) );
}
The 'isVirgin' method returns true if 'pre' processing the form, and false if 'post'
processing.
Option 1 gives good seperation, but can lead to an unneccesary proliferation of Action
classes in large apps
Option 2 achieves the same, but can lead to 'messy' Actions
Option 3 needs additional logic in the form, but allows pre and post processing in the
one Action - however, this doesn't extend as far as seperate actions and action
parameters when you need to do more than just pre and post processing.
In our applications we have used all 3 at various times. We tend to use option 3 when
we just need the split between pre and post processing, eg a Search or Login action.
In more complex sceanrio's we tend to use option 1 or 2.
Try to determine which best fits your scenario. Depending on your context, one
solution may be better than the other, but this will not be true across the board for
all scenarios. Think through your real needs before choosing the solution.
With regards to your exact scenario, we developed option 3 as a solution to this very
situation, so I would suggest option 3 might be best suited, although you will
ultimately have to decide ! Having developed option 3 and implemented it, we have
found it to be the most effective way of getting around this. As I previously stated,
option 1 and 2 come into their own in other situations.
Hope this helps - if you need any more detail let me know,
Ghoot
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 21 February 2002 17:10
To: Struts Users Mailing List
Subject: Struts design question about maintenance screens
Hi Folks:
thanks to your help, you indicated that the Action should preload form
values on a maintenance form. This works great.
I have an Action object that allows maintenance on a table
(call it table
A). This action object handles preloading of data
as well as the actual updating of data (Add/Edit/View).
Another question I have:
- The action object gets kind of kludgey in how I have to
keep track of
whether I am preloading data (called from a html:link) or
whether I am
Applying the data (called from the form Submit).
Is it overkill if I create 2 different actions (1 action to
preload the
data and another to update the data)?I think by doing
it this way, it
may be easier for me to incorporate the sensitive form resubmit
prevention by using tokens.
Any suggestions are much appreciated.
thanks,
Theron
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Struts design question about maintenance screens
Wow!
Great reply. I am saving this one.
thanks,
Theron
Emaho, Ghoot
Ghoot@PETROTECHNTo: Struts Users Mailing List
[EMAIL PROTECTED]
ICS.co.uk cc:
Subject: RE: Struts design question
about maintenance screens
02/21/02 09:51 AM
Please respond to
Struts Users
Mailing List
There are a number of ways to achieve this, and again (!) it's about
choice, although I must say this can be confusing for newbie (and
experienced!) struts users.
1. 2 Actions, 1 for 'pre' and 1 for 'post' processing
2. An 'action' parameter, with switch behaviour in the action class
3. 'isVirgin()' extension to the Action Form.
Option 3 is basically an added method to the ActionForm class that allows
the Action to determine if 'pre' or 'post' processing the form, without the
need for an 'action' parameter. Consider the following in the Action class,
where 'sf' refers to the instance of the form:
// determine if pre-processing, and if so continue on to the View
if (sf.isVirgin())
return
mapping.findForward(ChikiConstants.ACTION_FORWARD_SUCCESS);
// getting this far indicates post-processing...
/**
* Determines if pre or post processing the form.br
* Criteria being null indicates pre-processing.
*
* @return true if pre-processing the form
*/
public boolean isVirgin () {
return ( (criteria == null) );
}
The 'isVirgin' method returns true if 'pre' processing the form, and false
if 'post' processing.
Option 1 gives good seperation, but can lead to an unneccesary
proliferation of Action classes in large apps
Option 2 achieves the same, but can lead to 'messy' Actions
Option 3 needs additional logic in the form, but allows pre and post
processing in the one Action - however, this doesn't extend as far as
seperate actions and action parameters when you need to do more than just
pre and post processing.
In our applications we have used all 3 at various times. We tend to use
option 3 when we just need the split between pre and post processing, eg a
Search or Login action. In more complex sceanrio's we tend to use option 1
or 2.
Try to determine which best fits your scenario. Depending on your context,
one solution may be better than the other, but this will not be true across
the board for all scenarios. Think through your real needs before choosing
the solution.
With regards to your exact scenario, we developed option 3 as a solution to
this very situation, so I would suggest option 3 might be best suited,
although you will ultimately have to decide ! Having developed option 3 and
implemented it, we have found it to be the most effective way of getting
around this. As I previously stated, option 1 and 2 come into their own in
other situations.
Hope this helps - if you need any more detail let me know,
Ghoot
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 21 February 2002 17:10
To: Struts Users Mailing List
Subject: Struts design question about maintenance screens
Hi Folks:
thanks to your help, you indicated that the Action should preload form
values on a maintenance form. This works great.
I have an Action object that allows maintenance on a table
(call it table
A). This action object handles preloading of data
as well as the actual updating of data (Add/Edit/View).
Another question I have:
- The action object gets kind of kludgey in how I have to
keep track of
whether I am preloading data (called from a html:link) or
whether I am
Applying the data (called from the form Submit).
Is it overkill if I create 2 different actions (1 action to
preload the
data and another to update the data)?I think by doing
it this way, it
may be easier for me to incorporate the sensitive form resubmit
prevention by using tokens.
Any suggestions are much appreciated.
thanks,
Theron
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail
RE: Struts design question about maintenance screens
Another drawback of Option 1 is that if your jsp's change frequently (adding
fields in the form, different formatting etc.) having two jsp's requires you
to update two files. This is not a problem in itself but it might make for
more difficult maintenance because you might make changes on one jsp but
forget the other.
Just another thing to consider when you make your design choice.
Option 3 sounds attractive. Thanks for the idea, Emaho.
JC
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 21, 2002 12:09 PM
To: Struts Users Mailing List
Cc: [EMAIL PROTECTED]
Subject: RE: Struts design question about maintenance screens
Wow!
Great reply. I am saving this one.
thanks,
Theron
Emaho, Ghoot
Ghoot@PETROTECHNTo: Struts Users Mailing
List [EMAIL PROTECTED]
ICS.co.uk cc:
Subject: RE: Struts design
question about maintenance screens
02/21/02 09:51 AM
Please respond to
Struts Users
Mailing List
There are a number of ways to achieve this, and again (!) it's about
choice, although I must say this can be confusing for newbie (and
experienced!) struts users.
1. 2 Actions, 1 for 'pre' and 1 for 'post' processing
2. An 'action' parameter, with switch behaviour in the action class
3. 'isVirgin()' extension to the Action Form.
Option 3 is basically an added method to the ActionForm class that allows
the Action to determine if 'pre' or 'post' processing the form, without the
need for an 'action' parameter. Consider the following in the Action class,
where 'sf' refers to the instance of the form:
// determine if pre-processing, and if so continue on to the View
if (sf.isVirgin())
return
mapping.findForward(ChikiConstants.ACTION_FORWARD_SUCCESS);
// getting this far indicates post-processing...
/**
* Determines if pre or post processing the form.br
* Criteria being null indicates pre-processing.
*
* @return true if pre-processing the form
*/
public boolean isVirgin () {
return ( (criteria == null) );
}
The 'isVirgin' method returns true if 'pre' processing the form, and false
if 'post' processing.
Option 1 gives good seperation, but can lead to an unneccesary
proliferation of Action classes in large apps
Option 2 achieves the same, but can lead to 'messy' Actions
Option 3 needs additional logic in the form, but allows pre and post
processing in the one Action - however, this doesn't extend as far as
seperate actions and action parameters when you need to do more than just
pre and post processing.
In our applications we have used all 3 at various times. We tend to use
option 3 when we just need the split between pre and post processing, eg a
Search or Login action. In more complex sceanrio's we tend to use option 1
or 2.
Try to determine which best fits your scenario. Depending on your context,
one solution may be better than the other, but this will not be true across
the board for all scenarios. Think through your real needs before choosing
the solution.
With regards to your exact scenario, we developed option 3 as a solution to
this very situation, so I would suggest option 3 might be best suited,
although you will ultimately have to decide ! Having developed option 3 and
implemented it, we have found it to be the most effective way of getting
around this. As I previously stated, option 1 and 2 come into their own in
other situations.
Hope this helps - if you need any more detail let me know,
Ghoot
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: 21 February 2002 17:10
To: Struts Users Mailing List
Subject: Struts design question about maintenance screens
Hi Folks:
thanks to your help, you indicated that the Action should preload form
values on a maintenance form. This works great.
I have an Action object that allows maintenance on a table
(call it table
A). This action object handles preloading of data
as well as the actual updating of data (Add/Edit/View).
Another question I have:
- The action object gets kind of kludgey in how I have to
keep track of
whether I am preloading data (called from a html:link) or
whether I am
Applying the data (called from the form Submit).
Is it overkill if I create 2 different actions (1 action to
preload the
data and another to update the data)?I think by doing
it this way, it
may be easier for me to incorporate the sensitive form resubmit
prevention by using tokens.
Any suggestions are much appreciated.
thanks,
Theron
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail
