Re: Struts Design question

[Mark Nichols]

From: "Yaman Kumar" <[EMAIL PROTECTED]>

> I have a AformBean in A.jsp and the page action is actionA, actionA
> processed
> all AfromBean values and got some dynamic data from Database,Now i
> would like to keep this data in BFormBean and the actionA forwards the
> output to B.jsp  how to keep the data in BformBean and how to populate
them
> in B.jsp?.
>

This is just a stab in the dark, but I think you need to create an instance
of BFormBean in actionA, and populate it yourself with whatever data it
holds. Then, before forwarding to B.jsp, you need to set BFormBean in the
appropriate scope (session or request) as defined in your struts-config.xml
file.

mark n.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts design question re: form action

[Craig R. McClanahan]

On Sat, 13 Apr 2002, Wellie W. Chao wrote:

> Date: Sat, 13 Apr 2002 10:57:29 -0400
> From: Wellie W. Chao <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Struts design question re: form action
>
> I'm just curious about a design issue with Struts 1.1. The  tag
> has a "forward" attribute that lets you specify an entry from
> struts-config.xml as the destination of the link. That way you aren't tied
> to a particular action or a particular JSP/HTML page. Why isn't there a
> similar attribute for ? You have to directly specify the URI
> (using the "action" attribute) instead of being able to specify a forward
> mapping. It just seemed inconsistent to me.

A couple of reasons:

* The "action" parameter (which is used to specify the  you want)
  is already a logical indirection; the name of a bunch of business logic
  that you want to execute ("save customer") without knowing anything
  about the actual Action class that implements this logic.  It would be
  redundant to provide two different logical indirection schemes.

* Using a forward parameter instead of an action name would mean that the
  page has no way to infer what form bean to use, so you'd essentially
  have to give up all the fancy support provided for form beans.

Craig



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts design question about maintenance screens

[Ted Husted]

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:   
> For additional commands, e-mail: 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Struts design question about maintenance screens

[Jakkampudi, ChandraseKhar]

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"

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

RE: Struts design question about maintenance screens

[theron . kousek]

Wow!
Great reply.   I am saving this one.

thanks,
Theron



   
  
"Emaho, Ghoot" 
  
  
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.
 * 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 d

RE: Struts design question about maintenance screens

[Emaho, Ghoot]

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.
 * 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:   
> 
> For additional commands, e-mail: 
> 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Struts design question about maintenance screens

[theron . kousek]

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"

  
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

[Chappell, Simon P]

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:   

For additional commands, e-mail: 


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Struts design question about maintenance screens

[Jakkampudi, ChandraseKhar]

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:

For additional commands, e-mail:


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: Struts Design question

[Frank Lawlor]

> > But my beans already contain the validation! Besides, performing the
> validation in the ActionForm is effectively tying business logic (data
> validation) to the web framework dontya think?
> 
> Well, I put data type and required field validation only in the bean.
> Validation that is more advanced than that, or based on business rules
> should be in your app server (if you have one), or in the 
> action object.
> 

While the response might be OK in a specific solution,
I think it is, in general, the wrong partitioning
of the validation issue.  The questioner was more on
the correct track.

To understand the more general case, consider the
case where a company has a database(s) and is
developing multiple applications, some may even
be developed by 3rd parties.

How do they look at the data validation issue?
Any DB administrator will tell you HE/SHE is 
responsible for the DB integrity, not the 
(irresponsible :-) app developers:

  - The data integrity issues need to be defined
by those who really understand and are 
responsible for them.  This includes business
data rules.

  - You don't want to replicate the validation in
multiple applications.

  - You don't want to have to change multiple 
applications and the database simultaneously
if there are changes.

  - etc., etc., etc.

Note that this doesn't mean ALL validation is 
associated with the database, just that which 
relates to the data model and the business integrity of
the data base.  If one app requires certain data,
another app different data, and the database doesn't
care, then it is the application responsibility.

To address this we defined a set of objects which
front the database.  They worry not only about
validation, but also things specific to the database
(e.g. query language), connection pooling, etc.

To work well with web applications these objects 
need to have a validation interface that lets you
provide the total set of new (string?) data and allows 
the object to return field-specific and object-general
error information.

