RE: Type conversions - issues on where to do them
1) If I do it in the ActionForm and there is a problem in the Action, then I have to reconvert back to a String on the way back.; That's why I advocate that properties in an ActionForm should be Strings instead of dates/ints/whatever. Why not let the ActionForm do all simple conversion and validation? The request object still has the String versions. Jonas
Re: Type conversions - issues on where to do them
The best practice is to perform domain validations in the ActionForm, like those possible with David W's validator. This means confirming that the String could be represented as the desired type. The original String captured by the ActionForm should never be altered (immutable except by the user). The type conversions can be handled by a helper object, which can be embedded in the ActionForm or elsewhere. If the conversions are handled by the ActionForm, the result should always be transfered to another property, leaving the original String intact. A good way to retrieve the data in this case is to have a separate accessor. So an ActionForm may have a getAccount() accessor and a getAccountInt() accessor, with the int property being set as part of the ActionForm validation. If the ActionForm makes it to the Action, the API contract would be that getAccountInt() will return a valid representation of getAccount as an int. Of course, the int returned may not be in a valid range, pursuant to some business logic. This level of validation should be perfomed in the Action, which can easily return the ActionForm to input if there is a problem. Another form of range might be a valid username and password. [ user input ] - [ action form ] - [ validate domain ] - [ action ] - [ validate range ] - [ transfer to persistent storage or business logic beans ] Depending on the resources available, you may also prefer to do the type conversions within the Action. If the ActionForm validator is doing it's job, the conversions should not fail. Personally, I let the RowSets do most of my type conversions for me, which happens within the Action. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/ Jonathan Asbell wrote: Hello all. I wanted to know where you are doing type conversion. The reason I ask is because to some extent one may choose to do slightly deeper validations in the ActionForm for reasons of expectation. The question remains as to the exact level of light validation we should do in the ActionForm. From reading the list it seems the general consensus is to only do validation of a value's existance. However, where do you do type conversion then? In the ActionForm? In the Action? In the BusinessObject layer? The issues are: 1) If I do it in the ActionForm and there is a problem in the Action, then I have to reconvert back to a String on the way back.; 2) If I do it in the Action, same problem, but also the argument has been brought to my attention that the ActionForm bean (although temporary) does not truly represent the data it contains (like when a value represents a double, money, or a Date) 3) If I do it in the Business Layer than the message has gone deeper into the application than necessary which sacrifices performance and needless use of resources.
Re: Type conversions - issues on where to do them
This is an interesting question. I'll give you my take on it -- others will have different opinions. On Wed, 13 Jun 2001, Jonathan Asbell wrote: Hello all. I wanted to know where you are doing type conversion. The reason I ask is because to some extent one may choose to do slightly deeper validations in the ActionForm for reasons of expectation. The question remains as to the exact level of light validation we should do in the ActionForm. From reading the list it seems the general consensus is to only do validation of a value's existance. However, where do you do type conversion then? In the ActionForm? In the Action? In the BusinessObject layer? The issues are: 1) If I do it in the ActionForm and there is a problem in the Action, then I have to reconvert back to a String on the way back.; That's why I advocate that properties in an ActionForm should be Strings instead of dates/ints/whatever. However, this is an issue that the validate() method can check, to catch things as early as possible. Whether you actually save the converted value here or not is a compute-time-versus-memory-space tradeoff, and either solution is possible. 2) If I do it in the Action, same problem, but also the argument has been brought to my attention that the ActionForm bean (although temporary) does not truly represent the data it contains (like when a value represents a double, money, or a Date) If you're using an ActionForm bean that uses validation (the default case), and if your validate method checks for any type conversion problems, then the Action can assume that the conversion will not fail. Of course, you need an it can't happen, but it did sort of error catch for conversion errors when you copy the String versions of the properties to your actual business objects, but 99% of the time they won't actually get triggered. 3) If I do it in the Business Layer than the message has gone deeper into the application than necessary which sacrifices performance and needless use of resources. Type conversion errors should have been caught by now. Business objects should deal with the native property types -- part of the role of the Action is to be an adapter between the String representation (used by the form beans) and the native representation (used by the business logic). Craig McClanahan
Re: Type conversions - issues on where to do them
Well, just one hitch when doing the business validation in the Action. If you are developing in an enterprise environment, you probably want to do these kind of validations in a business object because, as pointed out in an eariler thread, you may need data from the database to do this validation/evaluation. Better that the validation for this level all be in one place. In an enterprise app the Action would probably be considered part of the web tier. Therfore, it would not be good to mix the two tiers. What do you Think? By the way Ted, thank you for being so open and taking the time to offer your perspective. I really appreciate it and I'm sure everyone on the list does as well. It makes this list truly worth while. Ditto to Oleg, Martin, Michael, Johan, Peter, Nanduri, Jon, Jeff, Hal, David, and Craig. I have learned alot in these 3 months. - Original Message - From: Ted Husted [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 13, 2001 10:42 PM Subject: Re: Type conversions - issues on where to do them The best practice is to perform domain validations in the ActionForm, like those possible with David W's validator. This means confirming that the String could be represented as the desired type. The original String captured by the ActionForm should never be altered (immutable except by the user). The type conversions can be handled by a helper object, which can be embedded in the ActionForm or elsewhere. If the conversions are handled by the ActionForm, the result should always be transfered to another property, leaving the original String intact. A good way to retrieve the data in this case is to have a separate accessor. So an ActionForm may have a getAccount() accessor and a getAccountInt() accessor, with the int property being set as part of the ActionForm validation. If the ActionForm makes it to the Action, the API contract would be that getAccountInt() will return a valid representation of getAccount as an int. Of course, the int returned may not be in a valid range, pursuant to some business logic. This level of validation should be perfomed in the Action, which can easily return the ActionForm to input if there is a problem. Another form of range might be a valid username and password. [ user input ] - [ action form ] - [ validate domain ] - [ action ] - [ validate range ] - [ transfer to persistent storage or business logic beans ] Depending on the resources available, you may also prefer to do the type conversions within the Action. If the ActionForm validator is doing it's job, the conversions should not fail. Personally, I let the RowSets do most of my type conversions for me, which happens within the Action. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/ Jonathan Asbell wrote: Hello all. I wanted to know where you are doing type conversion. The reason I ask is because to some extent one may choose to do slightly deeper validations in the ActionForm for reasons of expectation. The question remains as to the exact level of light validation we should do in the ActionForm. From reading the list it seems the general consensus is to only do validation of a value's existance. However, where do you do type conversion then? In the ActionForm? In the Action? In the BusinessObject layer? The issues are: 1) If I do it in the ActionForm and there is a problem in the Action, then I have to reconvert back to a String on the way back.; 2) If I do it in the Action, same problem, but also the argument has been brought to my attention that the ActionForm bean (although temporary) does not truly represent the data it contains (like when a value represents a double, money, or a Date) 3) If I do it in the Business Layer than the message has gone deeper into the application than necessary which sacrifices performance and needless use of resources.
Re: Type conversions - issues on where to do them
Regarding your answer: Of course, you need an 'it can't happen, but it did' sort of error catch for conversion errors when you copy the String versions of the properties to your actual business objects, Are you assuming that I keep the form data as Strings until the business layer? This was my collegue's complaint about the ActionForms because they did not contain the types he was expecting, but rather just Strings. Where are you personally doing conversions? - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Jonathan Asbell [EMAIL PROTECTED] Sent: Wednesday, June 13, 2001 11:01 PM Subject: Re: Type conversions - issues on where to do them This is an interesting question. I'll give you my take on it -- others will have different opinions. On Wed, 13 Jun 2001, Jonathan Asbell wrote: Hello all. I wanted to know where you are doing type conversion. The reason I ask is because to some extent one may choose to do slightly deeper validations in the ActionForm for reasons of expectation. The question remains as to the exact level of light validation we should do in the ActionForm. From reading the list it seems the general consensus is to only do validation of a value's existance. However, where do you do type conversion then? In the ActionForm? In the Action? In the BusinessObject layer? The issues are: 1) If I do it in the ActionForm and there is a problem in the Action, then I have to reconvert back to a String on the way back.; That's why I advocate that properties in an ActionForm should be Strings instead of dates/ints/whatever. However, this is an issue that the validate() method can check, to catch things as early as possible. Whether you actually save the converted value here or not is a compute-time-versus-memory-space tradeoff, and either solution is possible. 2) If I do it in the Action, same problem, but also the argument has been brought to my attention that the ActionForm bean (although temporary) does not truly represent the data it contains (like when a value represents a double, money, or a Date) If you're using an ActionForm bean that uses validation (the default case), and if your validate method checks for any type conversion problems, then the Action can assume that the conversion will not fail. Of course, you need an it can't happen, but it did sort of error catch for conversion errors when you copy the String versions of the properties to your actual business objects, but 99% of the time they won't actually get triggered. 3) If I do it in the Business Layer than the message has gone deeper into the application than necessary which sacrifices performance and needless use of resources. Type conversion errors should have been caught by now. Business objects should deal with the native property types -- part of the role of the Action is to be an adapter between the String representation (used by the form beans) and the native representation (used by the business logic). Craig McClanahan
Re: Type conversions - issues on where to do them
Jonathan Asbell wrote: Well, just one hitch when doing the business validation in the Action. If you are developing in an enterprise environment, you probably want to do these kind of validations in a business object because, as pointed out in an eariler thread, you may need data from the database to do this validation/evaluation. Better that the validation for this level all be in one place. In an enterprise app the Action would probably be considered part of the web tier. Therfore, it would not be good to mix the two tiers. What do you Think? The Action can be murky ground, but it is often used as the interface between the business tier and the Web tier. After all, they have to meet somewhere, yes? So, if the business object rejected the data, it would return it to the Action, which would hand it back to the ActionForm. You would not so much be doing the validation in the Action form as much as you would be calling the Business Object from the Action to do the validation. [ ActionForm ] - [ Action ] - [ Business Object ] By the way Ted, thank you for being so open and taking the time to offer your perspective. I really appreciate it and I'm sure everyone on the list does as well. It makes this list truly worth while. Ditto to Oleg, Martin, Michael, Johan, Peter, Nanduri, Jon, Jeff, Hal, David, and Craig. I have learned alot in these 3 months. And before much longer I'm sure someone will be adding your name to a list like that, Jonathan ;-) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/
Re: Type conversions - issues on where to do them
On Wed, 13 Jun 2001, Jonathan Asbell wrote: Regarding your answer: Of course, you need an 'it can't happen, but it did' sort of error catch for conversion errors when you copy the String versions of the properties to your actual business objects, Are you assuming that I keep the form data as Strings until the business layer? This was my collegue's complaint about the ActionForms because they did not contain the types he was expecting, but rather just Strings. Where are you personally doing conversions? There are two reasonable strategies for an ActionForm: * Check the convertability of the input strings but don't save them. * Convert the data to the appropriate native format, and provide a second getter method (getOrderDateAsDate() or something) for the native format. Note that, if you're using the latter strategy, your business object does not need to worry about conversion errors -- because the setter for the corresponding property (setOrderDate) will already be accepting a date. There is a second set of issues around the *semantic* validity of an input value (is it really reasonable to set the order date to 153 years ago?). This is, again, something you can check in many cases in the form bean's validate() method. But what do you do about a rule that the order date cannot be before this customer's credit was approved? That kind of rule should still be checked at the business logic layer, IMHO. Craig McClanahan - Original Message - From: Craig R. McClanahan [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Jonathan Asbell [EMAIL PROTECTED] Sent: Wednesday, June 13, 2001 11:01 PM Subject: Re: Type conversions - issues on where to do them This is an interesting question. I'll give you my take on it -- others will have different opinions. On Wed, 13 Jun 2001, Jonathan Asbell wrote: Hello all. I wanted to know where you are doing type conversion. The reason I ask is because to some extent one may choose to do slightly deeper validations in the ActionForm for reasons of expectation. The question remains as to the exact level of light validation we should do in the ActionForm. From reading the list it seems the general consensus is to only do validation of a value's existance. However, where do you do type conversion then? In the ActionForm? In the Action? In the BusinessObject layer? The issues are: 1) If I do it in the ActionForm and there is a problem in the Action, then I have to reconvert back to a String on the way back.; That's why I advocate that properties in an ActionForm should be Strings instead of dates/ints/whatever. However, this is an issue that the validate() method can check, to catch things as early as possible. Whether you actually save the converted value here or not is a compute-time-versus-memory-space tradeoff, and either solution is possible. 2) If I do it in the Action, same problem, but also the argument has been brought to my attention that the ActionForm bean (although temporary) does not truly represent the data it contains (like when a value represents a double, money, or a Date) If you're using an ActionForm bean that uses validation (the default case), and if your validate method checks for any type conversion problems, then the Action can assume that the conversion will not fail. Of course, you need an it can't happen, but it did sort of error catch for conversion errors when you copy the String versions of the properties to your actual business objects, but 99% of the time they won't actually get triggered. 3) If I do it in the Business Layer than the message has gone deeper into the application than necessary which sacrifices performance and needless use of resources. Type conversion errors should have been caught by now. Business objects should deal with the native property types -- part of the role of the Action is to be an adapter between the String representation (used by the form beans) and the native representation (used by the business logic). Craig McClanahan
Re: Type conversions - issues on where to do them
As we are both being nightowls in the same timezone, let me continue with this. We are using a Broker. So, in my case each Action would call the Broker, which is our link to the enterprise layer. Also, if the business object rejected the data, as you said, than it would pass it to the Action but NOT up again to the ActionForm. At that point the Action would choose a forward with errors and data. - Original Message - From: Ted Husted [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 13, 2001 11:25 PM Subject: Re: Type conversions - issues on where to do them Jonathan Asbell wrote: Well, just one hitch when doing the business validation in the Action. If you are developing in an enterprise environment, you probably want to do these kind of validations in a business object because, as pointed out in an eariler thread, you may need data from the database to do this validation/evaluation. Better that the validation for this level all be in one place. In an enterprise app the Action would probably be considered part of the web tier. Therfore, it would not be good to mix the two tiers. What do you Think? The Action can be murky ground, but it is often used as the interface between the business tier and the Web tier. After all, they have to meet somewhere, yes? So, if the business object rejected the data, it would return it to the Action, which would hand it back to the ActionForm. You would not so much be doing the validation in the Action form as much as you would be calling the Business Object from the Action to do the validation. [ ActionForm ] - [ Action ] - [ Business Object ] By the way Ted, thank you for being so open and taking the time to offer your perspective. I really appreciate it and I'm sure everyone on the list does as well. It makes this list truly worth while. Ditto to Oleg, Martin, Michael, Johan, Peter, Nanduri, Jon, Jeff, Hal, David, and Craig. I have learned alot in these 3 months. And before much longer I'm sure someone will be adding your name to a list like that, Jonathan ;-) -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/
Re: Type conversions - issues on where to do them
Jonathan Asbell wrote: As we are both being nightowls in the same timezone, let me continue with this. We are using a Broker. So, in my case each Action would call the Broker, which is our link to the enterprise layer. Also, if the business object rejected the data, as you said, than it would pass it to the Action but NOT up again to the ActionForm. At that point the Action would choose a forward with errors and data. Yes, I misspoke. The Action would insert an error and choose a forward; the ActionForm would just tag along as part of the pending request/response. The custom tags in the JSP would then find the ActionForm in the request, and redisplay what the user entered, for correction and resubmission. Jonathan Asbell wrote: Are you assuming that I keep the form data as Strings until the business layer? This was my collegue's complaint about the ActionForms because they did not contain the types he was expecting, but rather just Strings. An important thing to remember is that HTTPD doesn't allow us to send anything but Strings. As Craig mentioned, you can do things like add your own accessors to return whatever types you expect (converted from the Strings that the client sent by HTTPD), or use some other utility within your application. For example, someone might already have a Helper object that accepts strings and then transforms them in different ways. The general philosphy, I suppose, is that data conversion is outside the scope of the framework and best left to the developer. In case anyone is interested, here's a nice article about Helper classes: http://developer.java.sun.com/developer/restricted/patterns/ViewHelper.html
