You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Jon Wilmoth <jo...@yahoo.com> on 2003/07/01 19:45:44 UTC
[BeanUtils & Struts]RE: Support for Date datatypes!!!
I did investigate registering "custom" converters.
Unfortunately, anything that would support
non-hard-coded conversion patterns will require either
a mixed paradygm usage (i.e passing a complex object
that contains the value to convert and all convertion
configuration instead of simply the value to be
converted) of the existing Converter.convert interface
or additional parameters. Since I think everyone can
agree that the first option is confusing and should be
avoided when possible the remaining option is to
modify/extend the interface. I agree this should be
communicated within the BeanUtils developer mailing
list and will cross post this in hopes of getting
further creative approaches to the problem. Because
Struts will be responsible for providing the means to
invoke the conversion (and much more) I do feel it is
appropriate for this list to continue to discuss the
Struts/BeanUtil interaction necessary for this
functionality.
--- Wendy Smoak <We...@asu.edu> wrote:
>
> [Not a developer, but I've been following this
> because I ran into the date
> problem early on.] I use BeanUtils.copyProperties
> to move things back and
> forth from ActionForms (all String properties) and
> my DTO's, as shown in the
> struts-example webapp. At some point I thought
> needed a Java "Date" object
> in the DTO (that requirement went away with further
> development). And the
> existing SQL formatted Date converter wasn't going
> to work, my database
> doesn't understand that format.
>
> What was suggested to me is writing and registering
> my own Converter with
> BeanUtils. I don't think I went through with it,
> but that made perfect
> sense to me. IMO, Struts shouldn't get involved
> with Date conversions,
> that's already the job of Commons BeanUtils.
>
> --
> Wendy Smoak
> Applications Systems Analyst, Sr.
> Arizona State University, PA, IRM
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Validation & Indexed properties
Posted by Jon Wilmoth <jo...@yahoo.com>.
I'm trying to validate a collection of objects such
that one of the properties generated html inputs looks
like:
<input type="text" name="assignmentForm[1].startDate"
size="13" value="">
I've defined the "form-validation" doc with the
following field block:
<field property="startDate" depends="date">
<msg key="errors.invalid.date" name="date"/>
<arg0 name="date"
key="package.Assignment.startDate.label"/>
<arg1 name="date" key="${var:datePattern}"
resource="false"/>
<var>
<var-name>datePattern</var-name>
<var-value>MM/dd/yyyy</var-value>
</var>
</field>
unfortunately, the form doesn't seem to get validated.
I don't have this issue with non-indexed properties.
On a related note, the html:errors tag doesn't seem to
have an indexed boolean attribute. Will I be able to
access the error message specific to that index?
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [BeanUtils & Struts]RE: Support for Date datatypes!!!
Posted by Ted Husted <hu...@apache.org>.
It's not available as a JAR, just the source.
Vic Cekvenich wrote:
> Nice. Where can an jar be downloaded for this?
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/wqdata/wqdata/src/java/shared/org_apache_commons/util/
>
>
> tia,
> .V
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [BeanUtils & Struts]RE: Support for Date datatypes!!!
Posted by Vic Cekvenich <vi...@baseBeans.com>.
Nice. Where can an jar be downloaded for this?
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/wqdata/wqdata/src/java/shared/org_apache_commons/util/
tia,
.V
Ted Husted wrote:
> Joe Germuska wrote:
> > I'm still not completely convinced that the best solution isn't to
> > write your own ActionForm class that has two properties, 'date' and
> > 'dateAsString' (or whatever you want to call them) and behind the
> > scenes, when one of the properties simply sets and returns a data
> > member, and the other parses and formats values.
>
> +1
>
> IMHO, this problem is outside both the scope of Struts and ConvertUtils.
>
> There are myriad ways to handle expressions of date and time. Enough
> that they deserve their own UI class (or classes). The Java libraries
> provide all the functionality most of us need. The trick, as Joe pointed
> out, is to put that functionality behind a facade. Especially when you
> get to as many use-cases as have been enumerated here.
>
> IMHO, the solution is not to push the work off onto the tags or onto the
> framework, but to centralize it in your own date handler object that can
> be extended to do what you need it to do.
>
> After three years, we all have working solutions to this problem. Most,
> I would hazard to guess, are variations of Joe's approach. IMHO, work on
> this subject is best directed at a better date-handling object (or
> facade), that could be used by Struts or any other presentation
> application.
>
> Right now, I'm using a DateDisplay object to handle displaying dates in
> drop-down boxes and converting it back and forth:
>
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/wqdata/wqdata/src/java/shared/org_apache_commons/util/
>
>
> There are also some date/time/calendaring handling utilities under
> development in Commons Lang:
>
> http://cvs.apache.org/viewcvs/jakarta-commons/lang/src/java/org/apache/commons/lang/time/
>
>
> The way I approach this problem is by defining a date handling class (or
> classes) that can talk to Struts and can also talk to the controller or
> your business classes. If a date need to be accepted in one format and
> presented in another, it should the job if this class to handle any
> conversions. Or, if you need to provide the Date in different binary
> flavors (util, sql), the class could do that tIn this way it can be used
> not only with the Struts tags but with JSLT tags and other presentation
> devices.
>
> I think in the end, we will all be using UI components that make such
> objects easier to plug into frameworks like Struts, but such components
> will need objects like these to do the dirty work.
>
> IMHO, this is the most Agile approach of all, since it is easy to
> implement and test, and can be reused time and again.
>
> -Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [BeanUtils & Struts]RE: Support for Date datatypes!!!
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
i don't have the expertise designing web frameworks that the folks from
struts have so i'd prefer to stay focused on jon's proposals for beanutils.
(i have a little more experience creating reusable library code used by
large numbers of users).
since these break backwards compatibility, i'd be very reluctant to
support the changes (that jon proposes) to beanutils unless there is a
very pressing need and no other possible solutions. there is already an
existing proposal concerning beanutils (by eric pabst) that i think leads
towards a more promising direction and which retains compatibility.
i intend to review eric's proposal in detail and (providing i find no
hidden defects and no one else objects) then commit the code sometime
soonish. i know that some people find this conservative approach to
development frustrating but beanutils is widely used and IMHO getting
things right is more important than pushing forward the code base with new
features.
FWIW IMHO there are a whole lot of wrinkles handling dates and i don't
have great hopes in a one-size-fits all approach. i would say that a more
modular and extensible approach would be better.
- robert
On Wednesday, July 2, 2003, at 07:17 PM, Jon Wilmoth wrote:
> Perhaps the focus of this discussion has been clouded
> by my initial proposal. I hope this is the case and
> not that people are not interested in addressing a
> common complex problem that has been left to each
> individual Struts implementor to resolve. So...let me
> restate the objective and the points to date:
>
> Objective: Provide users of the Struts framework
> seemless, integrated support for custom formatted date
> properties. This includes data entry as well as
> rendering.
>
> The current sequence of events (and thus the available
> solution point(s)) are as follows -
> Data input:
> 1) Taglibs render html control displaying current
> value (if any) of form bean property
> 2) http get/post with string data --> framework pieces
> --> RequestProcessor.processPopulate
> 3) RequestProcessor.processPopulate -->
> RequestUtils.populate
> 4) RequestUtils.populate --> BeanUtils.populate(bean,
> properties)
> 5) BeanUtils.populate(bean, properties) -->
> ConvertUtils.convert
> 6) BeanUtils.populate(bean, properties) -->
> PropertyUtils.setProperty (Indexed, Mapped or simple)
> 7) RequestProcessor.processValidate -->
> RequestProcessor.processActionPerform (happy path)
> 8) Action executes and returns to step 1 (for
> simplicity)
>
> Points to Date:
> * It has been suggested that all conversions be
> performed by the BeanUtils package so that other
> projects could leverage common code.
> * It has also been suggested that a single object
> other than ConvertUtils be responsible for date
> conversions.
> * A ui component model seems to be the "cure" for
> increasing the robust nature of html controls as they
> interact with java code.
> * The solution has touch points with the struts
> framework
> * Other groups are addressing one or more aspects
> (i.e. JSTL)
> * A property descriptor type object had been mentioned
> as a central place for defining numerous aspects of a
> single property (i.e. min's, max's, conversions,
> etc.).
> * Solution should accomodate more abstract types of
> custom conversion than simply dates? No use cases of
> these other data types have been provided.
>
> My questions then are;
> 1) Does the community see value in centralizing the
> solution of dealing with custom formatted date
> conversions? If not then the rest are sadly a moot
> point.
> 2) If so, should Date --> String and String --> Date
> conversion be in the same place? Which group/code
> base can be recongnized as the "official" supported
> location for this behavior?
> 3) How/Where does the Struts framework (tags, request
> processor, etc.) interact with this code?
> 4) What role does the UI component model play in this?
> Does it define the relationship between a control and
> this "property descriptor"? Where is this model
> defined? Struts? Commons? JavaServer Faces?
>
> --- Ted Husted <hu...@apache.org> wrote:
>> Joe Germuska wrote:
>>> I'm still not completely convinced that the best
>> solution isn't to
>>> write your own ActionForm class that has two
>> properties, 'date' and
>>> 'dateAsString' (or whatever you want to call
>> them) and behind the
>>> scenes, when one of the properties simply sets
>> and returns a data
>>> member, and the other parses and formats values.
>>
>> +1
>>
>> IMHO, this problem is outside both the scope of
>> Struts and ConvertUtils.
>>
>> There are myriad ways to handle expressions of date
>> and time. Enough
>> that they deserve their own UI class (or classes).
>> The Java libraries
>> provide all the functionality most of us need. The
>> trick, as Joe pointed
>> out, is to put that functionality behind a facade.
>> Especially when you
>> get to as many use-cases as have been enumerated
>> here.
>>
>> IMHO, the solution is not to push the work off onto
>> the tags or onto the
>> framework, but to centralize it in your own date
>> handler object that can
>> be extended to do what you need it to do.
>>
>> After three years, we all have working solutions to
>> this problem. Most,
>> I would hazard to guess, are variations of Joe's
>> approach. IMHO, work on
>> this subject is best directed at a better
>> date-handling object (or
>> facade), that could be used by Struts or any other
>> presentation
>> application.
>>
>> Right now, I'm using a DateDisplay object to handle
>> displaying dates in
>> drop-down boxes and converting it back and forth:
>>
>>
> http://cvs.sourceforge.net/cgi-
> bin/viewcvs.cgi/wqdata/wqdata/src/java/shared/org_apache_commons/util/
>>
>> There are also some date/time/calendaring handling
>> utilities under
>> development in Commons Lang:
>>
>>
> http://cvs.apache.org/viewcvs/jakarta-
> commons/lang/src/java/org/apache/commons/lang/time/
>>
>> The way I approach this problem is by defining a
>> date handling class (or
>> classes) that can talk to Struts and can also talk
>> to the controller or
>> your business classes. If a date need to be accepted
>> in one format and
>> presented in another, it should the job if this
>> class to handle any
>> conversions. Or, if you need to provide the Date in
>> different binary
>> flavors (util, sql), the class could do that tIn
>> this way it can be used
>> not only with the Struts tags but with JSLT tags and
>> other presentation
>> devices.
>>
>> I think in the end, we will all be using UI
>> components that make such
>> objects easier to plug into frameworks like Struts,
>> but such components
>> will need objects like these to do the dirty work.
>>
>> IMHO, this is the most Agile approach of all, since
>> it is easy to
>> implement and test, and can be reused time and
>> again.
>>
>> -Ted.
>>
>>
>>
>>
> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> struts-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> struts-dev-help@jakarta.apache.org
>>
>
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [BeanUtils & Struts]RE: Support for Date datatypes!!!
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
i don't have the expertise designing web frameworks that the folks from
struts have so i'd prefer to stay focused on jon's proposals for beanutils.
(i have a little more experience creating reusable library code used by
large numbers of users).
since these break backwards compatibility, i'd be very reluctant to
support the changes (that jon proposes) to beanutils unless there is a
very pressing need and no other possible solutions. there is already an
existing proposal concerning beanutils (by eric pabst) that i think leads
towards a more promising direction and which retains compatibility.
i intend to review eric's proposal in detail and (providing i find no
hidden defects and no one else objects) then commit the code sometime
soonish. i know that some people find this conservative approach to
development frustrating but beanutils is widely used and IMHO getting
things right is more important than pushing forward the code base with new
features.
FWIW IMHO there are a whole lot of wrinkles handling dates and i don't
have great hopes in a one-size-fits all approach. i would say that a more
modular and extensible approach would be better.
- robert
On Wednesday, July 2, 2003, at 07:17 PM, Jon Wilmoth wrote:
> Perhaps the focus of this discussion has been clouded
> by my initial proposal. I hope this is the case and
> not that people are not interested in addressing a
> common complex problem that has been left to each
> individual Struts implementor to resolve. So...let me
> restate the objective and the points to date:
>
> Objective: Provide users of the Struts framework
> seemless, integrated support for custom formatted date
> properties. This includes data entry as well as
> rendering.
>
> The current sequence of events (and thus the available
> solution point(s)) are as follows -
> Data input:
> 1) Taglibs render html control displaying current
> value (if any) of form bean property
> 2) http get/post with string data --> framework pieces
> --> RequestProcessor.processPopulate
> 3) RequestProcessor.processPopulate -->
> RequestUtils.populate
> 4) RequestUtils.populate --> BeanUtils.populate(bean,
> properties)
> 5) BeanUtils.populate(bean, properties) -->
> ConvertUtils.convert
> 6) BeanUtils.populate(bean, properties) -->
> PropertyUtils.setProperty (Indexed, Mapped or simple)
> 7) RequestProcessor.processValidate -->
> RequestProcessor.processActionPerform (happy path)
> 8) Action executes and returns to step 1 (for
> simplicity)
>
> Points to Date:
> * It has been suggested that all conversions be
> performed by the BeanUtils package so that other
> projects could leverage common code.
> * It has also been suggested that a single object
> other than ConvertUtils be responsible for date
> conversions.
> * A ui component model seems to be the "cure" for
> increasing the robust nature of html controls as they
> interact with java code.
> * The solution has touch points with the struts
> framework
> * Other groups are addressing one or more aspects
> (i.e. JSTL)
> * A property descriptor type object had been mentioned
> as a central place for defining numerous aspects of a
> single property (i.e. min's, max's, conversions,
> etc.).
> * Solution should accomodate more abstract types of
> custom conversion than simply dates? No use cases of
> these other data types have been provided.
>
> My questions then are;
> 1) Does the community see value in centralizing the
> solution of dealing with custom formatted date
> conversions? If not then the rest are sadly a moot
> point.
> 2) If so, should Date --> String and String --> Date
> conversion be in the same place? Which group/code
> base can be recongnized as the "official" supported
> location for this behavior?
> 3) How/Where does the Struts framework (tags, request
> processor, etc.) interact with this code?
> 4) What role does the UI component model play in this?
> Does it define the relationship between a control and
> this "property descriptor"? Where is this model
> defined? Struts? Commons? JavaServer Faces?
>
> --- Ted Husted <hu...@apache.org> wrote:
>> Joe Germuska wrote:
>>> I'm still not completely convinced that the best
>> solution isn't to
>>> write your own ActionForm class that has two
>> properties, 'date' and
>>> 'dateAsString' (or whatever you want to call
>> them) and behind the
>>> scenes, when one of the properties simply sets
>> and returns a data
>>> member, and the other parses and formats values.
>>
>> +1
>>
>> IMHO, this problem is outside both the scope of
>> Struts and ConvertUtils.
>>
>> There are myriad ways to handle expressions of date
>> and time. Enough
>> that they deserve their own UI class (or classes).
>> The Java libraries
>> provide all the functionality most of us need. The
>> trick, as Joe pointed
>> out, is to put that functionality behind a facade.
>> Especially when you
>> get to as many use-cases as have been enumerated
>> here.
>>
>> IMHO, the solution is not to push the work off onto
>> the tags or onto the
>> framework, but to centralize it in your own date
>> handler object that can
>> be extended to do what you need it to do.
>>
>> After three years, we all have working solutions to
>> this problem. Most,
>> I would hazard to guess, are variations of Joe's
>> approach. IMHO, work on
>> this subject is best directed at a better
>> date-handling object (or
>> facade), that could be used by Struts or any other
>> presentation
>> application.
>>
>> Right now, I'm using a DateDisplay object to handle
>> displaying dates in
>> drop-down boxes and converting it back and forth:
>>
>>
> http://cvs.sourceforge.net/cgi-
> bin/viewcvs.cgi/wqdata/wqdata/src/java/shared/org_apache_commons/util/
>>
>> There are also some date/time/calendaring handling
>> utilities under
>> development in Commons Lang:
>>
>>
> http://cvs.apache.org/viewcvs/jakarta-
> commons/lang/src/java/org/apache/commons/lang/time/
>>
>> The way I approach this problem is by defining a
>> date handling class (or
>> classes) that can talk to Struts and can also talk
>> to the controller or
>> your business classes. If a date need to be accepted
>> in one format and
>> presented in another, it should the job if this
>> class to handle any
>> conversions. Or, if you need to provide the Date in
>> different binary
>> flavors (util, sql), the class could do that tIn
>> this way it can be used
>> not only with the Struts tags but with JSLT tags and
>> other presentation
>> devices.
>>
>> I think in the end, we will all be using UI
>> components that make such
>> objects easier to plug into frameworks like Struts,
>> but such components
>> will need objects like these to do the dirty work.
>>
>> IMHO, this is the most Agile approach of all, since
>> it is easy to
>> implement and test, and can be reused time and
>> again.
>>
>> -Ted.
>>
>>
>>
>>
> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> struts-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> struts-dev-help@jakarta.apache.org
>>
>
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [BeanUtils & Struts]RE: Support for Date datatypes!!!
Posted by Jon Wilmoth <jo...@yahoo.com>.
Perhaps the focus of this discussion has been clouded
by my initial proposal. I hope this is the case and
not that people are not interested in addressing a
common complex problem that has been left to each
individual Struts implementor to resolve. So...let me
restate the objective and the points to date:
Objective: Provide users of the Struts framework
seemless, integrated support for custom formatted date
properties. This includes data entry as well as
rendering.
The current sequence of events (and thus the available
solution point(s)) are as follows -
Data input:
1) Taglibs render html control displaying current
value (if any) of form bean property
2) http get/post with string data --> framework pieces
--> RequestProcessor.processPopulate
3) RequestProcessor.processPopulate -->
RequestUtils.populate
4) RequestUtils.populate --> BeanUtils.populate(bean,
properties)
5) BeanUtils.populate(bean, properties) -->
ConvertUtils.convert
6) BeanUtils.populate(bean, properties) -->
PropertyUtils.setProperty (Indexed, Mapped or simple)
7) RequestProcessor.processValidate -->
RequestProcessor.processActionPerform (happy path)
8) Action executes and returns to step 1 (for
simplicity)
Points to Date:
* It has been suggested that all conversions be
performed by the BeanUtils package so that other
projects could leverage common code.
* It has also been suggested that a single object
other than ConvertUtils be responsible for date
conversions.
* A ui component model seems to be the "cure" for
increasing the robust nature of html controls as they
interact with java code.
* The solution has touch points with the struts
framework
* Other groups are addressing one or more aspects
(i.e. JSTL)
* A property descriptor type object had been mentioned
as a central place for defining numerous aspects of a
single property (i.e. min's, max's, conversions,
etc.).
* Solution should accomodate more abstract types of
custom conversion than simply dates? No use cases of
these other data types have been provided.
My questions then are;
1) Does the community see value in centralizing the
solution of dealing with custom formatted date
conversions? If not then the rest are sadly a moot
point.
2) If so, should Date --> String and String --> Date
conversion be in the same place? Which group/code
base can be recongnized as the "official" supported
location for this behavior?
3) How/Where does the Struts framework (tags, request
processor, etc.) interact with this code?
4) What role does the UI component model play in this?
Does it define the relationship between a control and
this "property descriptor"? Where is this model
defined? Struts? Commons? JavaServer Faces?
--- Ted Husted <hu...@apache.org> wrote:
> Joe Germuska wrote:
> > I'm still not completely convinced that the best
> solution isn't to
> > write your own ActionForm class that has two
> properties, 'date' and
> > 'dateAsString' (or whatever you want to call
> them) and behind the
> > scenes, when one of the properties simply sets
> and returns a data
> > member, and the other parses and formats values.
>
> +1
>
> IMHO, this problem is outside both the scope of
> Struts and ConvertUtils.
>
> There are myriad ways to handle expressions of date
> and time. Enough
> that they deserve their own UI class (or classes).
> The Java libraries
> provide all the functionality most of us need. The
> trick, as Joe pointed
> out, is to put that functionality behind a facade.
> Especially when you
> get to as many use-cases as have been enumerated
> here.
>
> IMHO, the solution is not to push the work off onto
> the tags or onto the
> framework, but to centralize it in your own date
> handler object that can
> be extended to do what you need it to do.
>
> After three years, we all have working solutions to
> this problem. Most,
> I would hazard to guess, are variations of Joe's
> approach. IMHO, work on
> this subject is best directed at a better
> date-handling object (or
> facade), that could be used by Struts or any other
> presentation
> application.
>
> Right now, I'm using a DateDisplay object to handle
> displaying dates in
> drop-down boxes and converting it back and forth:
>
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/wqdata/wqdata/src/java/shared/org_apache_commons/util/
>
> There are also some date/time/calendaring handling
> utilities under
> development in Commons Lang:
>
>
http://cvs.apache.org/viewcvs/jakarta-commons/lang/src/java/org/apache/commons/lang/time/
>
> The way I approach this problem is by defining a
> date handling class (or
> classes) that can talk to Struts and can also talk
> to the controller or
> your business classes. If a date need to be accepted
> in one format and
> presented in another, it should the job if this
> class to handle any
> conversions. Or, if you need to provide the Date in
> different binary
> flavors (util, sql), the class could do that tIn
> this way it can be used
> not only with the Struts tags but with JSLT tags and
> other presentation
> devices.
>
> I think in the end, we will all be using UI
> components that make such
> objects easier to plug into frameworks like Struts,
> but such components
> will need objects like these to do the dirty work.
>
> IMHO, this is the most Agile approach of all, since
> it is easy to
> implement and test, and can be reused time and
> again.
>
> -Ted.
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [BeanUtils & Struts]RE: Support for Date datatypes!!!
Posted by Jon Wilmoth <jo...@yahoo.com>.
Perhaps the focus of this discussion has been clouded
by my initial proposal. I hope this is the case and
not that people are not interested in addressing a
common complex problem that has been left to each
individual Struts implementor to resolve. So...let me
restate the objective and the points to date:
Objective: Provide users of the Struts framework
seemless, integrated support for custom formatted date
properties. This includes data entry as well as
rendering.
The current sequence of events (and thus the available
solution point(s)) are as follows -
Data input:
1) Taglibs render html control displaying current
value (if any) of form bean property
2) http get/post with string data --> framework pieces
--> RequestProcessor.processPopulate
3) RequestProcessor.processPopulate -->
RequestUtils.populate
4) RequestUtils.populate --> BeanUtils.populate(bean,
properties)
5) BeanUtils.populate(bean, properties) -->
ConvertUtils.convert
6) BeanUtils.populate(bean, properties) -->
PropertyUtils.setProperty (Indexed, Mapped or simple)
7) RequestProcessor.processValidate -->
RequestProcessor.processActionPerform (happy path)
8) Action executes and returns to step 1 (for
simplicity)
Points to Date:
* It has been suggested that all conversions be
performed by the BeanUtils package so that other
projects could leverage common code.
* It has also been suggested that a single object
other than ConvertUtils be responsible for date
conversions.
* A ui component model seems to be the "cure" for
increasing the robust nature of html controls as they
interact with java code.
* The solution has touch points with the struts
framework
* Other groups are addressing one or more aspects
(i.e. JSTL)
* A property descriptor type object had been mentioned
as a central place for defining numerous aspects of a
single property (i.e. min's, max's, conversions,
etc.).
* Solution should accomodate more abstract types of
custom conversion than simply dates? No use cases of
these other data types have been provided.
My questions then are;
1) Does the community see value in centralizing the
solution of dealing with custom formatted date
conversions? If not then the rest are sadly a moot
point.
2) If so, should Date --> String and String --> Date
conversion be in the same place? Which group/code
base can be recongnized as the "official" supported
location for this behavior?
3) How/Where does the Struts framework (tags, request
processor, etc.) interact with this code?
4) What role does the UI component model play in this?
Does it define the relationship between a control and
this "property descriptor"? Where is this model
defined? Struts? Commons? JavaServer Faces?
--- Ted Husted <hu...@apache.org> wrote:
> Joe Germuska wrote:
> > I'm still not completely convinced that the best
> solution isn't to
> > write your own ActionForm class that has two
> properties, 'date' and
> > 'dateAsString' (or whatever you want to call
> them) and behind the
> > scenes, when one of the properties simply sets
> and returns a data
> > member, and the other parses and formats values.
>
> +1
>
> IMHO, this problem is outside both the scope of
> Struts and ConvertUtils.
>
> There are myriad ways to handle expressions of date
> and time. Enough
> that they deserve their own UI class (or classes).
> The Java libraries
> provide all the functionality most of us need. The
> trick, as Joe pointed
> out, is to put that functionality behind a facade.
> Especially when you
> get to as many use-cases as have been enumerated
> here.
>
> IMHO, the solution is not to push the work off onto
> the tags or onto the
> framework, but to centralize it in your own date
> handler object that can
> be extended to do what you need it to do.
>
> After three years, we all have working solutions to
> this problem. Most,
> I would hazard to guess, are variations of Joe's
> approach. IMHO, work on
> this subject is best directed at a better
> date-handling object (or
> facade), that could be used by Struts or any other
> presentation
> application.
>
> Right now, I'm using a DateDisplay object to handle
> displaying dates in
> drop-down boxes and converting it back and forth:
>
>
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/wqdata/wqdata/src/java/shared/org_apache_commons/util/
>
> There are also some date/time/calendaring handling
> utilities under
> development in Commons Lang:
>
>
http://cvs.apache.org/viewcvs/jakarta-commons/lang/src/java/org/apache/commons/lang/time/
>
> The way I approach this problem is by defining a
> date handling class (or
> classes) that can talk to Struts and can also talk
> to the controller or
> your business classes. If a date need to be accepted
> in one format and
> presented in another, it should the job if this
> class to handle any
> conversions. Or, if you need to provide the Date in
> different binary
> flavors (util, sql), the class could do that tIn
> this way it can be used
> not only with the Struts tags but with JSLT tags and
> other presentation
> devices.
>
> I think in the end, we will all be using UI
> components that make such
> objects easier to plug into frameworks like Struts,
> but such components
> will need objects like these to do the dirty work.
>
> IMHO, this is the most Agile approach of all, since
> it is easy to
> implement and test, and can be reused time and
> again.
>
> -Ted.
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [BeanUtils & Struts]RE: Support for Date datatypes!!!
Posted by Ted Husted <hu...@apache.org>.
Joe Germuska wrote:
> I'm still not completely convinced that the best solution isn't to
> write your own ActionForm class that has two properties, 'date' and
> 'dateAsString' (or whatever you want to call them) and behind the
> scenes, when one of the properties simply sets and returns a data
> member, and the other parses and formats values.
+1
IMHO, this problem is outside both the scope of Struts and ConvertUtils.
There are myriad ways to handle expressions of date and time. Enough
that they deserve their own UI class (or classes). The Java libraries
provide all the functionality most of us need. The trick, as Joe pointed
out, is to put that functionality behind a facade. Especially when you
get to as many use-cases as have been enumerated here.
IMHO, the solution is not to push the work off onto the tags or onto the
framework, but to centralize it in your own date handler object that can
be extended to do what you need it to do.
After three years, we all have working solutions to this problem. Most,
I would hazard to guess, are variations of Joe's approach. IMHO, work on
this subject is best directed at a better date-handling object (or
facade), that could be used by Struts or any other presentation
application.
Right now, I'm using a DateDisplay object to handle displaying dates in
drop-down boxes and converting it back and forth:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/wqdata/wqdata/src/java/shared/org_apache_commons/util/
There are also some date/time/calendaring handling utilities under
development in Commons Lang:
http://cvs.apache.org/viewcvs/jakarta-commons/lang/src/java/org/apache/commons/lang/time/
The way I approach this problem is by defining a date handling class (or
classes) that can talk to Struts and can also talk to the controller or
your business classes. If a date need to be accepted in one format and
presented in another, it should the job if this class to handle any
conversions. Or, if you need to provide the Date in different binary
flavors (util, sql), the class could do that tIn this way it can be used
not only with the Struts tags but with JSLT tags and other presentation
devices.
I think in the end, we will all be using UI components that make such
objects easier to plug into frameworks like Struts, but such components
will need objects like these to do the dirty work.
IMHO, this is the most Agile approach of all, since it is easy to
implement and test, and can be reused time and again.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [BeanUtils & Struts]RE: Support for Date datatypes!!!
Posted by Joe Germuska <Jo...@Germuska.com>.
At 3:51 PM -0700 7/1/03, Jon Wilmoth wrote:
>These don't necessarily have to exist in the same
>form, but I don't see why they shouldn't be supported
>if they were. I disagree that the ConvertUtils should
>not be responsible for conversions of this sort.
My point is that the ConvertUtils libraries are built around a
specific metaphor, as embodied in the interface. Given a string (and
only a string), use a standard format template to convert that string
into a specific type.
As Robert Burrell Donkin noted in this thread on commons-dev, if your
solution involves changing the "Converter" interface, it's going to
be very hard to sell, as who knows how many people have implemented
Converter and would have to go changing those implementations.
Perhaps if you could pitch it as a wrapping layer around ConvertUtils
-- an "AdvancedConvertUtilsBean" class which could register
converters of some sub-interface which extends Converter.
Alternatively, take advantage of the fact that it's now possible to
deal with conversion using a ConvertUtilsBean (which hadn't been the
model of the original Struts form population) and devise a way to
build a new ConvertUtilsBean as necessary each time
processPopulateForm is called.
This won't be possible if you want one ConvertUtilsBean to convert
Strings in different formats to the same Date type -- in that case
you'd either need to go back to the AdvancedConvertUtilsBean
approach, or declare your form properties to be of various subtypes
of java.util.Date, each of which might have a different Converter
registered. (com.foo.Time extends java.util.Date, registered with
"HH:mm"; com.foo.Month extends java.util.Date, registered with a
converter "MMMM", etc...)
The ConvertUtilsBean seems somewhat more promising to me, but coming
up with a clean design that is not a burden on people who don't need
it still seems like more work than declaring your form properties to
be strings and dealing with the conversion in business objects...
Joe
--
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time."
--Jaron Lanier
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [BeanUtils & Struts]RE: Support for Date datatypes!!!
Posted by Jon Wilmoth <jo...@yahoo.com>.
These don't necessarily have to exist in the same
form, but I don't see why they shouldn't be supported
if they were. I disagree that the ConvertUtils should
not be responsible for conversions of this sort. If
not there where would you suggest they go? I've been
using the "extra" bean property as you described below
for 1+ years and it works, but to me this is an
unnecessary workaround. Struts does not ask FormBean
providers to provide String "holders" and convertion
routines for Longs, Integers, etc and in my opinion it
shouldn't for dates. Given the common usage of dates
in applications, requiring one of the fundamental
datatypes to be handled by every team using struts
seems wrong to me.
--- Joe Germuska <Jo...@Germuska.com> wrote:
> OK, good, different kinds of dates (calendar dates,
> times, and
> months) is a good case -- now, do these co-exist in
> the same form?
> It's definitely stretching the idea of ConvertUtils
> to think that it
> would need to convert differently formatted strings
> into the same
> object type.
>
> I'm still not completely convinced that the best
> solution isn't to
> write your own ActionForm class that has two
> properties, 'date' and
> 'dateAsString' (or whatever you want to call them)
> and behind the
> scenes, when one of the properties simply sets and
> returns a data
> member, and the other parses and formats values.
>
> I'm not trying to shut you out -- and besides, I'm
> not a committer,
> so I couldn't if I tried. I just like debating
> these kinds of design
> questions and I'm criticizing in that spirit.
>
> Joe
>
>
> At 11:50 AM -0700 7/1/03, Jon Wilmoth wrote:
> >The problem is I have existing code that does
> custom
> >string --> date --> string conversion. I'm not
> >looking for a better work-around. I believe this
> is
> >functionality that everyone who builds a struts
> >application will have to implement with custom code
> >and thus is an excellent Struts/BeanUtils
> enhancement
> >candidate! I do realize this is NOT a simple task
> as
> >it has come up on the mailing list a number of
> times
> >in the last 3 years and still remains not
> implemented.
> > Here are some use cases that illustrate the
> desired
> >behavior (remember, I'm looking for round-trip
> support
> >of the date datatype):
> >
> >Use Case 1 (Data Input):
> >1) User enter's birthdate in MM/dd/yyyy format
> >..
> >Use Case 2 (Data Input):
> >1) User standard workday start time in "HH:mm"
> format
> >..
> >Use Case 3 (Data Input):
> >1) User enters month of year for month long event
> >(i.e. Black History Month) "MMMM" format
> >..
> >
> >Use Case 3 (Data Output):
> >1) User Admin views list of user names and
> birthdays.
> >2) System displays username and birthday using
> >standard MM/dd/yyyy format.
> >2.a) System will display date in format specified
> by
> >user preferences (i.e. EE MMMM dd yyyy) overriding
> the
> >standard MM/dd/yyyy format.
> >
> >--- Joe Germuska <Jo...@Germuska.com> wrote:
> >> At 10:45 AM -0700 7/1/03, Jon Wilmoth wrote:
> >> >I did investigate registering "custom"
> converters.
> >> >Unfortunately, anything that would support
> >> >non-hard-coded conversion patterns will require
> >> either
> >> >a mixed paradygm usage (i.e passing a complex
> >> object
> >> >that contains the value to convert and all
> >> convertion
> >> >configuration instead of simply the value to be
> >> >converted) of the existing Converter.convert
> >> interface
> >> >or additional parameters. Since I think
> everyone
> >> can
> >> >agree that the first option is confusing and
> should
> >> be
> >> >avoided when possible the remaining option is
> to
> >> >modify/extend the interface. I agree this
> should
> >> be
> >> >communicated within the BeanUtils developer
> mailing
> >> >list and will cross post this in hopes of
> getting
> >> >further creative approaches to the problem.
> >> Because
> >> >Struts will be responsible for providing the
> means
> >> to
> >> >invoke the conversion (and much more) I do feel
> it
> >> is
> >> >appropriate for this list to continue to
> discuss
> >> the
> >> >Struts/BeanUtil interaction necessary for this
> >> >functionality.
> >>
> >> Do you have one or two primary use cases? I
> don't
> >> think it needs to
> >> be radically complicated, but it might be easier
> to
> >> tell with a
> >> concrete description of the problem to solve.
> >>
> >> In general, Struts gives you lots of places you
> >> could pass in a date
> >> format string as a property (to an ActionForm,
> to an
> >> ActionMapping,
> >> to a PlugIn... in most applications, I would
> assume
> >> you'd have one
> >> standard date input format, so you don't need to
> >> configure a variety
> >> of format strings, although if you have a use
> case
> >> for that, feel
> >> free to describe it.
> >>
> >> So if you can pass in a format string to some
> custom
> >> code that you
> >> write that can take a String from an ActionForm
> and
> >> make it a Date
> >> before it goes into your business objects, does
> that
> >> solve the
> > > problem? The alternative is solving the very,
> very
> >> complicated
> >> problem of generalizing string-to-object
> conversion
> >> for anything that
> >> has a variable string representation, including
> but
> >> not limited to
> >> Dates. (Or having a special-case hanging off of
> >> ConvertUtils like a
> >> third leg...)
> >>
> >> Joe
> >> --
> >> --
> >> Joe Germuska
> >> Joe@Germuska.com
> >> http://blog.germuska.com
> >> "If nature worked that way, the universe would
> crash
> >> all the time."
> >> --Jaron Lanier
> >>
> >>
>
>---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> >> struts-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail:
> >> struts-dev-help@jakarta.apache.org
> >>
> >
> >
> >__________________________________
> >Do you Yahoo!?
> >SBC Yahoo! DSL - Now only $29.95 per month!
> >http://sbc.yahoo.com
> >
>
>---------------------------------------------------------------------
> >To unsubscribe, e-mail:
> struts-dev-unsubscribe@jakarta.apache.org
> >For additional commands, e-mail:
> struts-dev-help@jakarta.apache.org
>
>
> --
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "If nature worked that way, the universe would crash
> all the time."
> --Jaron Lanier
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [BeanUtils & Struts]RE: Support for Date datatypes!!!
Posted by Joe Germuska <Jo...@Germuska.com>.
OK, good, different kinds of dates (calendar dates, times, and
months) is a good case -- now, do these co-exist in the same form?
It's definitely stretching the idea of ConvertUtils to think that it
would need to convert differently formatted strings into the same
object type.
I'm still not completely convinced that the best solution isn't to
write your own ActionForm class that has two properties, 'date' and
'dateAsString' (or whatever you want to call them) and behind the
scenes, when one of the properties simply sets and returns a data
member, and the other parses and formats values.
I'm not trying to shut you out -- and besides, I'm not a committer,
so I couldn't if I tried. I just like debating these kinds of design
questions and I'm criticizing in that spirit.
Joe
At 11:50 AM -0700 7/1/03, Jon Wilmoth wrote:
>The problem is I have existing code that does custom
>string --> date --> string conversion. I'm not
>looking for a better work-around. I believe this is
>functionality that everyone who builds a struts
>application will have to implement with custom code
>and thus is an excellent Struts/BeanUtils enhancement
>candidate! I do realize this is NOT a simple task as
>it has come up on the mailing list a number of times
>in the last 3 years and still remains not implemented.
> Here are some use cases that illustrate the desired
>behavior (remember, I'm looking for round-trip support
>of the date datatype):
>
>Use Case 1 (Data Input):
>1) User enter's birthdate in MM/dd/yyyy format
>..
>Use Case 2 (Data Input):
>1) User standard workday start time in "HH:mm" format
>..
>Use Case 3 (Data Input):
>1) User enters month of year for month long event
>(i.e. Black History Month) "MMMM" format
>..
>
>Use Case 3 (Data Output):
>1) User Admin views list of user names and birthdays.
>2) System displays username and birthday using
>standard MM/dd/yyyy format.
>2.a) System will display date in format specified by
>user preferences (i.e. EE MMMM dd yyyy) overriding the
>standard MM/dd/yyyy format.
>
>--- Joe Germuska <Jo...@Germuska.com> wrote:
>> At 10:45 AM -0700 7/1/03, Jon Wilmoth wrote:
>> >I did investigate registering "custom" converters.
>> >Unfortunately, anything that would support
>> >non-hard-coded conversion patterns will require
>> either
>> >a mixed paradygm usage (i.e passing a complex
>> object
>> >that contains the value to convert and all
>> convertion
>> >configuration instead of simply the value to be
>> >converted) of the existing Converter.convert
>> interface
>> >or additional parameters. Since I think everyone
>> can
>> >agree that the first option is confusing and should
>> be
>> >avoided when possible the remaining option is to
>> >modify/extend the interface. I agree this should
>> be
>> >communicated within the BeanUtils developer mailing
>> >list and will cross post this in hopes of getting
>> >further creative approaches to the problem.
>> Because
>> >Struts will be responsible for providing the means
>> to
>> >invoke the conversion (and much more) I do feel it
>> is
>> >appropriate for this list to continue to discuss
>> the
>> >Struts/BeanUtil interaction necessary for this
>> >functionality.
>>
>> Do you have one or two primary use cases? I don't
>> think it needs to
>> be radically complicated, but it might be easier to
>> tell with a
>> concrete description of the problem to solve.
>>
>> In general, Struts gives you lots of places you
>> could pass in a date
>> format string as a property (to an ActionForm, to an
>> ActionMapping,
>> to a PlugIn... in most applications, I would assume
>> you'd have one
>> standard date input format, so you don't need to
>> configure a variety
>> of format strings, although if you have a use case
>> for that, feel
>> free to describe it.
>>
>> So if you can pass in a format string to some custom
>> code that you
>> write that can take a String from an ActionForm and
>> make it a Date
>> before it goes into your business objects, does that
>> solve the
> > problem? The alternative is solving the very, very
>> complicated
>> problem of generalizing string-to-object conversion
>> for anything that
>> has a variable string representation, including but
>> not limited to
>> Dates. (Or having a special-case hanging off of
>> ConvertUtils like a
>> third leg...)
>>
>> Joe
>> --
>> --
>> Joe Germuska
>> Joe@Germuska.com
>> http://blog.germuska.com
>> "If nature worked that way, the universe would crash
>> all the time."
>> --Jaron Lanier
>>
>>
>---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> struts-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> struts-dev-help@jakarta.apache.org
>>
>
>
>__________________________________
>Do you Yahoo!?
>SBC Yahoo! DSL - Now only $29.95 per month!
>http://sbc.yahoo.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-dev-help@jakarta.apache.org
--
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time."
--Jaron Lanier
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [BeanUtils & Struts]RE: Support for Date datatypes!!!
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Tue, 1 Jul 2003, Jon Wilmoth wrote:
> Date: Tue, 1 Jul 2003 11:50:59 -0700 (PDT)
> From: Jon Wilmoth <jo...@yahoo.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>,
> jonwilmoth@yahoo.com
> To: Struts Developers List <st...@jakarta.apache.org>
> Subject: Re: [BeanUtils & Struts]RE: Support for Date datatypes!!!
>
> The problem is I have existing code that does custom
> string --> date --> string conversion. I'm not
> looking for a better work-around. I believe this is
> functionality that everyone who builds a struts
> application will have to implement with custom code
> and thus is an excellent Struts/BeanUtils enhancement
> candidate! I do realize this is NOT a simple task as
> it has come up on the mailing list a number of times
> in the last 3 years and still remains not implemented.
> Here are some use cases that illustrate the desired
> behavior (remember, I'm looking for round-trip support
> of the date datatype):
>
If it were easy, it would have been done already :-).
> Use Case 1 (Data Input):
> 1) User enter's birthdate in MM/dd/yyyy format
> ..
In most of Europe, and many other places, that would be dd/MM/yyyy.
> Use Case 2 (Data Input):
> 1) User standard workday start time in "HH:mm" format
> ..
12 hour clock or 24 hour clock?
> Use Case 3 (Data Input):
> 1) User enters month of year for month long event
> (i.e. Black History Month) "MMMM" format
> ..
Presumably the user can specify this in whatever language they like?
>
> Use Case 3 (Data Output):
> 1) User Admin views list of user names and birthdays.
> 2) System displays username and birthday using
> standard MM/dd/yyyy format.
That's not the "standard" in many places.
> 2.a) System will display date in format specified by
> user preferences (i.e. EE MMMM dd yyyy) overriding the
> standard MM/dd/yyyy format.
This is where solutions based on ConvertUtils really fall down, because
Converters are web-app wide. It's one of the symptoms of the fact that
Struts doesn't really support UI "components" at the moment -- it just
supports simple fields.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [BeanUtils & Struts]RE: Support for Date datatypes!!!
Posted by Jon Wilmoth <jo...@yahoo.com>.
The problem is I have existing code that does custom
string --> date --> string conversion. I'm not
looking for a better work-around. I believe this is
functionality that everyone who builds a struts
application will have to implement with custom code
and thus is an excellent Struts/BeanUtils enhancement
candidate! I do realize this is NOT a simple task as
it has come up on the mailing list a number of times
in the last 3 years and still remains not implemented.
Here are some use cases that illustrate the desired
behavior (remember, I'm looking for round-trip support
of the date datatype):
Use Case 1 (Data Input):
1) User enter's birthdate in MM/dd/yyyy format
..
Use Case 2 (Data Input):
1) User standard workday start time in "HH:mm" format
..
Use Case 3 (Data Input):
1) User enters month of year for month long event
(i.e. Black History Month) "MMMM" format
..
Use Case 3 (Data Output):
1) User Admin views list of user names and birthdays.
2) System displays username and birthday using
standard MM/dd/yyyy format.
2.a) System will display date in format specified by
user preferences (i.e. EE MMMM dd yyyy) overriding the
standard MM/dd/yyyy format.
--- Joe Germuska <Jo...@Germuska.com> wrote:
> At 10:45 AM -0700 7/1/03, Jon Wilmoth wrote:
> >I did investigate registering "custom" converters.
> >Unfortunately, anything that would support
> >non-hard-coded conversion patterns will require
> either
> >a mixed paradygm usage (i.e passing a complex
> object
> >that contains the value to convert and all
> convertion
> >configuration instead of simply the value to be
> >converted) of the existing Converter.convert
> interface
> >or additional parameters. Since I think everyone
> can
> >agree that the first option is confusing and should
> be
> >avoided when possible the remaining option is to
> >modify/extend the interface. I agree this should
> be
> >communicated within the BeanUtils developer mailing
> >list and will cross post this in hopes of getting
> >further creative approaches to the problem.
> Because
> >Struts will be responsible for providing the means
> to
> >invoke the conversion (and much more) I do feel it
> is
> >appropriate for this list to continue to discuss
> the
> >Struts/BeanUtil interaction necessary for this
> >functionality.
>
> Do you have one or two primary use cases? I don't
> think it needs to
> be radically complicated, but it might be easier to
> tell with a
> concrete description of the problem to solve.
>
> In general, Struts gives you lots of places you
> could pass in a date
> format string as a property (to an ActionForm, to an
> ActionMapping,
> to a PlugIn... in most applications, I would assume
> you'd have one
> standard date input format, so you don't need to
> configure a variety
> of format strings, although if you have a use case
> for that, feel
> free to describe it.
>
> So if you can pass in a format string to some custom
> code that you
> write that can take a String from an ActionForm and
> make it a Date
> before it goes into your business objects, does that
> solve the
> problem? The alternative is solving the very, very
> complicated
> problem of generalizing string-to-object conversion
> for anything that
> has a variable string representation, including but
> not limited to
> Dates. (Or having a special-case hanging off of
> ConvertUtils like a
> third leg...)
>
> Joe
> --
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "If nature worked that way, the universe would crash
> all the time."
> --Jaron Lanier
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
[BeanUtils & Struts]RE: Support for Date datatypes!!!
Posted by Joe Germuska <Jo...@Germuska.com>.
At 10:45 AM -0700 7/1/03, Jon Wilmoth wrote:
>I did investigate registering "custom" converters.
>Unfortunately, anything that would support
>non-hard-coded conversion patterns will require either
>a mixed paradygm usage (i.e passing a complex object
>that contains the value to convert and all convertion
>configuration instead of simply the value to be
>converted) of the existing Converter.convert interface
>or additional parameters. Since I think everyone can
>agree that the first option is confusing and should be
>avoided when possible the remaining option is to
>modify/extend the interface. I agree this should be
>communicated within the BeanUtils developer mailing
>list and will cross post this in hopes of getting
>further creative approaches to the problem. Because
>Struts will be responsible for providing the means to
>invoke the conversion (and much more) I do feel it is
>appropriate for this list to continue to discuss the
>Struts/BeanUtil interaction necessary for this
>functionality.
Do you have one or two primary use cases? I don't think it needs to
be radically complicated, but it might be easier to tell with a
concrete description of the problem to solve.
In general, Struts gives you lots of places you could pass in a date
format string as a property (to an ActionForm, to an ActionMapping,
to a PlugIn... in most applications, I would assume you'd have one
standard date input format, so you don't need to configure a variety
of format strings, although if you have a use case for that, feel
free to describe it.
So if you can pass in a format string to some custom code that you
write that can take a String from an ActionForm and make it a Date
before it goes into your business objects, does that solve the
problem? The alternative is solving the very, very complicated
problem of generalizing string-to-object conversion for anything that
has a variable string representation, including but not limited to
Dates. (Or having a special-case hanging off of ConvertUtils like a
third leg...)
Joe
--
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time."
--Jaron Lanier
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: Validwhen returns, need some pixie dust on the nightly build machine
Posted by James Turner <tu...@blackbear.com>.
Never mind again, someone already created an antlr project.
James
> -----Original Message-----
> From: James Turner [mailto:turner@blackbear.com]
> Sent: Tuesday, July 01, 2003 6:51 PM
> To: 'Struts Developers List'
> Cc: rleland@apache.org
> Subject: RE: Validwhen returns, need some pixie dust on the
> nightly build machine
>
>
> Am I missing something here?
>
> [turner@linux jakarta]$ cvs -d turner@cvs.apache.org:/home/cvs co gump
>
> Password:
> cvs server: cannot find module `gump' - ignored
>
> > From: Rob Leland [mailto:rleland@apache.org]
> >
> > Check out gump from cvs.apache.org and add a dependancy to the
> > jakarta-struts.xml.
> >
> > -Rob
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: Validwhen returns, need some pixie dust on the nightly build machine
Posted by James Turner <tu...@blackbear.com>.
Never mind on the first point, it's jakarta-gump...
However, how do I add a dependency to a jar file that is sourced outside
the Jakarta/Apache project space?
James
> -----Original Message-----
> From: James Turner [mailto:turner@blackbear.com]
> Sent: Tuesday, July 01, 2003 6:51 PM
> To: 'Struts Developers List'
> Cc: rleland@apache.org
> Subject: RE: Validwhen returns, need some pixie dust on the
> nightly build machine
>
>
> Am I missing something here?
>
> [turner@linux jakarta]$ cvs -d turner@cvs.apache.org:/home/cvs co gump
>
> Password:
> cvs server: cannot find module `gump' - ignored
>
> > From: Rob Leland [mailto:rleland@apache.org]
> >
> > Check out gump from cvs.apache.org and add a dependancy to the
> > jakarta-struts.xml.
> >
> > -Rob
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: Validwhen returns, need some pixie dust on the nightly build machine
Posted by James Turner <tu...@blackbear.com>.
Am I missing something here?
[turner@linux jakarta]$ cvs -d turner@cvs.apache.org:/home/cvs co gump
Password:
cvs server: cannot find module `gump' - ignored
> From: Rob Leland [mailto:rleland@apache.org]
>
> Check out gump from cvs.apache.org and add a dependancy to the
> jakarta-struts.xml.
>
> -Rob
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Validwhen returns, need some pixie dust on the nightly build
machine
Posted by Rob Leland <rl...@apache.org>.
James Turner wrote:
>Ummm, ok... Where does it live?
>
>James
>
>
>
>>-----Original Message-----
>>From: news [mailto:news@main.gmane.org] On Behalf Of Martin Cooper
>>Sent: Tuesday, July 01, 2003 3:31 PM
>>To: struts-dev@jakarta.apache.org
>>Subject: Re: Validwhen returns, need some pixie dust on the
>>nightly build machine
>>
>>
>>James, you'll need to update the Gump descriptor too,
>>otherwise we're going to start seeing Gump failure messages again. ;-(
>>
>>--
>>Martin Cooper
>>
Check out gump from cvs.apache.org and add a dependancy to the
jakarta-struts.xml.
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: Validwhen returns, need some pixie dust on the nightly build machine
Posted by James Turner <tu...@blackbear.com>.
Ummm, ok... Where does it live?
James
> -----Original Message-----
> From: news [mailto:news@main.gmane.org] On Behalf Of Martin Cooper
> Sent: Tuesday, July 01, 2003 3:31 PM
> To: struts-dev@jakarta.apache.org
> Subject: Re: Validwhen returns, need some pixie dust on the
> nightly build machine
>
>
> James, you'll need to update the Gump descriptor too,
> otherwise we're going to start seeing Gump failure messages again. ;-(
>
> --
> Martin Cooper
>
>
> "James Turner" <tu...@blackbear.com> wrote in message
news:014601c33ff9$d9af5960$124f3e18@blackbear...
Ok, now that the dust is settling on 1.1, I've re-checked-in the
validwhen validator, but in order for the nightlies not to break, the
antlr.jar file (available from http://www.antlr.org/download/) needs to
be put on the build machine and the antlr.jar property in
build.properties needs to point to it.
James
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Validwhen returns, need some pixie dust on the nightly build machine
Posted by Martin Cooper <ma...@apache.org>.
James, you'll need to update the Gump descriptor too, otherwise we're going
to start seeing Gump failure messages again. ;-(
--
Martin Cooper
"James Turner" <tu...@blackbear.com> wrote in message
news:014601c33ff9$d9af5960$124f3e18@blackbear...
Ok, now that the dust is settling on 1.1, I've re-checked-in the
validwhen validator, but in order for the nightlies not to break, the
antlr.jar file (available from http://www.antlr.org/download/) needs to
be put on the build machine and the antlr.jar property in
build.properties needs to point to it.
James
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Validwhen returns, need some pixie dust on the nightly build machine
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
I forwarded our thread on to my friend, Drew (the creator of OGNL), and
he replied with this:
> Begin forwarded message:
>
>> Well, I used ANTLR because I'm familiar with LALR(1) parsers, and I
>> knew
>> I could make it work. Also, I don't think (from a quick look at the
>> documentation) that you can do the Foo[] syntax (which I use to drop
>> in
>> the index count of the current indexed property) using OGNL. On the
>> other hand, I'm not at all wedded to ANTLR, if someone wants to take a
>> shot at implementing the grammer using another tool, that's great.
>
OGNL used to use ANTLR but moved away some time ago to use JavaCC. It
allowed OGNL to be deployed as a standalone unit without having to
carry around another jar file. Plus complaints were heard because some
people used ANTLR for other parts of the project and the version that
OGNL required was not compatible. So JavaCC is a Good Thing in this
regard.
I'm willing to bet that just about anything you want to do with an
expression language is doable with OGNL. It really gives you all the
power of Java within the language plus lots of niceties for working
with collections (projection and selection), provides "lambda
expressions" for encapsulated functions that can be called within OGNL.
I'm not sure what the Foo[] syntax is but OGNL has powerful indexing
facilities, both JavaBeans indexed properties (i.e. getFoo(int
i)/setFoo(int i, Object o)) and "object indexed properties", which is
new to 2.6.0. Object indexed properties allow you do access things
that look like indexed properties (getAttribute(String
name)/setAttribute(String name, Object value)) as indexed properties
(i.e. request.attributes["foo"]) without having to call a method. Is
any of this what he means?
>> On a side note, one of the things I'm unhappy with is that I have to
>> use
>> AND and OR rather than && and ||, because when I used &&, it blows up
>> the XML parsing of validation.xml. Is there a way to get around this?
>
Well...as far as the && syntax goes XML is not forgiving unless you use
CDATA segments. For expressions that are part of attribute values you
don't have any way around it.
So instead of :
<expression>this && that</expression>
you have:
<expression><![CDATA[ this && that ]]></expression>
or:
<expression>
<![CDATA[
this && that
]]>
</expression>
It's up to you to decide which is more readable. _I_ think it's
gobbledygook any way you slice it.
The issue here is really only the &, && and < operators because it
interferes with the XML reserved characters. Everything else works
fine. It's a real bummer.
- Drew
--
+---------------------------------+
< Drew Davidson | OGNL Technology >
< Professional Open Source >
+---------------------------------+
| Email: drew@ognl.org /
| Web: http://www.ognl.org /
| Vox: (520) 531-1966 <
| Fax: (520) 531-1965 \
| Mobile: (520) 405-2967 \
+---------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: Validwhen returns, need some pixie dust on the nightly build machine
Posted by James Turner <tu...@blackbear.com>.
Well, I used ANTLR because I'm familiar with LALR(1) parsers, and I knew
I could make it work. Also, I don't think (from a quick look at the
documentation) that you can do the Foo[] syntax (which I use to drop in
the index count of the current indexed property) using OGNL. On the
other hand, I'm not at all wedded to ANTLR, if someone wants to take a
shot at implementing the grammer using another tool, that's great.
On a side note, one of the things I'm unhappy with is that I have to use
AND and OR rather than && and ||, because when I used &&, it blows up
the XML parsing of validation.xml. Is there a way to get around this?
James
> -----Original Message-----
> From: Erik Hatcher [mailto:jakarta-struts@ehatchersolutions.com]
> Sent: Tuesday, July 01, 2003 3:10 PM
> To: Struts Developers List
> Subject: Re: Validwhen returns, need some pixie dust on the
> nightly build machine
>
>
> Could we revisit why OGNL was not used for this?
>
> Both WebWork2 and Tapestry use OGNL extensively. OGNL is extremely
> powerful and practically a defacto expression language these days.
>
> Erik
>
> On Tuesday, July 1, 2003, at 01:54 PM, James Turner wrote:
> > Ok, now that the dust is settling on 1.1, I've re-checked-in the
> > validwhen validator, but in order for the nightlies not to
> break, the
> > antlr.jar file (available from
> http://www.antlr.org/download/) > needs
> > to be put on the
> build machine and the antlr.jar property in
> > build.properties needs to point to it.
> >
> > James
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Validwhen returns, need some pixie dust on the nightly build machine
Posted by Erik Hatcher <ja...@ehatchersolutions.com>.
Could we revisit why OGNL was not used for this?
Both WebWork2 and Tapestry use OGNL extensively. OGNL is extremely
powerful and practically a defacto expression language these days.
Erik
On Tuesday, July 1, 2003, at 01:54 PM, James Turner wrote:
> Ok, now that the dust is settling on 1.1, I've re-checked-in the
> validwhen validator, but in order for the nightlies not to break, the
> antlr.jar file (available from http://www.antlr.org/download/) needs to
> be put on the build machine and the antlr.jar property in
> build.properties needs to point to it.
>
> James
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Validwhen returns, need some pixie dust on the nightly build machine
Posted by James Turner <tu...@blackbear.com>.
Ok, now that the dust is settling on 1.1, I've re-checked-in the
validwhen validator, but in order for the nightlies not to break, the
antlr.jar file (available from http://www.antlr.org/download/) needs to
be put on the build machine and the antlr.jar property in
build.properties needs to point to it.
James
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org