Hi, I usually do these transformations within the Action. Translating the content of the form-beans into ValueObjects that are passed into the model-backend which contains the business-logic. The same on the way back (Backend generates value-objects, Action transforms into view-model-classes (smalltalk) which then can be displayed). I got this advice from some doc by Ted saying that the Action-class should play the translator from the web (our frontend) to the business-logic (model / backend) and vice-versa.
hth Alexander Jesse PS: yes it creates a few objects more, but it cleanly separates the layers -----Original Message----- From: James Carman [mailto:[EMAIL PROTECTED]] Sent: Montag, 11. Februar 2002 22:28 To: Struts Users Mailing List Subject: Re: java.util.Date parameters... My point was that the business logic should not have to deal with Strings just because Struts can't handle them. ----- Original Message ----- From: "Keith Bacon" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Monday, February 11, 2002 1:22 PM Subject: Re: java.util.Date parameters... > How about 2 setters for in your business logic validation. > > setAndValidateMyDateString(String inputDateString) { > // validate date is valid. > // If valid call the next method to do the rest. > } > > setAndValidateMyDate(Date inputDate) {..} > > String getMyDateDisplayFormat {} > Date getMyDate() {} > > Then your GUI can send you a date or a string as it pleases & fetch the data in either format. > This pattern works for numbers too. > == > What I was proposing below is that users type in dates in any format your validation method can > handle & see the dates displayed in the format determined by 1 static method. > Experience of dates on systems with applet/html & Swing front ends has lead me to the conclusion > that defining dates as Strings in java classes is really simple. Also the simplest design is to > have validation that can handle input Date objects & a String version of it. > (Don't worry you aren't the only one that doesn't believe me!). > > I wasn't mentioning how dates are stored on a DB, that's up to code in the business logic (or the > persistence layer behind it). > > K. > > > --- James Carman <[EMAIL PROTECTED]> wrote: > > That doesn't answer my question. I don't want users to have to type dates > > in the ISO format on the web page. I want them to be able to type > > 02/11/2002 for today's date. However, I also want to be able to store this > > string however I want (maybe as a String in ISO format or a java.util.Date > > object). My design approach allows Struts to still do all of the > > extracting/populating of the form beans, but also allows the customization > > of showing non-String properties in <html:text> or <html:textarea> tags. > > That's all I was looking for, an automated way to bridge the gap between > > non-String properties and Struts' auto-populate feature. > > > > Also, a web application should just be written as a shell around business > > logic. The business logic should not have to cater to the restrictions of a > > web application (resorting to storing dates as strings for example). In > > fact, the business logic should be able to execute without a web application > > being present at all (if for nothing else but testing purposes). > > > > ----- Original Message ----- > > From: "Keith Bacon" <[EMAIL PROTECTED]> > > To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > > Sent: Monday, February 11, 2002 11:45 AM > > Subject: Re: java.util.Date parameters... > > > > > > > I have a Utility class of static methods to validate & format data. > > > 1 - To avoid unnecessary object creation for performance. > > > 2 - Utility methods are the simplest design there is - so why have > > anything more complicated > > > (because we are so madly OO sometimes we forget to be simple?). > > > Also we pass dates around as Strings (yyyymmdd). I saw code from a big > > bank (can't remember which > > > one), they had gone the same way - using Strings in ISO date standard > > format. > > > I never found a problem with this & it seems so darn direct & simple. I > > used to use Date objects > > > but gave that up. > > > > > > eg. > > > // returns error message or null if date valid. > > > static public String validateDate(String inputDate) {..) > > > > > > // after successful call to validate call this to put > > > // date in standard format. > > > static public String stringToDate(String inputDate) {}... > > > > > > Then your form bean & action form & business logic only have the dates as > > Strings. > > > A String containing a date is effectively a Date Value object, but it's > > not worth > > > creating a Date class to encapsulate it. > > > An Object should have Identity, Attributes & Behaviour (said some wise > > guy), a date object doesn't > > > really qualify. > > > > > > Keith. > > > > > > > > > > > > > > > --- James Carman <[EMAIL PROTECTED]> wrote: > > > > What is the best way to user java.util.Dates in your forms, since the > > "text" html tag requires a > > > > property of type java.lang.String? I thought about creating the > > following, reusable framework > > > > for all parameter types that cannot be automatically set/extracted using > > the current Struts > > > > framework... > > > > > > > > Create a special PropertyProxy class as follows... > > > > > > > > /** > > > > * PropertyProxy merely forwards set/get property requests to the > > appropriate methods in the > > > > enclosed > > > > * bean object. > > > > */ > > > > public class PropertyProxy > > > > { > > > > public PropertyProxy( Object bean, String propertyName ); > > > > public void setProperty( Object value ); > > > > public Object getProperty(); > > > > } > > > > > > > > Extend PropertyProxy to support "stringification" of properties, > > introducing the following... > > > > > > > > /** > > > > * A Stringifier object translates object to/from their java.lang.String > > form. The toString() > > > > and > > > > * fromString() methods are inverses of one another. That is... > > > > * > > > > * o.equals( fromString( toString( o ) ) ) == true > > > > * > > > > * for all o supported by this Stringifier instance. > > > > */ > > > > public interface Stringifier > > > > { > > > > String toString( Object value ); > > > > Object fromString( String string ); > > > > } > > > > > > > > /** > > > > * StringifiedPropertyProxy expects java.lang.String objects in the > > setProperty() method and > > > > * returns java.lang.String objects from the getProperty() method. > > > > */ > > > > public class StringifiedPropertyProxy extends PropertyProxy > > > > { > > > > public StringifiedPropertyProxy( Object bean, String propertyName, > > Stringifier stringifier ); > > > > } > > > > > > > > Now, to support java.util.Date properties (I usually use nested bean > > properties in my forms)... > > > > > > > > /** > > > > * Simply stringifies java.util.Date objects using a > > java.text.SimpleDateFormat object. > > > > */ > > > > public class SimpleDateStringifier implements Stringifier > > > > { > > > > private final SimpleDateFormat format; > > > > public SimpleDateStringifier( String formatString ); > > > > } > > > > > > > > public class Person > > > > { > > > > private String name; > > > > private java.util.Date birthday; > > > > > > > > public void setName( String newName ); > > > > public String getName(); > > > > public void setBirthday( Date newBirthday ); > > > > public Date getBirthday(); > > > > } > > > > > > > > public class PersonForm extends ActionForm > > > > { > > > > private Person person = new Person(); > > > > private PropertyProxy birthdayProxy = new > > StringifiedPropertyProxy( person, "birthday", new > > > > SimpleDateStringifier( "MM/dd/yyyy" ) ); > > > > > > > > public Person getPerson(); > > > > public SimpleDateProxy getBirthdayProxy() > > > > } > > > > > > > > Here's the resulting form in a JSP page... > > > > > > > > <html:form action="whatever"> > > > > <html:text name="person.name" /> > > > > <html:text name="birthdayProxy.property" /> > > > > </html:form> > > > > > > > > Does this sound feasible? Or, is there a better way to do it? > > > > > > > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Send FREE Valentine eCards with Yahoo! Greetings! > > > http://greetings.yahoo.com > > > > > > -- > > > 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]> > > > > > __________________________________________________ > Do You Yahoo!? > Send FREE Valentine eCards with Yahoo! Greetings! > http://greetings.yahoo.com > > -- > 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]>
