(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 <[EMAIL PROTECTED]> wrote:Joe Germuska wrote:I'm still not completely convinced that the bestsolution isn't towrite your own ActionForm class that has twoproperties, 'date' and'dateAsString' (or whatever you want to callthem) and behind thescenes, when one of the properties simply setsand returns a datamember, 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
__________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
