RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion)
See intermixed. On Tue, 12 Nov 2002, Martin Cooper wrote: Date: Tue, 12 Nov 2002 08:36:13 -0800 From: Martin Cooper [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) -Original Message- From: Sri Sankaran [mailto:Sri.Sankaran;sas.com] Sent: Tuesday, November 12, 2002 7:56 AM To: Struts Users Mailing List Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() for m confusion) No sweat. The reason this discussion got so off whack was because I tried to slam a square peg in a round hole by continuing with Kris' example (Edit Save actions) to make my point -- bad idea. So what *is* my scenario? Consider for example, a master-detail pair of pages. The master page display a list of employee names. The detail page -- which is displayed when a user selects an employee from the master page -- displays a collection of (possibly editable) fields that describe the selected employee. The form-bean associated with the detail page is your typical EmployeeBean object. Even if the struts-config is set up with the right action mapping like action path=/detail type=com.acme.DetailAction name=employeeBean/ how can Struts know that the user selected the user 'John Smith' on the master page? Ergo, the need to create the necessary form bean in the action for the master page. We cannot wait for/depend on Struts to create it. I don't like the fact that the MasterAction needs to have knowledge of the requirements for the detail page (the type of bean, the name under which it is accessed) -- or maybe that isn't so bad?? Yes, it is bad. Actually, it's a bit of a mystery to me that this issue doesn't come up more often (or perhaps I just always miss it). One solution (which Craig would probably shoot me for mentioning :) Yep :-). For those who tuned in late, I am *not* a fan of this -- in part because it has some pretty unexpected semantics w.r.t. form beans. is action chaining. That is, your master action chains (i.e. forwards) to a detail action that prepares the bean for the detail page. There are some problems with chaining actions, though, so it's not the best way to handle this. An alternative is to split your actions into two phases, and keep the logic of those two phases separate, using additional classes. This is what I'm doing now, and it's pretty clean. Unfortunately, at this point my employer owns the code, but I'll see if I can wrest it free at some point. ;-) If you know what your destination action's path is, you actually *can* divine what form bean is needed pretty easily. Let's assume we're talking about the ultimate action at path /foo: ApplicationConfig appConfig = (ApplicationConfig) request.getAttribute(Globals.APPLICATION_KEY); ActionConfig actionConfig = appConfig.findActionConfig(/foo); String name = actionConfig.getName(); // Form bean name String attribute = actionConfig.getAttribute(); // Attribute to store under String scope = actionConfig.getScope(); // Scope to store in FormBeanConfig fbConfig = appConfig.findFormBeanConfig(name); Now you've got all the metadata you need to dynamically instantiate the appropriate form bean, and store it under the appropriate attribute in the appropriate scope, without hard coding any of this stuff. -- Martin Cooper Craig -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: request.setAttribute() form confusion
Nevermind, answering my own question ...
actions in the Struts examples don't use the second line of code, so the
answer is no, you don't need the two together.
Susan
On 11/11/2002 01:34:16 PM Susan Bradeen wrote:
If I have this code, which appears to be good practice, in the beginning
of my pre-action's execute() method:
if (form == null) {
form = new SomeForm();
if (request.equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), form);
}
else {
request.getSession().setAttribute(mapping.getAttribute(), form);
}
}
SomeForm myForm = (SomeForm)form;
/* populate form values ... */
Do I also need to use the following line at the end (after form
population), or is this basically accomplishing the same as the above?
request.setAttribute(mapping.getAttribute(), myForm);
Thanks,
Susan Bradeen
--
To unsubscribe, e-mail:
mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-user-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: request.setAttribute() form confusion
You shouldn't ever have to create the form yourself if you: - declare the form-bean in your config file - use the name of the form you declared in the action mapping's name attribute form-bean name=myForm ... / ... action path=/somePath name=myForm ... / That should suffice. What you should find is that the form is created for you. Doing things as I mention simplifies you actions so that they can just expect the form to be there. If the form is not there you will probably NPE. That would indicate that you didn't create the association (by setting name=myForm) or Struts wasn't able to create the form for some odd reason. Susan Bradeen wrote: Nevermind, answering my own question ... actions in the Struts examples don't use the second line of code, so the answer is no, you don't need the two together. Susan -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: request.setAttribute() form confusion
Susan,
Here's a response to a different thread with the same type of code block:
http://marc.theaimsgroup.com/?l=struts-userm=103669042429912w=2
I understand this type of approach is used in the example app, but I'd say it's
anything but good practice. In general, if you have an action that's going to
pre-populate a form, it's action mapping should include a name (or attribute)
attribute for the appropriate form. Struts will take care of finding or
creating the form, ensuring that it's stored in the proper scope, and passing
it to the execute/perform method. All you need to do then is cast it to the
appropriate type.
Quoting Susan Bradeen [EMAIL PROTECTED]:
If I have this code, which appears to be good practice, in the beginning
of my pre-action's execute() method:
if (form == null) {
form = new SomeForm();
if (request.equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), form);
}
else {
request.getSession().setAttribute(mapping.getAttribute(), form);
}
}
SomeForm myForm = (SomeForm)form;
/* populate form values ... */
Do I also need to use the following line at the end (after form
population), or is this basically accomplishing the same as the above?
request.setAttribute(mapping.getAttribute(), myForm);
Thanks,
Susan Bradeen
--
To unsubscribe, e-mail:
mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-user-help;jakarta.apache.org
--
Kris Schneider mailto:kris;dotech.com
D.O.Tech http://www.dotech.com/
--
To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
[SIDEBAR] Form population (Was RE: request.setAttribute() form confusion)
While that is true, other than in the case of blank forms, isn't it true that one rarely depends on Struts to auto-generate the form bean? If you are presenting data, the form is pre-populated with such data. This data is typically derived by an earlier action -- mediated by a business delegate. Say you have action-1 which is invoked when a page-1 is submitted. It does sundry business functions which includes getting the data necessary for the next page, page-2 say. In order for page-2 to pick up this data, action-1 must know the 'name' attribute for the action-mapping corresponding to page-2 and save the form-bean under this name in the appropriate scope. Is there a way around this issue? Sri -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 3:00 PM To: Struts Users Mailing List Subject: Re: request.setAttribute() form confusion You shouldn't ever have to create the form yourself if you: - declare the form-bean in your config file - use the name of the form you declared in the action mapping's name attribute form-bean name=myForm ... / ... action path=/somePath name=myForm ... / That should suffice. What you should find is that the form is created for you. Doing things as I mention simplifies you actions so that they can just expect the form to be there. If the form is not there you will probably NPE. That would indicate that you didn't create the association (by setting name=myForm) or Struts wasn't able to create the form for some odd reason. Susan Bradeen wrote: Nevermind, answering my own question ... actions in the Struts examples don't use the second line of code, so the answer is no, you don't need the two together. Susan -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion)
Doesn't doing things the way you are suggesting spread the business logic over the view and the controller? I have found that if you have a overall form which may or may not correspond to a db element but pulls in as nested forms the tables that it needs and controls the business logic to be a strong way of doing things. This means that Eddie's comment will still hold about letting struts manage the action form. Edgar -Original Message- From: Sri Sankaran [mailto:Sri.Sankaran;sas.com] Sent: Monday, November 11, 2002 2:51 PM To: 'Struts Users Mailing List' Subject: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) While that is true, other than in the case of blank forms, isn't it true that one rarely depends on Struts to auto-generate the form bean? If you are presenting data, the form is pre-populated with such data. This data is typically derived by an earlier action -- mediated by a business delegate. Say you have action-1 which is invoked when a page-1 is submitted. It does sundry business functions which includes getting the data necessary for the next page, page-2 say. In order for page-2 to pick up this data, action-1 must know the 'name' attribute for the action-mapping corresponding to page-2 and save the form-bean under this name in the appropriate scope. Is there a way around this issue? Sri -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 3:00 PM To: Struts Users Mailing List Subject: Re: request.setAttribute() form confusion You shouldn't ever have to create the form yourself if you: - declare the form-bean in your config file - use the name of the form you declared in the action mapping's name attribute form-bean name=myForm ... / ... action path=/somePath name=myForm ... / That should suffice. What you should find is that the form is created for you. Doing things as I mention simplifies you actions so that they can just expect the form to be there. If the form is not there you will probably NPE. That would indicate that you didn't create the association (by setting name=myForm) or Struts wasn't able to create the form for some odd reason. Susan Bradeen wrote: Nevermind, answering my own question ... actions in the Struts examples don't use the second line of code, so the answer is no, you don't need the two together. Susan -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
Re: request.setAttribute() form confusion
Thank you for the help Eddie and Kris. I've already got my action mapping
set up just as you say to have them, so I'll go back to trusting Struts
with the form creation.
Susan
On 11/11/2002 02:00:55 PM Kris Schneider wrote:
Susan,
Here's a response to a different thread with the same type of code
block:
http://marc.theaimsgroup.com/?l=struts-userm=103669042429912w=2
I understand this type of approach is used in the example app, but I'd
say it's
anything but good practice. In general, if you have an action that's
going to
pre-populate a form, it's action mapping should include a name (or
attribute)
attribute for the appropriate form. Struts will take care of finding or
creating the form, ensuring that it's stored in the proper scope, and
passing
it to the execute/perform method. All you need to do then is cast it to
the
appropriate type.
Quoting Susan Bradeen [EMAIL PROTECTED]:
If I have this code, which appears to be good practice, in the
beginning
of my pre-action's execute() method:
if (form == null) {
form = new SomeForm();
if (request.equals(mapping.getScope())) {
request.setAttribute(mapping.getAttribute(), form);
}
else {
request.getSession().setAttribute(mapping.getAttribute(),
form);
}
}
SomeForm myForm = (SomeForm)form;
/* populate form values ... */
Do I also need to use the following line at the end (after form
population), or is this basically accomplishing the same as the above?
request.setAttribute(mapping.getAttribute(), myForm);
Thanks,
Susan Bradeen
--
To unsubscribe, e-mail:
mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-user-help;jakarta.apache.org
--
Kris Schneider mailto:kris;dotech.com
D.O.Tech http://www.dotech.com/
--
To unsubscribe, e-mail:
mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail:
mailto:struts-user-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion)
Actually, the way I have tried to describe keeps business logic *entirely* out of the form-beans and uses them only as the medium of transporting data between the model and the view. I prefer not to put *any* business logic in the form beans (code re-use, lack of portability, model/controller separation -- take your pick). In other words, the form-bean is just a dumb holder of information; it doesn't know where the data came from or where it goes. Is that not the recommended purpose? Are you suggesting that the form-bean be responsible for loading/unloading the data? Sri -Original Message- From: edgar [mailto:edgar;blue-moose.net] Sent: Monday, November 11, 2002 3:04 PM To: 'Struts Users Mailing List' Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) Doesn't doing things the way you are suggesting spread the business logic over the view and the controller? I have found that if you have a overall form which may or may not correspond to a db element but pulls in as nested forms the tables that it needs and controls the business logic to be a strong way of doing things. This means that Eddie's comment will still hold about letting struts manage the action form. Edgar -Original Message- From: Sri Sankaran [mailto:Sri.Sankaran;sas.com] Sent: Monday, November 11, 2002 2:51 PM To: 'Struts Users Mailing List' Subject: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) While that is true, other than in the case of blank forms, isn't it true that one rarely depends on Struts to auto-generate the form bean? If you are presenting data, the form is pre-populated with such data. This data is typically derived by an earlier action -- mediated by a business delegate. Say you have action-1 which is invoked when a page-1 is submitted. It does sundry business functions which includes getting the data necessary for the next page, page-2 say. In order for page-2 to pick up this data, action-1 must know the 'name' attribute for the action-mapping corresponding to page-2 and save the form-bean under this name in the appropriate scope. Is there a way around this issue? Sri -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 3:00 PM To: Struts Users Mailing List Subject: Re: request.setAttribute() form confusion You shouldn't ever have to create the form yourself if you: - declare the form-bean in your config file - use the name of the form you declared in the action mapping's name attribute form-bean name=myForm ... / ... action path=/somePath name=myForm ... / That should suffice. What you should find is that the form is created for you. Doing things as I mention simplifies you actions so that they can just expect the form to be there. If the form is not there you will probably NPE. That would indicate that you didn't create the association (by setting name=myForm) or Struts wasn't able to create the form for some odd reason. Susan Bradeen wrote: Nevermind, answering my own question ... actions in the Struts examples don't use the second line of code, so the answer is no, you don't need the two together. Susan -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion)
...one rarely depends on Struts to auto-generate the form bean? If you changed rarely to almost always, I'd tend to agree with you ;-). I make a clear distinction between form creation/retrieval and population/modification. Take the typical: EditAction - JSP - SaveAction In general, the action mappings for both EditAction and SaveAction would use the same form bean. EditAction takes the form bean created/retrieved by Struts, populates/modifies it with data obtained from the business layer, and then forwards to the JSP for display. The user interacts with the page, submits to SaveAction which takes the form bean created/retrieved *and* populated/modified (from request params) by Struts and uses its data to interact with the business layer. So, I guess the key difference is that for EditAction the form bean is populated/modified with data from the business layer but for SaveAction it's done with data from request params. In both cases, Struts handles the form bean creation/retrieval. Quoting Sri Sankaran [EMAIL PROTECTED]: From: Sri Sankaran [mailto:Sri.Sankaran;sas.com] Sent: Monday, November 11, 2002 2:51 PM To: 'Struts Users Mailing List' Subject: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) While that is true, other than in the case of blank forms, isn't it true that one rarely depends on Struts to auto-generate the form bean? If you are presenting data, the form is pre-populated with such data. This data is typically derived by an earlier action -- mediated by a business delegate. Say you have action-1 which is invoked when a page-1 is submitted. It does sundry business functions which includes getting the data necessary for the next page, page-2 say. In order for page-2 to pick up this data, action-1 must know the 'name' attribute for the action-mapping corresponding to page-2 and save the form-bean under this name in the appropriate scope. Is there a way around this issue? Sri -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 3:00 PM To: Struts Users Mailing List Subject: Re: request.setAttribute() form confusion You shouldn't ever have to create the form yourself if you: - declare the form-bean in your config file - use the name of the form you declared in the action mapping's name attribute form-bean name=myForm ... / ... action path=/somePath name=myForm ... / That should suffice. What you should find is that the form is created for you. Doing things as I mention simplifies you actions so that they can just expect the form to be there. If the form is not there you will probably NPE. That would indicate that you didn't create the association (by setting name=myForm) or Struts wasn't able to create the form for some odd reason. Susan Bradeen wrote: Nevermind, answering my own question ... actions in the Struts examples don't use the second line of code, so the answer is no, you don't need the two together. Susan -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- Kris Schneider mailto:kris;dotech.com D.O.Tech http://www.dotech.com/ -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion)
...EditAction takes the form bean created/retrieved by Struts, populates/modifies it with... Wait a minute. What caused Struts to create the form bean? If that is form-bean associated with this action, the scenario I am describing is different. In my scenario, consecutive actions do not share the same form-bean. It's as if EditAction does its work and needs to prep *a*different*form* for the next screen. EditAction -- JSP -- SaveAction form-Aform-Bform-B Sri -Original Message- From: Kris Schneider [mailto:kris;dotech.com] Sent: Monday, November 11, 2002 4:17 PM To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) ...one rarely depends on Struts to auto-generate the form bean? If you changed rarely to almost always, I'd tend to agree with you ;-). I make a clear distinction between form creation/retrieval and population/modification. Take the typical: EditAction - JSP - SaveAction In general, the action mappings for both EditAction and SaveAction would use the same form bean. EditAction takes the form bean created/retrieved by Struts, populates/modifies it with data obtained from the business layer, and then forwards to the JSP for display. The user interacts with the page, submits to SaveAction which takes the form bean created/retrieved *and* populated/modified (from request params) by Struts and uses its data to interact with the business layer. So, I guess the key difference is that for EditAction the form bean is populated/modified with data from the business layer but for SaveAction it's done with data from request params. In both cases, Struts handles the form bean creation/retrieval. Quoting Sri Sankaran [EMAIL PROTECTED]: From: Sri Sankaran [mailto:Sri.Sankaran;sas.com] Sent: Monday, November 11, 2002 2:51 PM To: 'Struts Users Mailing List' Subject: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) While that is true, other than in the case of blank forms, isn't it true that one rarely depends on Struts to auto-generate the form bean? If you are presenting data, the form is pre-populated with such data. This data is typically derived by an earlier action -- mediated by a business delegate. Say you have action-1 which is invoked when a page-1 is submitted. It does sundry business functions which includes getting the data necessary for the next page, page-2 say. In order for page-2 to pick up this data, action-1 must know the 'name' attribute for the action-mapping corresponding to page-2 and save the form-bean under this name in the appropriate scope. Is there a way around this issue? Sri -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 3:00 PM To: Struts Users Mailing List Subject: Re: request.setAttribute() form confusion You shouldn't ever have to create the form yourself if you: - declare the form-bean in your config file - use the name of the form you declared in the action mapping's name attribute form-bean name=myForm ... / ... action path=/somePath name=myForm ... / That should suffice. What you should find is that the form is created for you. Doing things as I mention simplifies you actions so that they can just expect the form to be there. If the form is not there you will probably NPE. That would indicate that you didn't create the association (by setting name=myForm) or Struts wasn't able to create the form for some odd reason. Susan Bradeen wrote: Nevermind, answering my own question ... actions in the Struts examples don't use the second line of code, so the answer is no, you don't need the two together. Susan -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- Kris Schneider mailto:kris;dotech.com D.O.Tech http://www.dotech.com/ -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion)
I have interpreted that the form bean be the repository for the bulk of the business logic surrounding it's elements. Then I can use any number of JSP pages to display / modify / whatever with minimal knowledge of the basic business rule. I don't know if that is what was intended, it just appears natural to me. I also don't have a another tool which might control the business logic so that might be our difference. I don't like to put too much business logic in the database because that tends to force use of DB specific code. There is a program turbine which is reccomended to be used with struts which is designed to handle some of the database operations which might change my analysis, but I haven't had time to review it. What are you using to do the business model? Thanks. Edgar -Original Message- From: Sri Sankaran [mailto:Sri.Sankaran;sas.com] Sent: Monday, November 11, 2002 3:12 PM To: 'Struts Users Mailing List'; Edgar Dollin Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) Actually, the way I have tried to describe keeps business logic *entirely* out of the form-beans and uses them only as the medium of transporting data between the model and the view. I prefer not to put *any* business logic in the form beans (code re-use, lack of portability, model/controller separation -- take your pick). In other words, the form-bean is just a dumb holder of information; it doesn't know where the data came from or where it goes. Is that not the recommended purpose? Are you suggesting that the form-bean be responsible for loading/unloading the data? Sri -Original Message- From: edgar [mailto:edgar;blue-moose.net] Sent: Monday, November 11, 2002 3:04 PM To: 'Struts Users Mailing List' Subject: RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) Doesn't doing things the way you are suggesting spread the business logic over the view and the controller? I have found that if you have a overall form which may or may not correspond to a db element but pulls in as nested forms the tables that it needs and controls the business logic to be a strong way of doing things. This means that Eddie's comment will still hold about letting struts manage the action form. Edgar -Original Message- From: Sri Sankaran [mailto:Sri.Sankaran;sas.com] Sent: Monday, November 11, 2002 2:51 PM To: 'Struts Users Mailing List' Subject: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) While that is true, other than in the case of blank forms, isn't it true that one rarely depends on Struts to auto-generate the form bean? If you are presenting data, the form is pre-populated with such data. This data is typically derived by an earlier action -- mediated by a business delegate. Say you have action-1 which is invoked when a page-1 is submitted. It does sundry business functions which includes getting the data necessary for the next page, page-2 say. In order for page-2 to pick up this data, action-1 must know the 'name' attribute for the action-mapping corresponding to page-2 and save the form-bean under this name in the appropriate scope. Is there a way around this issue? Sri -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 3:00 PM To: Struts Users Mailing List Subject: Re: request.setAttribute() form confusion You shouldn't ever have to create the form yourself if you: - declare the form-bean in your config file - use the name of the form you declared in the action mapping's name attribute form-bean name=myForm ... / ... action path=/somePath name=myForm ... / That should suffice. What you should find is that the form is created for you. Doing things as I mention simplifies you actions so that they can just expect the form to be there. If the form is not there you will probably NPE. That would indicate that you didn't create the association (by setting name=myForm) or Struts wasn't able to create the form for some odd reason. Susan Bradeen wrote: Nevermind, answering my own question ... actions in the Struts examples don't use the second line of code, so the answer is no, you don't need the two together. Susan -- Eddie Bush -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion)
OK Eddie, what do you use to model the business logic? -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 6:16 PM To: 'Struts Users Mailing List' Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) My apologies - you were going after edgar - and rightfully so :-) edgar: Listen to Sri the wise ;-) Eddie Bush wrote: -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
RE: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion)
OK. We don't disagree much, accept in semantics. I do subclass the struts ActionForm in an abstract class and subclass everything else from that, but all the other business logic is separate and stands by itself. If I had to go to a different framework, I would replace the connector class. I do appreciate your comments. Thanks -Original Message- From: Eddie Bush [mailto:ekbush;swbell.net] Sent: Monday, November 11, 2002 7:01 PM To: 'Struts Users Mailing List' Subject: Re: [SIDEBAR] Form population (Was RE: request.setAttribute() form confusion) edgar wrote: OK Eddie, what do you use to model the business logic? Classes which aren't dependant on Struts ;-) -- To unsubscribe, e-mail: mailto:struts-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:struts-user-help;jakarta.apache.org
