commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [BeanUtils & Struts]RE: Support for Date datatypes!!!
Date Wed, 02 Jul 2003 20:46:43 GMT
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 <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
>


---------------------------------------------------------------------
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