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
Joe Germuska wrote:
I've been wishing that form declaration was unified, rather than using
struts-config for some and validator for another part. Now to think
about what to actually do about it, hmmm.
This looks promising:
http://sourceforge.net/projects/formproc
-Ted.
--
Ted Husted,
Struts i
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
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
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 cla
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
> me
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
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
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 a
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 co
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 enh
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 convertio
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
[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" ob
> I appreciate centralizing properties, but I think some
> of the properties you mentioned (i.e. style,
> title/titleKey, etc.) are not really in the buffer
> space, but solidly fixed in the html/jsp space. I
> think it is probably a violation of the separation of
> concerns to define such UI spec
I agree the proposal was not a wholistic solution, but
it did address an very real issue with a "doable"
timeframe. Since every application I've every been
involved with has had to solve date conversions, I
believe this is an ideal extension to the framework.
It should be noted that date support
Some of what Ted says sounds similar to the things I use to generate
UIs in Meta-jb (http://meta-jb.sourceforge.net/). While still
incomplete and not yet html-ready, there might still be some ideas
you guys can borrow.
-Paul
Joe Germuska wrote:
>
> Right on, Ted! I hadn't formulated my reacti
Right on, Ted! I hadn't formulated my reaction, but my reaction was
that this belongs in the form configuration rather than in tag
libraries.
I've been wishing that form declaration was unified, rather than
using struts-config for some and validator for another part. Now to
think about what
Fixing ConvertUtils would seem like a better solution to me than making
this many workarounds to support a single data type.
If we make these kind of patches to Struts, we've only "helped" Struts.
If we fix ConvertUtils, we can help any other application or framework
that uses ConvertUtils.
I
As I've found with my involvement in contributing to
the Bugzilla project, radification/confirmation of
design/implementation details is critical to
acceptance of a submitted patch. Below are the
changes I propose to make this happen. The String -->
Date direction is significanly more involved th
At 11:23 -0700 6/27/03, Jon Wilmoth wrote:
I'm reposting as the previous attempt may have gotten
lost in the new release excitement.
I'd like to know what the CURRENT plans are for
supporting date datatypes in the framework. This
means conversion of strings --> dates for FormBean
population and th
21 matches
Mail list logo