This is also a good place to place the common
"business data rules" (not "application rules") so
that all applications use one common set, maintenance
is consistent, etc.

In VERY simple cases you could merge this with Action
classes, but generally there are significant differences,
no 1-1 relationship, etc.

Frank Lawlor
Athens Group, Inc.
(512) 345-0600 x151
Athens Group, an employee-owned consulting firm integrating technology
strategy and software solutions.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts Design question

[Jeff_Mychasiw]

If I could jump in and ask a question,

I have searched this list for a best practice regarding the relationship between
  formbeans, value objects, and formatting/cleaning data.

I found the discussion between Jon and Ted interesting.

I am gearing up to try and use struts in my current project so I would like to
  clear on thing up.

We use value objects (with int's,floats, ect)  from Session EJB's.

In addition to this, we populate the editable text boxes with formatted values
  such as currency (with comma's), phone number with brackets , dates ,and
  so on.

So the data going into the page get's formatted and upon submit must get cleaned
  and then validated.

 I was under the impression that  this would be done in the FormBean in a couple
  of different ways.

One is to store the  property as it native type (int), and do the formatting in
  the standard  String getXXX() and clean the data in the standard
  setXXX(String xxx).

The second is to create a standard form bean but supply an extra set of methods
  to deal with the special cases, such as: int getIntXXX() ect.

Am I off base with this line of thinking?





Jon Wall wrote:
>  I'm
> assuming, then, that the ActionForm performs another
> function that I hadn't thought about - converting the
> String and boolean props that you're bringing in on
> the web to the navtive structure used by the backend.
> Is this true?  So what you're telling me is...I not
> only need to create an ActionForm class for each of my
> many components (100+) that actually implements each
> of the public methods, but for each of the non
> String/boolean properties I need to make a sort of
> formatter method.

The ActionForm is really about buffering. It gives the HTML controls
persistance, until the data can be validated and/of converted to your
native structures. What happens when someone tries to toss "47a" at an
Integer property? HTTP is a hostile, uncontrolled environment, and the
ActionForms are designed to compensate for that.

But keep in mind that ActionForms are just for HTML Form input. They are
not expected to be used as anything but buffers for the html form tags.
You do not have to use them to retrieve widgets, just to send widgets
data they need to store.

Once the ActionForm is validated, the BeanUtils can be a very handy way
to copy the data over to your native beans. Usually, you just need to
define your ActionForm properties to match your native bean property
names. The problem is, you need a place to stand if the data fails
validation, and can't be transferred to your native beans. There lies
the rub.












--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts Design question

[Ted Husted]

Ted Husted wrote:
> If you find something that works better for you, be sure to report back.
> We aren't jealous ;-) Adopt and adapt.

Or, if you find one I haven't listed here, be sure to let me know. 

http://husted.com/struts/links.htm#mvc/frameworks


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts Design question

[Ted Husted]

Jon Wall wrote:
> 1.  The String/boolean requirement.  Everything I'd
> tested happened to be String or boolean, but Ted
> pointed out this wouldn't work for nested tags.  I'm
> assuming, then, that the ActionForm performs another
> function that I hadn't thought about - converting the
> String and boolean props that you're bringing in on
> the web to the navtive structure used by the backend.
> Is this true?  So what you're telling me is...I not
> only need to create an ActionForm class for each of my
> many components (100+) that actually implements each
> of the public methods, but for each of the non
> String/boolean properties I need to make a sort of
> formatter method.  

The ActionForm is really about buffering. It gives the HTML controls
persistance, until the data can be validated and/of converted to your
native structures. What happens when someone tries to toss "47a" at an
Integer property? HTTP is a hostile, uncontrolled environment, and the
ActionForms are designed to compensate for that. 

But keep in mind that ActionForms are just for HTML Form input. They are
not expected to be used as anything but buffers for the html form tags.
You do not have to use them to retrieve widgets, just to send widgets
data they need to store.

Once the ActionForm is validated, the BeanUtils can be a very handy way
to copy the data over to your native beans. Usually, you just need to
define your ActionForm properties to match your native bean property
names. The problem is, you need a place to stand if the data fails
validation, and can't be transferred to your native beans. There lies
the rub.


> And keep up with this process with
> every new component, and more difficult yet keep up
> with every new method on existing components.  Eeek.
> I know that I can automate this kind of thing...but it
> might be enough to keep me from using this framework.
> I understand the ROI theory and all that, but the
> unfortunate reality is that my development schedule is
> way too tight to take time out to work on something
> like this.  Am I grasping if I ask if there's any
> generic tools out there to do something like this?

If you find something that works better for you, be sure to report back.
We aren't jealous ;-) Adopt and adapt.



> 2.  This also explains my original troubles with my
> Save action I think, because I was trying to nest my
> components.  The real issue is that i need to call
> WidgetForm.setWidget() to initialize my widget's
> properties to what is already in the database before
> Struts autopopulates the widget properties using
> values from the form.  My new understanding of the
> Struts paradigm (please correct me if I'm wrong) is
> that the ActionForm shouldn't nest the components, but
> rather should mirror it and not contain the widget at
> all.  Let Struts autopopulate the ActionForm, and then
> use BeanUtils.populate() to copy the info over.

In practice, most pre-existing components are not suited for use as a
buffer for HTML controls, which is what the ActionForms do. If a
component is suited as a buffer for a HTML control, then there is no
reason not to nest it.

A good candidate for a HTML buffer uses a String or boolean for storage,
and can store invalid input before committing it to your model.
Generally, most components are designed to do exactly the opposite --
accept or reject input, period.


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts Design question

[Jon Wall]

Hi Ted -

Thanks for the input.  A light went on when I read
this...I'd initially wanted to just include my
existing components in a thin "composition" ActionForm
class - in other words, if I had a "Widget" component,
I'd create a WidgetForm class with getWidget() and
setWidget(), then my form would use the nested syntax,
ie "widget.prop1", "widget.prop2".  This was working
great for the Edit and Add actions, but was probably
the cause for my problems with the Save action.  I'm
realizing a couple of problems with this method...

1.  The String/boolean requirement.  Everything I'd
tested happened to be String or boolean, but Ted
pointed out this wouldn't work for nested tags.  I'm
assuming, then, that the ActionForm performs another
function that I hadn't thought about - converting the
String and boolean props that you're bringing in on
the web to the navtive structure used by the backend. 
Is this true?  So what you're telling me is...I not
only need to create an ActionForm class for each of my
many components (100+) that actually implements each
of the public methods, but for each of the non
String/boolean properties I need to make a sort of
formatter method.  And keep up with this process with
every new component, and more difficult yet keep up
with every new method on existing components.  Eeek. 
I know that I can automate this kind of thing...but it
might be enough to keep me from using this framework. 
I understand the ROI theory and all that, but the
unfortunate reality is that my development schedule is
way too tight to take time out to work on something
like this.  Am I grasping if I ask if there's any
generic tools out there to do something like this?  

2.  This also explains my original troubles with my
Save action I think, because I was trying to nest my
components.  The real issue is that i need to call
WidgetForm.setWidget() to initialize my widget's
properties to what is already in the database before
Struts autopopulates the widget properties using
values from the form.  My new understanding of the
Struts paradigm (please correct me if I'm wrong) is
that the ActionForm shouldn't nest the components, but
rather should mirror it and not contain the widget at
all.  Let Struts autopopulate the ActionForm, and then
use BeanUtils.populate() to copy the info over.  



thanks again for any help...
-jon



--- Ted Husted <[EMAIL PROTECTED]> wrote:
> Jon Wall wrote:
> > 
> > I've been lurking on this list for a while, and I
> > finally have time to look hard at Struts for a web
> > application that I'm working on. I have a coupla
> > questions.. 1. This first question I found
> reference
> > to in the archives
> >
>
(http://www.mail-archive.com/struts-user@jakarta.apache.org/msg18281.html)
> > but couldn't find an answer.
> 
> We tried making the ActionForm an interface in the
> first place, but, in
> practice, there were simply too many side effects. 
> 
>
http://www.mail-archive.com/struts-dev%40jakarta.apache.org/msg03590.html
> 
>
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg08070.html
> 
> If your JavaBean only uses String and boolean
> properties, and doesn't
> make immediate state changes to your model, you can
> nest it and use the
> dotted syntax. Otherwise, it's a wild goose chase.
> 
> 
> > In the application I'm
> > working on the business logic is already written
> and
> > is being added to by another team (it's supporting
> > other applications besides the web). So I've got a
> > whole slew of JavaBeans (100+) already written for
> me,
> > but now I'm facing the task of wrapping them in
> > ActionForm subclasses, cursing under my breath
> that it
> > isn't an interface. I understand that the purpose
> of
> > the ActionForm is as a buffer..perform validation
> and
> > all that. But my beans already contain the
> validation!
> > Besides, performing the validation in the
> ActionForm
> > is effectively tying business logic (data
> validation)
> > to the web framework dontya think?
> 
> It's really more about correction than validation.
> The validate method
> can wrap methods from the business layer, or the
> Action can do that
> instead and then return the ActionForm itself. But
> the main thing is
> that most existing beans expect native types that
> can't be properly
> represented by a HTML control.
> 
> Your beans may contain validation, but can they
> return the invalid input
> to the user for correction? That's what ActionForms
> are for. To buffer
> data so it ~can be~ validated, and returned for
> correction if it is not.
> 
> So, you take the data from the ActionForm, and
> present it to your bean.
> If your bean rejects it, you use the ActionForm to
> ferry the whole
> she-bang back to the user, so they can fix it and
> try again.
> 
> The ActionForm also serves as firewall, since the
> autopopulation
> mechanism can be used to affect any public method on
> your JavaBean, not
> just the ones you put on the form. This is
> exploitable by a hostile
> user.
> 
> 

Re: Struts Design question

[Edward Q. Bridges]

i believe that you could subclass ActionServlet and implement the
processPreprocess method.  this is called before processActionForm and
processPopulate.


On Fri, 7 Dec 2001 13:08:10 -0800 (PST), Jon Wall wrote:

.
.
.
>having a problem with the Save action. The issue is
>that I need to retrieve the object from the datastore
>(using the id) *before* the ActionForm is populated
>with the request parameters. What I'd like is to have



 ed.q.bridges
 tel. 089-368179.552
 fax 089-368179.79
 osterwaldstraße 10
 (haus F eingang 21)
 80805 münchen





--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts Design question - followup

[Matt Goodall]

On Fri, 2001-12-07 at 22:37, Jon Wall wrote:
> Hi Brian - 
> 
> Thanks for the responses.  Some more information and
> clarification...
> 
> > Well, I put data type and required field validation
> > only in the bean.
> 
> I'm doing this type of validation on the client-side
> in JavaScript already.  I prefer to keep it here as
> it's not too much work and it's much faster than doing
> it server side.  

And what happens when the user has JavaScript turned off?

You need to perform the validation server-side too. Client-side
validation should only really be used to improve usability by avoiding a
trip to the server (as you point out).

Cheers, Matt


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts Design question

[Ted Husted]

Jon Wall wrote:
> 
> I've been lurking on this list for a while, and I
> finally have time to look hard at Struts for a web
> application that I'm working on. I have a coupla
> questions.. 1. This first question I found reference
> to in the archives
> (http://www.mail-archive.com/struts-user@jakarta.apache.org/msg18281.html)
> but couldn't find an answer.

We tried making the ActionForm an interface in the first place, but, in
practice, there were simply too many side effects. 

http://www.mail-archive.com/struts-dev%40jakarta.apache.org/msg03590.html

http://www.mail-archive.com/struts-user@jakarta.apache.org/msg08070.html

If your JavaBean only uses String and boolean properties, and doesn't
make immediate state changes to your model, you can nest it and use the
dotted syntax. Otherwise, it's a wild goose chase.


> In the application I'm
> working on the business logic is already written and
> is being added to by another team (it's supporting
> other applications besides the web). So I've got a
> whole slew of JavaBeans (100+) already written for me,
> but now I'm facing the task of wrapping them in
> ActionForm subclasses, cursing under my breath that it
> isn't an interface. I understand that the purpose of
> the ActionForm is as a buffer..perform validation and
> all that. But my beans already contain the validation!
> Besides, performing the validation in the ActionForm
> is effectively tying business logic (data validation)
> to the web framework dontya think?

It's really more about correction than validation. The validate method
can wrap methods from the business layer, or the Action can do that
instead and then return the ActionForm itself. But the main thing is
that most existing beans expect native types that can't be properly
represented by a HTML control.

Your beans may contain validation, but can they return the invalid input
to the user for correction? That's what ActionForms are for. To buffer
data so it ~can be~ validated, and returned for correction if it is not.

So, you take the data from the ActionForm, and present it to your bean.
If your bean rejects it, you use the ActionForm to ferry the whole
she-bang back to the user, so they can fix it and try again.

The ActionForm also serves as firewall, since the autopopulation
mechanism can be used to affect any public method on your JavaBean, not
just the ones you put on the form. This is exploitable by a hostile
user.


> Rules such as no
> invoice numbers under 1000 (Ted's example) should be
> handled by the business logic, and given my situation
> (probably a common one), this logic needs to be shared
> between applications. I can't go into the server
> system and fit ActionForm into the class heirarchy,
> but I sure could have thrown an interface in there.

It should not be in your heirarchy, but used to transfer data *to* your
heirarchy. One good way to do this is to match the ActionForm properties
to the properties on your JavaBeans, and use the reflection methods in
BeanUtils to punch it over. If you put describe and populate together,
you can populate just about anything from just about anything.



> Input on this is appreciated. 2. This has to have come
> up before, but I couldn't find any references. All of
> my JavaBeans map to persistent components, all of
> which have id's. I've written some actions to display
> lists of these components and the like and everything
> works great. I also started to try the Add/Edit/Save
> pattern, which occurs everywhere in the app, and I'm
> having a problem with the Save action. The issue is
> that I need to retrieve the object from the datastore
> (using the id) *before* the ActionForm is populated
> with the request parameters.
> What I'd like is to have
> the bean populated from the database, and then any
> parameters that are present on the request object set
> on the bean, then persist. I can't figure out how to
> initialize the bean to the datastore before it gets to
> me in the Action. 

Go to the Action first, populate the ActionForm and then forward to the
JSP. The form tags will see the ActionForm, and use it to populate
themselves. Then when the form is submitted, it is populated from the
request parameters "again", closing the loop.


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Struts Design question - followup

[Jon Wall]

Hi Brian - 

Thanks for the responses.  Some more information and
clarification...

> Well, I put data type and required field validation
> only in the bean.

I'm doing this type of validation on the client-side
in JavaScript already.  I prefer to keep it here as
it's not too much work and it's much faster than doing
it server side.  

> You can populate your databean in your action object
> based on DB data since
> the action object is called before the JSP page is
> generated.

I know, but then I have to populate the bean with the
request parameters myself, right?  Struts does the
auto populating before it hands off to me...only it's
not working because the bean hasn't been
"initialized".


thanks..
-jon


--- [EMAIL PROTECTED] wrote:
> 
> Let me try to venture a few responses...
> 
> > But my beans already contain the validation!
> Besides, performing the
> validation in the ActionForm is effectively tying
> business logic (data
> validation) to the web framework dontya think?
> 
> Well, I put data type and required field validation
> only in the bean.
> Validation that is more advanced than that, or based
> on business rules
> should be in your app server (if you have one), or
> in the action object.
> 
> >I need to retrieve the object from the datastore
> (using the id) *before*
> the ActionForm is populated with the request
> parameters.
> 
> You can populate your databean in your action object
> based on DB data since
> the action object is called before the JSP page is
> generated.
> 
> >  the user never submits the form and goes to a
> different section of the
> site. How would I get the bean out of the session?
> 
> All active databeans for a session are stored under
> the key:
> org.apache.struts.action.FORM_BEANS.  You can get
> ahold of this collection
> and clear it out (save the current bean for the page
> you are on).  This is
> sort of a hack, so maybe there is another better way
> to do it..
> 
> Brian
> 
> 
> 
> 
> 
> 
>  
> Jon Wall
> 
>  
>  Struts Users Mailing List
> <[EMAIL PROTECTED]>
> o.com>   cc:
> 
>  
>  Subject:   
>  Struts Design question 
>  
> 12/07/2001  
> 
>  
> 03:08 PM
> 
>  
> Please respond  
> 
>  
> to "Struts  
> 
>  
> Users Mailing   
> 
>  
> List"   
> 
>  
> 
> 
>  
> 
> 
>  
> 
> 
> 
> 
> I've been lurking on this list for a while, and I
> finally have time to look hard at Struts for a web
> application that I'm working on. I have a coupla
> questions.. 1. This first question I found reference
> to in the archives
>
(http://www.mail-archive.com/struts-user@jakarta.apache.org/msg18281.html)
> but couldn't find an answer. In the application I'm
> working on the business logic is already written and
> is being added to by another team (it's supporting
> other applications besides the web). So I've got a
> whole slew of JavaBeans (100+) already written for
> me,
> but now I'm facing the task of wrapping them in
> ActionForm subclasses, cursing under my breath that
> it
> isn't an interface. I understand that the purpose of
> the ActionForm is as a buffer..perform validation
> and
> all that. But my beans already contain the
> validation!
> Besides, performing the validation in the ActionForm
> is effectively tying business logic (data
> validation)
> to the web framework dontya think? Rules such as no
> invoice numbers under 1000 (Ted's example) should be
> handled by the business logic, and given my
> situation
> (probably a common one), this logic needs to be
> shared
> between applications. I can't go into the server
> system and fit ActionForm into the class heirarchy,
> but I sure could have thrown an interface in there.
> Input on this is appreciated. 2. This has to have
> come
> up before, but I couldn't find any references. All
> o

Re: Struts Design question

[Brian . Duchouquette]

Let me try to venture a few responses...

> But my beans already contain the validation! Besides, performing the
validation in the ActionForm is effectively tying business logic (data
validation) to the web framework dontya think?

Well, I put data type and required field validation only in the bean.
Validation that is more advanced than that, or based on business rules
should be in your app server (if you have one), or in the action object.

>I need to retrieve the object from the datastore (using the id) *before*
the ActionForm is populated with the request parameters.

You can populate your databean in your action object based on DB data since
the action object is called before the JSP page is generated.

>  the user never submits the form and goes to a different section of the
site. How would I get the bean out of the session?

All active databeans for a session are stored under the key:
org.apache.struts.action.FORM_BEANS.  You can get ahold of this collection
and clear it out (save the current bean for the page you are on).  This is
sort of a hack, so maybe there is another better way to do it..

Brian




   

Jon Wall   


o.com>   cc:   

 Subject: Struts Design question   

12/07/2001 

03:08 PM   

Please respond 

to "Struts 

Users Mailing  

List"  

   

   





I've been lurking on this list for a while, and I
finally have time to look hard at Struts for a web
application that I'm working on. I have a coupla
questions.. 1. This first question I found reference
to in the archives
(http://www.mail-archive.com/struts-user@jakarta.apache.org/msg18281.html)
but couldn't find an answer. In the application I'm
working on the business logic is already written and
is being added to by another team (it's supporting
other applications besides the web). So I've got a
whole slew of JavaBeans (100+) already written for me,
but now I'm facing the task of wrapping them in
ActionForm subclasses, cursing under my breath that it
isn't an interface. I understand that the purpose of
the ActionForm is as a buffer..perform validation and
all that. But my beans already contain the validation!
Besides, performing the validation in the ActionForm
is effectively tying business logic (data validation)
to the web framework dontya think? Rules such as no
invoice numbers under 1000 (Ted's example) should be
handled by the business logic, and given my situation
(probably a common one), this logic needs to be shared
between applications. I can't go into the server
system and fit ActionForm into the class heirarchy,
but I sure could have thrown an interface in there.
Input on this is appreciated. 2. This has to have come
up before, but I couldn't find any references. All of
my JavaBeans map to persistent components, all of
which have id's. I've written some actions to display
lists of these components and the like and everything
works great. I also started to try the Add/Edit/Save
pattern, which occurs everywhere in the app, and I'm
having a problem with the Save action. The issue is
that I need to retrieve the object from the datastore
(using the id) *before* the ActionForm is populated
with the request parameters. What I'd like is to have
the bean populated from the database, and then any
parameters that are present on the request object set
on the bean, then persist. I can't figure out how to
initialize the bean to the datastore before it gets to
me in the Action. If I make the ActionForm session
scoped, it works great...is this the common practice?
If so, how is cleanup performed? IE, user clicks to
Edit Widget 137, my EditWidgetAction class populates
WidgetForm and sticks it in the session, the user
never submits the form and goes to a different section
of the site. How wo

RE: Struts Design Question

[Aaron Ravenberg]

Yes you can do the add/edit all on the same form.  If have a database
generated code or key you can put that in a hidden field.  When in the
action examine the form or request obj to see if that key is there, if it is
you have a modify, if not add the record.

Have you page that lists the songs pass a the code/key as a parameter to the
SongForm.jsp. Then you can use the jsp:useBean as follows:


 


Then to pre populate the form you can make a DataBase call in your form
setSongKey() method and use the result to set the other values in the form.

For a delete you can have a second form on the same page (with its own
submit button) that has the songKey set into the SongDeleteForm and the
submit is mapped to a DeleteAction that just uses the key to delete the
record.

I am new at the struts stuff myself, so these may not be the best ways to
accomplish what you are trying to do, but I know it works.  So anyone else
please feel free to critique.

Aaron


-Original Message-
From: Shriver, Ryan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 08, 2001 9:30 AM
To: '[EMAIL PROTECTED]'
Subject: Struts Design Question


Hello all,
I downloaded Struts last week and have enjoyed playing with it. I've come
upon a design problem and I was hoping some folks on this list could help
solve it. I've had no luck finding an answer in the mail archives.

I want to maintain a list of songs. Through a web interface, I want to add a
new song, edit information about an existing song (composer, artist, etc)
and also delete a song. Under the covers this will do some sort of database
insert, update and delete, respectively.

The forms for adding a new song and editing an existing song are practically
identical. They contain the same field names with the difference being edit
pre-populates the fields with the existing values of a song whereas the
fields are blank for add. Question #1: Can one ActionForm suffice for both
add and edit form pages? My gut says yes, but I want to make sure.

Actions. In the simplest scenario, I could create separate actions for all
operations. I'd have AddSongAction, EditSongAction and DeleteSongAction
classes each with their own logic in perform(). This would work, but there's
something that bothers me about having three different classes performing
operations on one entity. It seems like overkill.

DispatchActions. I saw the post about using DispatchAction to have multiple
methods in a single Action class. I really like this approach, as I could
have insert, update and delete methods in my Action class. However, the
input="" attribute in the action mapping definition (in struts-config.xml)
is shared for all of them. So if I have separate addsong.jsp and
editsong.jsp form pages sharing the same Action, and a validation error
occurs, Struts can only return to one (whatever input="" is). So this won't
work.

Question #2: Is there a happy medium between these two approaches?

One idea that I haven't worked through is using one songform.jsp page for
add/edit/delete. Calling songform.jsp?method=add would produce a blank page
for entering a new song. Songform.jsp?method=edit&id=1234 would populate the
form with values from a song whose id = 1234. From here one could edit or
delete the selected song. In Struts I'd use the DispatchAction to pass all
add/edit/delete requests to one Action class. Because all were using the
same form, the input="" attribute problem above would be avoided.

Question #3: Will this approach work? Can anyone offer a better solution for
this problem?

Thanks for the feedback.

-ryan

Re: Struts design question

[Ted Husted]

> Why do Action, ActionForm and ActionMappings classes keep references
to the ActionServlet?

So that they can access the many features available through the
servlet, like logging and (lately) a JBDC DataSource.

The ActionServlet is like a switchboard, and the references a way they
can dial "0" for the operator.

For more about how Struts works, there is a  "Walking Tour of the
Example Application" at 

< http://husted.com/about/struts/ >

along with a sample JBDC applicaton. 

*** REPLY SEPARATOR  ***

On 12/27/2000 at 6:41 PM Punyansky, Alex wrote:

Hi,

I'm going through Struts code trying to understand how this whole thing
works. I could figure out almost everything except one thing: Why do
Action,
ActionForm and ActionMappings classes keep references to the
ActionServlet?
Can anybody explain this?

Thanks

Alex