commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Wilmoth <jonwilm...@yahoo.com>
Subject Re: [BeanUtils & Struts]RE: Support for Date datatypes!!!
Date Wed, 02 Jul 2003 18:17:59 GMT
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 <husted@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


Mime
View raw message