You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by James Carman <ja...@carmanconsulting.com> on 2002/02/11 16:38:45 UTC
java.util.Date parameters...
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?
Re: java.util.Date parameters...
Posted by James Carman <ja...@carmanconsulting.com>.
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" <ke...@yahoo.com>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
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 <ja...@carmanconsulting.com> 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" <ke...@yahoo.com>
> > To: "Struts Users Mailing List" <st...@jakarta.apache.org>
> > 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 <ja...@carmanconsulting.com> 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:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Send FREE Valentine eCards with Yahoo! Greetings!
> http://greetings.yahoo.com
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: java.util.Date parameters...
Posted by Keith Bacon <ke...@yahoo.com>.
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 <ja...@carmanconsulting.com> 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" <ke...@yahoo.com>
> To: "Struts Users Mailing List" <st...@jakarta.apache.org>
> 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 <ja...@carmanconsulting.com> 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:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
> >
> >
>
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: java.util.Date parameters...
Posted by James Carman <ja...@carmanconsulting.com>.
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" <ke...@yahoo.com>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
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 <ja...@carmanconsulting.com> 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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: java.util.Date parameters...
Posted by Keith Bacon <ke...@yahoo.com>.
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 <ja...@carmanconsulting.com> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>