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 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: > [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]
