Re: ActionForms for read-only data??
On Thu, 14 Jun 2001, Jonathan Asbell wrote: Craig, can you explain point number one Expose the data as JavaBeans *other than* the form bean. Is it that you are not using the form bean? Yes. I can think of many cases where you'd want to extract read-only data from beans other than the form bean when building a presentation layer, and I would feel pretty limited by a rule that said all the dynamic data you need for this page *must* come from the form bean. Now, if the data is already present in the form bean and you want to use it in a read-only fashion, that's OK too ... the important coordination issue between the business logic and presentation logic layers is which bean names you're using to communicate, and what properties are expected in each bean. Craig - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 14, 2001 1:19 PM Subject: Re: ActionForms for read-only data?? On Thu, 14 Jun 2001, hi there wrote: Craig, The ActionForm class definition seems to imply that it was intended to contain only editable data (i.e., the reset and validate methods). Distinguishing between read and write functionality in the enterprise systems I have developed was always a major advantage, both in extensibility and code maintainability, as usually each type of functionality had different processing requirments. It seems that if we mix read and write functionality into one ActionForm instance, we will have some bulky classes to maintain. Any comments? Thanks. There are probably multiple reasonable approaches to dealing with read-only data. Let's consider some of the ways you can do this: (1) Expose the data as JavaBeans *other than* the form bean: This is quite easy, since you can do things like bean:write to generate the output, logic: to test, and so on. However, you are mildly increasing the linkage between the model layer and the view layer -- now the developers have to agree on the bean name, and the properties to be used. The tradeoff is that you might be able to reuse beans (such as value objects in an EJB based app) that already exist. (2) Copy the read-only data into the form bean: This is particularly useful in several use cases: - You only want to access the data nested inside the html:form - You don't want to create the extra dependency on a bean name (since you can reference the form bean implicitly) - A particular property might be read-only in some uses of the form and read-write in others (see the username field of the RegistrationForm bean in the example application). However, adding new properties means going back and updating the form bean class every time, which can be tedious if it's not being automatically generated. In practice, I have used both techniques -- but in particular I find myself needing data outside the nested body of an html:form, in which case I really need to use technique (1) anyway. Part of my internal system documentation (for the various developers) is a clear description of the bean names (and scopes), and the properties that they expose, that the page developer can count on. This seems to deal with most of the manageability issues, but none of these apps have had a very long life yet since Struts has only been around a year :-). Craig McClanahan From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: ActionForms for read-only data?? Date: Mon, 11 Jun 2001 17:01:31 -0700 (PDT) On Mon, 11 Jun 2001 [EMAIL PROTECTED] wrote: I have a Struts theory question on use of action forms versus java beans for read-only data. We have extended workflow on our website such that the same form can look a bit different depending on where you are in the workflow. For example, the quote request will have limit and retention fields in the business request section. Once you get to quote, those fields are read-only and there's an additional quote amount field. When the client requests binder, all those fields are read-only and there is a checkbox. Once bound, everything is read-only. There is some disagreement on the team as to how to handle this case. We will obviously have four JSPs, one for each of these presentations. The question is the data mapping to beans. Half of the team feels that to use Struts in its purest sense, we need to have java beans that represent the read-only data, and action forms to represent the editable data. That would mean four action forms, one for each JSP. The other half of the team wants to re-use the same action form for all four cases, bean:define it in the session
Re: ActionForms for read-only data??
Craig, The ActionForm class definition seems to imply that it was intended to contain only editable data (i.e., the reset and validate methods). Distinguishing between read and write functionality in the enterprise systems I have developed was always a major advantage, both in extensibility and code maintainability, as usually each type of functionality had different processing requirments. It seems that if we mix read and write functionality into one ActionForm instance, we will have some bulky classes to maintain. Any comments? Thanks. From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: ActionForms for read-only data?? Date: Mon, 11 Jun 2001 17:01:31 -0700 (PDT) On Mon, 11 Jun 2001 [EMAIL PROTECTED] wrote: I have a Struts theory question on use of action forms versus java beans for read-only data. We have extended workflow on our website such that the same form can look a bit different depending on where you are in the workflow. For example, the quote request will have limit and retention fields in the business request section. Once you get to quote, those fields are read-only and there's an additional quote amount field. When the client requests binder, all those fields are read-only and there is a checkbox. Once bound, everything is read-only. There is some disagreement on the team as to how to handle this case. We will obviously have four JSPs, one for each of these presentations. The question is the data mapping to beans. Half of the team feels that to use Struts in its purest sense, we need to have java beans that represent the read-only data, and action forms to represent the editable data. That would mean four action forms, one for each JSP. The other half of the team wants to re-use the same action form for all four cases, bean:define it in the session, and use bean:write to print out the data if read-only. The major advantage is simplicity - we have one bean that represents all of the data - there is no need to understand what part of the workflow we are in when translating the data from the data model to the presentation layer beans. It is also easier to understand for an HTML programmer or developer that the same bean is used regardless of whether it is a bean:write or any of the html tags. We certainly don't want to end up in a position where we have broken the framework and hurt our extensibility in future releases. The first scenario would seem to follow the framework more closely, but in this special case, is it a problem to deviate and use the ActionForm for what it is - a bean? We would appreciate any advice and experiences. Thank you. Ted covered a couple of the issues in his response -- I'd like to add a few more thoughts. I don't think there are cut-and-dried answers to an issue like this, so it's a question of balancing the tradeoffs. If you are using the same JSP page itself for the different views of the same information, you probably already have conditional logic in it about whether to make a field editable or read only. In such a case, I don't think it necessarily violates the Struts philosophy to use the same ActionForm bean. In fact, the Struts example application includes a miniature example of this use case like this: logic:equal name=registrationForm property=action scope=request value=Create html:text property=username size=16 maxlength=16/ /logic:equal logic:equal name=registrationForm property=action scope=request value=Edit bean:write name=registrationForm property=username/ /logic:equal which makes the username field editable in create mode, but read only in edit mode. Note that you do not actually have to use bean:define to introduce the ActionForm bean if it's the same bean used in your html:form tag -- the standard Struts logic will introduce it for you. It can be used exactly like any other bean, from within the nested body of the html:form. Lisa Stephens GeneralCologne Re Trumbull, CT 203 328 5227 Craig McClanahan _ Get your FREE download of MSN Explorer at http://explorer.msn.com
Re: ActionForms for read-only data??
On Thu, 14 Jun 2001, hi there wrote: Craig, The ActionForm class definition seems to imply that it was intended to contain only editable data (i.e., the reset and validate methods). Distinguishing between read and write functionality in the enterprise systems I have developed was always a major advantage, both in extensibility and code maintainability, as usually each type of functionality had different processing requirments. It seems that if we mix read and write functionality into one ActionForm instance, we will have some bulky classes to maintain. Any comments? Thanks. There are probably multiple reasonable approaches to dealing with read-only data. Let's consider some of the ways you can do this: (1) Expose the data as JavaBeans *other than* the form bean: This is quite easy, since you can do things like bean:write to generate the output, logic: to test, and so on. However, you are mildly increasing the linkage between the model layer and the view layer -- now the developers have to agree on the bean name, and the properties to be used. The tradeoff is that you might be able to reuse beans (such as value objects in an EJB based app) that already exist. (2) Copy the read-only data into the form bean: This is particularly useful in several use cases: - You only want to access the data nested inside the html:form - You don't want to create the extra dependency on a bean name (since you can reference the form bean implicitly) - A particular property might be read-only in some uses of the form and read-write in others (see the username field of the RegistrationForm bean in the example application). However, adding new properties means going back and updating the form bean class every time, which can be tedious if it's not being automatically generated. In practice, I have used both techniques -- but in particular I find myself needing data outside the nested body of an html:form, in which case I really need to use technique (1) anyway. Part of my internal system documentation (for the various developers) is a clear description of the bean names (and scopes), and the properties that they expose, that the page developer can count on. This seems to deal with most of the manageability issues, but none of these apps have had a very long life yet since Struts has only been around a year :-). Craig McClanahan From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: ActionForms for read-only data?? Date: Mon, 11 Jun 2001 17:01:31 -0700 (PDT) On Mon, 11 Jun 2001 [EMAIL PROTECTED] wrote: I have a Struts theory question on use of action forms versus java beans for read-only data. We have extended workflow on our website such that the same form can look a bit different depending on where you are in the workflow. For example, the quote request will have limit and retention fields in the business request section. Once you get to quote, those fields are read-only and there's an additional quote amount field. When the client requests binder, all those fields are read-only and there is a checkbox. Once bound, everything is read-only. There is some disagreement on the team as to how to handle this case. We will obviously have four JSPs, one for each of these presentations. The question is the data mapping to beans. Half of the team feels that to use Struts in its purest sense, we need to have java beans that represent the read-only data, and action forms to represent the editable data. That would mean four action forms, one for each JSP. The other half of the team wants to re-use the same action form for all four cases, bean:define it in the session, and use bean:write to print out the data if read-only. The major advantage is simplicity - we have one bean that represents all of the data - there is no need to understand what part of the workflow we are in when translating the data from the data model to the presentation layer beans. It is also easier to understand for an HTML programmer or developer that the same bean is used regardless of whether it is a bean:write or any of the html tags. We certainly don't want to end up in a position where we have broken the framework and hurt our extensibility in future releases. The first scenario would seem to follow the framework more closely, but in this special case, is it a problem to deviate and use the ActionForm for what it is - a bean? We would appreciate any advice and experiences. Thank you. Ted covered a couple of the issues in his response -- I'd like to add a few more thoughts. I don't think there are cut-and-dried answers to an issue like this, so it's a question of balancing the tradeoffs. If you are using the same JSP page itself
Re: ActionForms for read-only data??
Craig, can you explain point number one Expose the data as JavaBeans *other than* the form bean. Is it that you are not using the form bean? - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 14, 2001 1:19 PM Subject: Re: ActionForms for read-only data?? On Thu, 14 Jun 2001, hi there wrote: Craig, The ActionForm class definition seems to imply that it was intended to contain only editable data (i.e., the reset and validate methods). Distinguishing between read and write functionality in the enterprise systems I have developed was always a major advantage, both in extensibility and code maintainability, as usually each type of functionality had different processing requirments. It seems that if we mix read and write functionality into one ActionForm instance, we will have some bulky classes to maintain. Any comments? Thanks. There are probably multiple reasonable approaches to dealing with read-only data. Let's consider some of the ways you can do this: (1) Expose the data as JavaBeans *other than* the form bean: This is quite easy, since you can do things like bean:write to generate the output, logic: to test, and so on. However, you are mildly increasing the linkage between the model layer and the view layer -- now the developers have to agree on the bean name, and the properties to be used. The tradeoff is that you might be able to reuse beans (such as value objects in an EJB based app) that already exist. (2) Copy the read-only data into the form bean: This is particularly useful in several use cases: - You only want to access the data nested inside the html:form - You don't want to create the extra dependency on a bean name (since you can reference the form bean implicitly) - A particular property might be read-only in some uses of the form and read-write in others (see the username field of the RegistrationForm bean in the example application). However, adding new properties means going back and updating the form bean class every time, which can be tedious if it's not being automatically generated. In practice, I have used both techniques -- but in particular I find myself needing data outside the nested body of an html:form, in which case I really need to use technique (1) anyway. Part of my internal system documentation (for the various developers) is a clear description of the bean names (and scopes), and the properties that they expose, that the page developer can count on. This seems to deal with most of the manageability issues, but none of these apps have had a very long life yet since Struts has only been around a year :-). Craig McClanahan From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: ActionForms for read-only data?? Date: Mon, 11 Jun 2001 17:01:31 -0700 (PDT) On Mon, 11 Jun 2001 [EMAIL PROTECTED] wrote: I have a Struts theory question on use of action forms versus java beans for read-only data. We have extended workflow on our website such that the same form can look a bit different depending on where you are in the workflow. For example, the quote request will have limit and retention fields in the business request section. Once you get to quote, those fields are read-only and there's an additional quote amount field. When the client requests binder, all those fields are read-only and there is a checkbox. Once bound, everything is read-only. There is some disagreement on the team as to how to handle this case. We will obviously have four JSPs, one for each of these presentations. The question is the data mapping to beans. Half of the team feels that to use Struts in its purest sense, we need to have java beans that represent the read-only data, and action forms to represent the editable data. That would mean four action forms, one for each JSP. The other half of the team wants to re-use the same action form for all four cases, bean:define it in the session, and use bean:write to print out the data if read-only. The major advantage is simplicity - we have one bean that represents all of the data - there is no need to understand what part of the workflow we are in when translating the data from the data model to the presentation layer beans. It is also easier to understand for an HTML programmer or developer that the same bean is used regardless of whether it is a bean:write or any of the html tags. We certainly don't want to end up in a position where we have broken the framework and hurt our extensibility in future releases. The first scenario would seem to follow the framework more closely, but in this special case, is it a problem
RE: ActionForms for read-only data??
Hi Ted Since you mentioned about this. I have tried a similar method and I notice while the method works, I have to store the form bean in the session scope instead of the request scope. When I try to store the form (with nested beans) in the request scope, when the form is submitted to the next action, STRUTS does not automatically create the table1 bean nor the table2 bean though it creates the formbean fine. Any comments? Regards Michael Mok www.webappcabaret.com/normad -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 12 June 2001 17:44 To: [EMAIL PROTECTED] Subject: Re: ActionForms for read-only data?? This is off the original topic, but speaking of multiple beans, I thought I would mention that since the Struts tags support a nested syntax, beans can be properties of ActionForms. html:hidden property=table1.account html:hidden property=table2.customerName This would map to table1.getAccount() and table2.CustomerName() -- where table1 and table2 were JavaBean properties of your ActionForm (including ActionForms!). -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/
Re: ActionForms for read-only data??
Struts tries to recycle ActionForm beans between requests. Perhaps Struts is not creating a new bean for the next request, but recycling the old one by calling reset(), and so the nested beans are being set to null. Michael Mok wrote: Hi Ted Since you mentioned about this. I have tried a similar method and I notice while the method works, I have to store the form bean in the session scope instead of the request scope. When I try to store the form (with nested beans) in the request scope, when the form is submitted to the next action, STRUTS does not automatically create the table1 bean nor the table2 bean though it creates the formbean fine. Any comments?
Re: ActionForms for read-only data??
The important thing about ActionForm beans is that they are intended as adapters between HTML forms and the rest of the application. If the property is being used within a HTML form, then it is a valid use of an ActionForm bean, regardless of whether the property is hidden or immutable. It is not expected that there will be a 1:1 relationship between a HTML form and an ActionForm bean. Some ActionForm beans may be used on several forms, and several forms may use the same ActionForm bean. In general, most people would design ActionForm beans to represent a logical view (in the SQL sense) within the application. If the data is being accessed by the same SQL query, then it would make sense to put it all on the same ActionForm bean, regardless of whether it is exposed. The only thing to watch for is Strut's calling reset() as part of the validation. If a property is not present in the form, then it will be reset, and your validation has to cope with that. One caveat: ActionForms are not meant to be a panacea for the presentation layer. There are often other JavaBeans in play on this layer, with ActionForms being specialized for use with HTML forms. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/ [EMAIL PROTECTED] wrote: I have a Struts theory question on use of action forms versus java beans for read-only data. We have extended workflow on our website such that the same form can look a bit different depending on where you are in the workflow. For example, the quote request will have limit and retention fields in the business request section. Once you get to quote, those fields are read-only and there's an additional quote amount field. When the client requests binder, all those fields are read-only and there is a checkbox. Once bound, everything is read-only. There is some disagreement on the team as to how to handle this case. We will obviously have four JSPs, one for each of these presentations. The question is the data mapping to beans. Half of the team feels that to use Struts in its purest sense, we need to have java beans that represent the read-only data, and action forms to represent the editable data. That would mean four action forms, one for each JSP. The other half of the team wants to re-use the same action form for all four cases, bean:define it in the session, and use bean:write to print out the data if read-only. The major advantage is simplicity - we have one bean that represents all of the data - there is no need to understand what part of the workflow we are in when translating the data from the data model to the presentation layer beans. It is also easier to understand for an HTML programmer or developer that the same bean is used regardless of whether it is a bean:write or any of the html tags. We certainly don't want to end up in a position where we have broken the framework and hurt our extensibility in future releases. The first scenario would seem to follow the framework more closely, but in this special case, is it a problem to deviate and use the ActionForm for what it is - a bean? We would appreciate any advice and experiences. Thank you. Lisa Stephens GeneralCologne Re Trumbull, CT 203 328 5227
