You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Craig R. McClanahan" <cr...@apache.org> on 2003/06/27 19:17:39 UTC
[VOTE] Release Vote: Struts-Faces Integration Library 0.4
The Struts-Faces integration library (in directory "contrib/struts-faces"
of the Struts CVS repository) is an adapter layer that allows the use of
components and renderers provided by JavaServer Faces (under development
via JSR-127 in the Java Community Process). Version 0.4 of this library,
currently available at:
http://jakarta.apache.org/builds/jakarta-struts/release/struts-faces/
corresponds to the EA4 release of JavaServer Faces reference
implementation, which is available as part of the Java Web Services
Developer Pack 1.2 release:
http://java.sun.com/webservices/
For historical legacy, the 0.3 version of the library (originally posted
in a nightly build directory), which corresponds to the EA3 release of
JavaServer Faces, is also made available in the release directory.
This is a formal vote to release version 0.4 of the integration library as
an official distribution from the Struts Project:
------- [VOTING SLIP: Struts-Faces Integration Library 0.4] -------------
[ ] +1 - I am in favor of this release, and can help
[ ] +0 - I am in favor of this release, but cannot help
[ ] -0 - I am not in favor of this release
[ ] -1 - I am against this proposal (must include a reason)
---------------------------------------------------------------------------
Here's my +1.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] Release Vote: Struts-Faces Integration Library 0.4
Posted by Martin Cooper <ma...@apache.org>.
On Fri, 27 Jun 2003, Craig R. McClanahan wrote:
> This is a formal vote to release version 0.4 of the integration library as
> an official distribution from the Struts Project:
>
> ------- [VOTING SLIP: Struts-Faces Integration Library 0.4] -------------
> [X] +1 - I am in favor of this release, and can help
> [ ] +0 - I am in favor of this release, but cannot help
> [ ] -0 - I am not in favor of this release
> [ ] -1 - I am against this proposal (must include a reason)
> ---------------------------------------------------------------------------
--
Martin Cooper
>
> Here's my +1.
>
> Craig
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] Release Vote: Struts-Faces Integration Library 0.4
Posted by James Mitchell <jm...@apache.org>.
On Friday 27 June 2003 13:17, Craig R. McClanahan wrote:
>
> ------- [VOTING SLIP: Struts-Faces Integration Library 0.4] -------------
> [X] +1 - I am in favor of this release, and can help, after I get back
> from vacation ;)
> [ ] +0 - I am in favor of this release, but cannot help
> [ ] -0 - I am not in favor of this release
> [ ] -1 - I am against this proposal (must include a reason)
> ---------------------------------------------------------------------------
>
> Craig
--
James Mitchell
Software Developer/Struts Evangelist
http://www.struts-atlanta.org
770-822-3359
AIM:jmitchtx
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: [VOTE] Release Vote: Struts-Faces Integration Library 0.4
Posted by James Turner <tu...@blackbear.com>.
+1 too
> -----Original Message-----
> From: David Graham [mailto:grahamdavid1980@yahoo.com]
> Sent: Friday, June 27, 2003 2:49 PM
> To: Struts Developers List
> Subject: Re: [VOTE] Release Vote: Struts-Faces Integration Library 0.4
>
>
> +1
>
> David
>
> --- "Craig R. McClanahan" <cr...@apache.org> wrote:
> > The Struts-Faces integration library (in directory
> > "contrib/struts-faces" of the Struts CVS repository) is an adapter
> > layer that allows the use of components and renderers provided by
> > JavaServer Faces (under development via JSR-127 in the Java
> Community
> > Process). Version 0.4 of this library,
> > currently available at:
> >
> >
> >
> http://jakarta.apache.org/builds/jakarta-struts/release/struts-faces/
> >
> > corresponds to the EA4 release of JavaServer Faces reference
> > implementation, which is available as part of the Java Web Services
> > Developer Pack 1.2 release:
> >
> > http://java.sun.com/webservices/
> >
> > For historical legacy, the 0.3 version of the library (originally
> > posted in a nightly build directory), which corresponds to the EA3
> > release of JavaServer Faces, is also made available in the release
> > directory.
> >
> > This is a formal vote to release version 0.4 of the integration
> > library as an official distribution from the Struts Project:
> >
> > ------- [VOTING SLIP: Struts-Faces Integration Library 0.4]
> > -------------
> > [ ] +1 - I am in favor of this release, and can help
> > [ ] +0 - I am in favor of this release, but cannot help
> > [ ] -0 - I am not in favor of this release
> > [ ] -1 - I am against this proposal (must include a reason)
> >
> --------------------------------------------------------------
> -------------
> >
> > Here's my +1.
> >
> > Craig
> >
> >
> >
> ---------------------------------------------------------------------
> > 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: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [VOTE] Release Vote: Struts-Faces Integration Library 0.4
Posted by David Graham <gr...@yahoo.com>.
+1
David
--- "Craig R. McClanahan" <cr...@apache.org> wrote:
> The Struts-Faces integration library (in directory
> "contrib/struts-faces"
> of the Struts CVS repository) is an adapter layer that allows the use of
> components and renderers provided by JavaServer Faces (under development
> via JSR-127 in the Java Community Process). Version 0.4 of this
> library,
> currently available at:
>
> http://jakarta.apache.org/builds/jakarta-struts/release/struts-faces/
>
> corresponds to the EA4 release of JavaServer Faces reference
> implementation, which is available as part of the Java Web Services
> Developer Pack 1.2 release:
>
> http://java.sun.com/webservices/
>
> For historical legacy, the 0.3 version of the library (originally posted
> in a nightly build directory), which corresponds to the EA3 release of
> JavaServer Faces, is also made available in the release directory.
>
> This is a formal vote to release version 0.4 of the integration library
> as
> an official distribution from the Struts Project:
>
> ------- [VOTING SLIP: Struts-Faces Integration Library 0.4]
> -------------
> [ ] +1 - I am in favor of this release, and can help
> [ ] +0 - I am in favor of this release, but cannot help
> [ ] -0 - I am not in favor of this release
> [ ] -1 - I am against this proposal (must include a reason)
>
---------------------------------------------------------------------------
>
> Here's my +1.
>
> Craig
>
>
> ---------------------------------------------------------------------
> 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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Support for Date datatypes!!!
Posted by Paul Speed <ps...@progeeks.com>.
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 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 to actually do about it, hmmm.
>
> Kudos to Jon for taking the time to propose something, in any case...
>
> Joe
>
> At 5:23 PM -0400 6/30/03, Ted Husted wrote:
> >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 believe the consensus has been that the ActionForm should
> >represent Strings as they are entered into the HTML form. Once the
> >Strings pass validation, then data conversion should occur as the
> >data moves toward the business and system tiers.
> >
> >I would agree that the ActionForm oversimplifies the problem. There
> >is definitely a need for a object that incorporates many more
> >attributes into a single configuration, target datatype being one of
> >these. But, IMHO, offering up a patch for just the Date datatype
> >would be a step in the wrong direction.
> >
> >We've come to say that the ActionForm is the missing buffer for the
> >HTML controls. I would suggest that we should take that to heart and
> >make it an actual buffer object for data-entry controls. We've
> >already started to add a second layer of description to the
> >ActionForm in the guise of the Validator forms. We've also started
> >to define the ActionForm itself in XML under the auspice of
> >DynaValidatorForm. Perhaps we should put both of these things
> >together and define a true field and form buffer object that can be
> >define in XML.
> >
> >Aside from target datatype, the Field/Form descriptor could also
> >have places to define the label, displaysize, maxlength, control,
> >readonly, disabled, tabindex, required, validator, default, alt,
> >altKey, style, styleClass, styleId, title, titleKey, and Java on*
> >events.
> >
> >We already enter all of these things into the application someplace,
> >and it would be helpful if they could all be gathered together where
> >they could be reused.
> >
> >The object would be an excellent place to put more advanced data
> >conversion routines, such as those required for dates. It could also
> >be used by other applications and frameworks outside of Struts.
>
> --
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "If nature worked that way, the universe would crash all the time."
> --Jaron Lanier
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Support for Date datatypes!!!
Posted by Ted Husted <hu...@apache.org>.
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 in Action <http://husted.com/struts/book.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Support for Date datatypes!!!
Posted by Joe Germuska <Jo...@Germuska.com>.
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 to actually do about it, hmmm.
Kudos to Jon for taking the time to propose something, in any case...
Joe
At 5:23 PM -0400 6/30/03, Ted Husted wrote:
>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 believe the consensus has been that the ActionForm should
>represent Strings as they are entered into the HTML form. Once the
>Strings pass validation, then data conversion should occur as the
>data moves toward the business and system tiers.
>
>I would agree that the ActionForm oversimplifies the problem. There
>is definitely a need for a object that incorporates many more
>attributes into a single configuration, target datatype being one of
>these. But, IMHO, offering up a patch for just the Date datatype
>would be a step in the wrong direction.
>
>We've come to say that the ActionForm is the missing buffer for the
>HTML controls. I would suggest that we should take that to heart and
>make it an actual buffer object for data-entry controls. We've
>already started to add a second layer of description to the
>ActionForm in the guise of the Validator forms. We've also started
>to define the ActionForm itself in XML under the auspice of
>DynaValidatorForm. Perhaps we should put both of these things
>together and define a true field and form buffer object that can be
>define in XML.
>
>Aside from target datatype, the Field/Form descriptor could also
>have places to define the label, displaysize, maxlength, control,
>readonly, disabled, tabindex, required, validator, default, alt,
>altKey, style, styleClass, styleId, title, titleKey, and Java on*
>events.
>
>We already enter all of these things into the application someplace,
>and it would be helpful if they could all be gathered together where
>they could be reused.
>
>The object would be an excellent place to put more advanced data
>conversion routines, such as those required for dates. It could also
>be used by other applications and frameworks outside of Struts.
--
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time."
--Jaron Lanier
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Support for Date datatypes!!!
Posted by David Graham <gr...@yahoo.com>.
> 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 specific elements outside
> of the space they come from. I do like the idea of
> combining the validation definition with target
> datatype/conversion mechanism to simplify the work of
> defining a UI field. Perhaps the Struts schema could
> wrap (and expand upon) the elements in the validation
> dtd allowing for a single point of entry for field
> definitions?
Once you combine struts-config.xml with validation.xml you lose the
ability to leverage commons-validator's ability to parse validation.xml
and configure itself. Struts would have to setup commons-validator itself
which isn't rocket science but it's probably not trivial either.
David
>
> --- Ted Husted <hu...@apache.org> wrote:
> > 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 believe the consensus has been that the ActionForm
> > should represent
> > Strings as they are entered into the HTML form. Once
> > the Strings pass
> > validation, then data conversion should occur as the
> > data moves toward
> > the business and system tiers.
> >
> > I would agree that the ActionForm oversimplifies the
> > problem. There is
> > definitely a need for a object that incorporates
> > many more attributes
> > into a single configuration, target datatype being
> > one of these. But,
> > IMHO, offering up a patch for just the Date datatype
> > would be a step in
> > the wrong direction.
> >
> > We've come to say that the ActionForm is the missing
> > buffer for the HTML
> > controls. I would suggest that we should take that
> > to heart and make it
> > an actual buffer object for data-entry controls.
> > We've already started
> > to add a second layer of description to the
> > ActionForm in the guise of
> > the Validator forms. We've also started to define
> > the ActionForm itself
> > in XML under the auspice of DynaValidatorForm.
> > Perhaps we should put
> > both of these things together and define a true
> > field and form buffer
> > object that can be define in XML.
> >
> > Aside from target datatype, the Field/Form
> > descriptor could also have
> > places to define the label, displaysize, maxlength,
> > control, readonly,
> > disabled, tabindex, required, validator, default,
> > alt, altKey, style,
> > styleClass, styleId, title, titleKey, and Java on*
> > events.
> >
> > We already enter all of these things into the
> > application someplace, and
> > it would be helpful if they could all be gathered
> > together where they
> > could be reused.
> >
> > The object would be an excellent place to put more
> > advanced data
> > conversion routines, such as those required for
> > dates. It could also be
> > used by other applications and frameworks outside of
> > Struts.
> >
> > -Ted.
> >
> > Jon Wilmoth wrote:
> > > 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 than
> > > rendering the date as a String. I investigated
> > > performing the conversion in ConvertUtils for
> > both,
> > > but without overloading the Converter.convert
> > > interface to accept a map of conversion parameters
> > > made available to the registered Converter
> > > implementations this is not possible. Further
> > more,
> > > the BeanUtils.populate method signature would also
> > > need to change to accomodate a collection of
> > property
> > > specific conversion parameter name/value pairs to
> > use
> > > this new convert method. Thus what's outlined
> > below
> > > involves changes in the Struts code base only!
> > >
> > > String --> Date
> > > 1) Add "dateformat" attribute to all html input
> > tags.
> > > This would specify the java.text.SimpleDateFormat
> > > pattern of the string being submitted. Tag would
> > > generate hidden field and a
> > PropertyConversionParam
> > > (new class) instance stored under the user's
> > session
> > > with PropertyConversionParam.getKey() used as the
> > > session attribute and the hidden field name. This
> > > would only be performed by the tag if the bean's
> > > property type was a date AND 'dateformat'
> > attribute
> > > was specified.
> > >
> > > Scratchpad of PropertyConversionParam class:
> > >
> > > PropertyConversionParam {
> > >
> > > public static final String KEY_PREFIX =
> > > "conversion-param";
> > > public static final String
> > DATE_CONVERSION_PATTERN =
> > > "dateConversionPattern";
> > >
> > > //simple setter/getter properties
> > > private String beanName;
> > > private String property;
> > > private String paramName;
> > > private String conversionValue;
> > >
> > > //calculated namespace key
> > > private String key = null;
> > >
> > > public String getKey() {
> > > if (key == null) {
> > > key = KEY_PREFIX +
> > > String.valueOf(beanName.hashCode()) +
> > > String.valueOf(property.hashCode()) +
> > > String.valueOf(paramName.hashCode());
> > > }
> > > return key;
> > > }
> > > }
> > >
> > > 2) Modify RequestUtils.populate:
> > > * For each property that has a dateformat value
> > > present remove Session PropertyConversionParam
> > > attribute and do not store name/value pair in map
> > > given to BeanUtils.populate method.
> > > * If there is a null attribute value ignore and
>
=== message truncated ===
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Support for Date datatypes!!!
Posted by Jon Wilmoth <jo...@yahoo.com>.
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 is provided
through the default converters
(org.apache.commons.beanutils.converters.SqlDateConverter,
org.apache.commons.beanutils.converters.SqlTimeConverter,
and
org.apache.commons.beanutils.converters.SqlTimestampConverter)
but they required a fixed input format that may not
work with all application. I welcome a more universal
solution (and have some thoughts for such outlined
below), but I am afraid of getting into a design that
due to it's numerous touch points never gets
implemented. Perhaps I've just listened to one too
many "Agile Methodology" pitches ;)
Due to the fact conversion patterns (date atleast) can
be dynamic (user preference for date formatting,
etc.), I would imagine the taglibs would still have to
have the opportunity to override the static XML
default definition.
I think expanding the Converter interface to accept
"configuration" parameters would allow for a more
robust ConvertUtils. Unfortunately, to get to the
conversion (from Struts), you have to get through the
BeanUtils.populate method and I do not know if it's at
this point this "Field Descriptor" object comes into
play. I do like the relative simplicity of the
current method. Prior to Struts existence (almost
unimaginable!) myself and another developer built a
MVC implementation for webapps that had just such an
object and the ActionForm was merely an container for
related "ActionField"s. This had it's problems as it
oversimplified the relationship between
fields...perhaps a hybrid is instore?
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 specific elements outside
of the space they come from. I do like the idea of
combining the validation definition with target
datatype/conversion mechanism to simplify the work of
defining a UI field. Perhaps the Struts schema could
wrap (and expand upon) the elements in the validation
dtd allowing for a single point of entry for field
definitions?
--- Ted Husted <hu...@apache.org> wrote:
> 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 believe the consensus has been that the ActionForm
> should represent
> Strings as they are entered into the HTML form. Once
> the Strings pass
> validation, then data conversion should occur as the
> data moves toward
> the business and system tiers.
>
> I would agree that the ActionForm oversimplifies the
> problem. There is
> definitely a need for a object that incorporates
> many more attributes
> into a single configuration, target datatype being
> one of these. But,
> IMHO, offering up a patch for just the Date datatype
> would be a step in
> the wrong direction.
>
> We've come to say that the ActionForm is the missing
> buffer for the HTML
> controls. I would suggest that we should take that
> to heart and make it
> an actual buffer object for data-entry controls.
> We've already started
> to add a second layer of description to the
> ActionForm in the guise of
> the Validator forms. We've also started to define
> the ActionForm itself
> in XML under the auspice of DynaValidatorForm.
> Perhaps we should put
> both of these things together and define a true
> field and form buffer
> object that can be define in XML.
>
> Aside from target datatype, the Field/Form
> descriptor could also have
> places to define the label, displaysize, maxlength,
> control, readonly,
> disabled, tabindex, required, validator, default,
> alt, altKey, style,
> styleClass, styleId, title, titleKey, and Java on*
> events.
>
> We already enter all of these things into the
> application someplace, and
> it would be helpful if they could all be gathered
> together where they
> could be reused.
>
> The object would be an excellent place to put more
> advanced data
> conversion routines, such as those required for
> dates. It could also be
> used by other applications and frameworks outside of
> Struts.
>
> -Ted.
>
> Jon Wilmoth wrote:
> > 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 than
> > rendering the date as a String. I investigated
> > performing the conversion in ConvertUtils for
> both,
> > but without overloading the Converter.convert
> > interface to accept a map of conversion parameters
> > made available to the registered Converter
> > implementations this is not possible. Further
> more,
> > the BeanUtils.populate method signature would also
> > need to change to accomodate a collection of
> property
> > specific conversion parameter name/value pairs to
> use
> > this new convert method. Thus what's outlined
> below
> > involves changes in the Struts code base only!
> >
> > String --> Date
> > 1) Add "dateformat" attribute to all html input
> tags.
> > This would specify the java.text.SimpleDateFormat
> > pattern of the string being submitted. Tag would
> > generate hidden field and a
> PropertyConversionParam
> > (new class) instance stored under the user's
> session
> > with PropertyConversionParam.getKey() used as the
> > session attribute and the hidden field name. This
> > would only be performed by the tag if the bean's
> > property type was a date AND 'dateformat'
> attribute
> > was specified.
> >
> > Scratchpad of PropertyConversionParam class:
> >
> > PropertyConversionParam {
> >
> > public static final String KEY_PREFIX =
> > "conversion-param";
> > public static final String
> DATE_CONVERSION_PATTERN =
> > "dateConversionPattern";
> >
> > //simple setter/getter properties
> > private String beanName;
> > private String property;
> > private String paramName;
> > private String conversionValue;
> >
> > //calculated namespace key
> > private String key = null;
> >
> > public String getKey() {
> > if (key == null) {
> > key = KEY_PREFIX +
> > String.valueOf(beanName.hashCode()) +
> > String.valueOf(property.hashCode()) +
> > String.valueOf(paramName.hashCode());
> > }
> > return key;
> > }
> > }
> >
> > 2) Modify RequestUtils.populate:
> > * For each property that has a dateformat value
> > present remove Session PropertyConversionParam
> > attribute and do not store name/value pair in map
> > given to BeanUtils.populate method.
> > * If there is a null attribute value ignore and
> allow
> > existing Converters to attempt conversion.
> >
> > 3) Add new DateUtil class to struts util package
> with
> > methods:
> > - java.util.Date toDate(String pattern, String
> value)
> > - String toString(String pattern, java.util.Date
> > value)
> > Realizing the tidyness of centralizing the
> conversion
> > behaviour, these methods could simply be added to
> the
> > ConvertUtils.
> >
> > 4) Modify RequestProcessor.processPopulate
> > (processPopulateConversions ?):
> > * After call to RequestUtils.populate() remove
> > session attributes that begin with
> > PropertyConversionParam.KEY_PREFIX
> > * For each PropertyConversionParam that has a
> > non-null request parameter conversion value, call
> > BeanUtils.setProperty(Object, String, Object)
> after
> > convert the string date to date a java.util.Date
> using
> > DateUtil.toDate.
> > PropertyConversionParam.getConversionValue() would
> > provide 'pattern' parameter while request would
> > provide the 'value' parameter.
> > * For each string --> date conversion that fails
> add
> > a ActionError instance for the property and follow
> > same redirect logic detailed in processValidate
> method
> > (perhaps a method extract refactoring).
> >
> >
> > Date --> String
> > 1) add "dateformat" attribute to bean:write tag &
> all
> > html input tags
> > 2) modify tag to call DateUtil.toString if bean
> > property is of type Date and "dateformat"
> attribute is
> > not null
> >
> > Please realize this is a first cut and I expect to
> > incorporate loads of feedback prior to submitting
> a
> > patch.
> >
> > --- Joe Germuska <Jo...@Germuska.com> wrote:
> >
> >>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 the converse date --> string for
> >>>rendering FormBean values.
> >>
> >>I think submitting a patch would be the most
> >>effective way to get
> >>this put into plans. But note that the
> >>string-to-object conversion
> >>is generally handled in Commons BeanUtils, not
> >>directly in Struts.
> >>The Struts "problem" to solve is where to specify
> >>the date format
> >>conversion, and unless you want to support only
> one
> >>date format for a
> >>whole application, how to pass date formats along
> to
> >>the form
> >>population process at the right time.
> >>
> >>How do you propose to handle the variety of
> possible
> >>date formats?
> >>Between the fact that that's a mildly complicated
> >>question and the
> >>fact that at least some Struts developers think
> that
> >>you should just
> >>use String types for all text fields in your
> forms,
> >>I suspect that's
> >>why you haven't seen any "official" support.
> >>
> >>But if you submit a patch or at least start a
> >>discussion of the
> >>implementation issues, I'm sure you'll get
> opinions.
> >> There are lots
> >>of those around here ;-)
> >>
> >>Joe
> >>
> >>--
> >>--
> >>Joe Germuska
> >>Joe@Germuska.com
> >>http://blog.germuska.com
> >>"If nature worked that way, the universe would
> crash
> >>all the time."
> >> --Jaron Lanier
> >>
> >>
> >
> >
>
---------------------------------------------------------------------
> >
> >>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:
> struts-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> struts-dev-help@jakarta.apache.org
> >
> >
>
>
> --
> Ted Husted,
> Struts in Action
> <http://husted.com/struts/book.html>
>
>
>
>
---------------------------------------------------------------------
> 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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Support for Date datatypes!!!
Posted by Ted Husted <hu...@apache.org>.
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 believe the consensus has been that the ActionForm should represent
Strings as they are entered into the HTML form. Once the Strings pass
validation, then data conversion should occur as the data moves toward
the business and system tiers.
I would agree that the ActionForm oversimplifies the problem. There is
definitely a need for a object that incorporates many more attributes
into a single configuration, target datatype being one of these. But,
IMHO, offering up a patch for just the Date datatype would be a step in
the wrong direction.
We've come to say that the ActionForm is the missing buffer for the HTML
controls. I would suggest that we should take that to heart and make it
an actual buffer object for data-entry controls. We've already started
to add a second layer of description to the ActionForm in the guise of
the Validator forms. We've also started to define the ActionForm itself
in XML under the auspice of DynaValidatorForm. Perhaps we should put
both of these things together and define a true field and form buffer
object that can be define in XML.
Aside from target datatype, the Field/Form descriptor could also have
places to define the label, displaysize, maxlength, control, readonly,
disabled, tabindex, required, validator, default, alt, altKey, style,
styleClass, styleId, title, titleKey, and Java on* events.
We already enter all of these things into the application someplace, and
it would be helpful if they could all be gathered together where they
could be reused.
The object would be an excellent place to put more advanced data
conversion routines, such as those required for dates. It could also be
used by other applications and frameworks outside of Struts.
-Ted.
Jon Wilmoth wrote:
> 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 than
> rendering the date as a String. I investigated
> performing the conversion in ConvertUtils for both,
> but without overloading the Converter.convert
> interface to accept a map of conversion parameters
> made available to the registered Converter
> implementations this is not possible. Further more,
> the BeanUtils.populate method signature would also
> need to change to accomodate a collection of property
> specific conversion parameter name/value pairs to use
> this new convert method. Thus what's outlined below
> involves changes in the Struts code base only!
>
> String --> Date
> 1) Add "dateformat" attribute to all html input tags.
> This would specify the java.text.SimpleDateFormat
> pattern of the string being submitted. Tag would
> generate hidden field and a PropertyConversionParam
> (new class) instance stored under the user's session
> with PropertyConversionParam.getKey() used as the
> session attribute and the hidden field name. This
> would only be performed by the tag if the bean's
> property type was a date AND 'dateformat' attribute
> was specified.
>
> Scratchpad of PropertyConversionParam class:
>
> PropertyConversionParam {
>
> public static final String KEY_PREFIX =
> "conversion-param";
> public static final String DATE_CONVERSION_PATTERN =
> "dateConversionPattern";
>
> //simple setter/getter properties
> private String beanName;
> private String property;
> private String paramName;
> private String conversionValue;
>
> //calculated namespace key
> private String key = null;
>
> public String getKey() {
> if (key == null) {
> key = KEY_PREFIX +
> String.valueOf(beanName.hashCode()) +
> String.valueOf(property.hashCode()) +
> String.valueOf(paramName.hashCode());
> }
> return key;
> }
> }
>
> 2) Modify RequestUtils.populate:
> * For each property that has a dateformat value
> present remove Session PropertyConversionParam
> attribute and do not store name/value pair in map
> given to BeanUtils.populate method.
> * If there is a null attribute value ignore and allow
> existing Converters to attempt conversion.
>
> 3) Add new DateUtil class to struts util package with
> methods:
> - java.util.Date toDate(String pattern, String value)
> - String toString(String pattern, java.util.Date
> value)
> Realizing the tidyness of centralizing the conversion
> behaviour, these methods could simply be added to the
> ConvertUtils.
>
> 4) Modify RequestProcessor.processPopulate
> (processPopulateConversions ?):
> * After call to RequestUtils.populate() remove
> session attributes that begin with
> PropertyConversionParam.KEY_PREFIX
> * For each PropertyConversionParam that has a
> non-null request parameter conversion value, call
> BeanUtils.setProperty(Object, String, Object) after
> convert the string date to date a java.util.Date using
> DateUtil.toDate.
> PropertyConversionParam.getConversionValue() would
> provide 'pattern' parameter while request would
> provide the 'value' parameter.
> * For each string --> date conversion that fails add
> a ActionError instance for the property and follow
> same redirect logic detailed in processValidate method
> (perhaps a method extract refactoring).
>
>
> Date --> String
> 1) add "dateformat" attribute to bean:write tag & all
> html input tags
> 2) modify tag to call DateUtil.toString if bean
> property is of type Date and "dateformat" attribute is
> not null
>
> Please realize this is a first cut and I expect to
> incorporate loads of feedback prior to submitting a
> patch.
>
> --- Joe Germuska <Jo...@Germuska.com> wrote:
>
>>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 the converse date --> string for
>>>rendering FormBean values.
>>
>>I think submitting a patch would be the most
>>effective way to get
>>this put into plans. But note that the
>>string-to-object conversion
>>is generally handled in Commons BeanUtils, not
>>directly in Struts.
>>The Struts "problem" to solve is where to specify
>>the date format
>>conversion, and unless you want to support only one
>>date format for a
>>whole application, how to pass date formats along to
>>the form
>>population process at the right time.
>>
>>How do you propose to handle the variety of possible
>>date formats?
>>Between the fact that that's a mildly complicated
>>question and the
>>fact that at least some Struts developers think that
>>you should just
>>use String types for all text fields in your forms,
>>I suspect that's
>>why you haven't seen any "official" support.
>>
>>But if you submit a patch or at least start a
>>discussion of the
>>implementation issues, I'm sure you'll get opinions.
>> There are lots
>>of those around here ;-)
>>
>>Joe
>>
>>--
>>--
>>Joe Germuska
>>Joe@Germuska.com
>>http://blog.germuska.com
>>"If nature worked that way, the universe would crash
>>all the time."
>> --Jaron Lanier
>>
>>
>
> ---------------------------------------------------------------------
>
>>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: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
>
--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Support for Date datatypes!!!
Posted by Jon Wilmoth <jo...@yahoo.com>.
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 than
rendering the date as a String. I investigated
performing the conversion in ConvertUtils for both,
but without overloading the Converter.convert
interface to accept a map of conversion parameters
made available to the registered Converter
implementations this is not possible. Further more,
the BeanUtils.populate method signature would also
need to change to accomodate a collection of property
specific conversion parameter name/value pairs to use
this new convert method. Thus what's outlined below
involves changes in the Struts code base only!
String --> Date
1) Add "dateformat" attribute to all html input tags.
This would specify the java.text.SimpleDateFormat
pattern of the string being submitted. Tag would
generate hidden field and a PropertyConversionParam
(new class) instance stored under the user's session
with PropertyConversionParam.getKey() used as the
session attribute and the hidden field name. This
would only be performed by the tag if the bean's
property type was a date AND 'dateformat' attribute
was specified.
Scratchpad of PropertyConversionParam class:
PropertyConversionParam {
public static final String KEY_PREFIX =
"conversion-param";
public static final String DATE_CONVERSION_PATTERN =
"dateConversionPattern";
//simple setter/getter properties
private String beanName;
private String property;
private String paramName;
private String conversionValue;
//calculated namespace key
private String key = null;
public String getKey() {
if (key == null) {
key = KEY_PREFIX +
String.valueOf(beanName.hashCode()) +
String.valueOf(property.hashCode()) +
String.valueOf(paramName.hashCode());
}
return key;
}
}
2) Modify RequestUtils.populate:
* For each property that has a dateformat value
present remove Session PropertyConversionParam
attribute and do not store name/value pair in map
given to BeanUtils.populate method.
* If there is a null attribute value ignore and allow
existing Converters to attempt conversion.
3) Add new DateUtil class to struts util package with
methods:
- java.util.Date toDate(String pattern, String value)
- String toString(String pattern, java.util.Date
value)
Realizing the tidyness of centralizing the conversion
behaviour, these methods could simply be added to the
ConvertUtils.
4) Modify RequestProcessor.processPopulate
(processPopulateConversions ?):
* After call to RequestUtils.populate() remove
session attributes that begin with
PropertyConversionParam.KEY_PREFIX
* For each PropertyConversionParam that has a
non-null request parameter conversion value, call
BeanUtils.setProperty(Object, String, Object) after
convert the string date to date a java.util.Date using
DateUtil.toDate.
PropertyConversionParam.getConversionValue() would
provide 'pattern' parameter while request would
provide the 'value' parameter.
* For each string --> date conversion that fails add
a ActionError instance for the property and follow
same redirect logic detailed in processValidate method
(perhaps a method extract refactoring).
Date --> String
1) add "dateformat" attribute to bean:write tag & all
html input tags
2) modify tag to call DateUtil.toString if bean
property is of type Date and "dateformat" attribute is
not null
Please realize this is a first cut and I expect to
incorporate loads of feedback prior to submitting a
patch.
--- Joe Germuska <Jo...@Germuska.com> wrote:
> 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 the converse date --> string for
> >rendering FormBean values.
>
> I think submitting a patch would be the most
> effective way to get
> this put into plans. But note that the
> string-to-object conversion
> is generally handled in Commons BeanUtils, not
> directly in Struts.
> The Struts "problem" to solve is where to specify
> the date format
> conversion, and unless you want to support only one
> date format for a
> whole application, how to pass date formats along to
> the form
> population process at the right time.
>
> How do you propose to handle the variety of possible
> date formats?
> Between the fact that that's a mildly complicated
> question and the
> fact that at least some Struts developers think that
> you should just
> use String types for all text fields in your forms,
> I suspect that's
> why you haven't seen any "official" support.
>
> But if you submit a patch or at least start a
> discussion of the
> implementation issues, I'm sure you'll get opinions.
> There are lots
> of those around here ;-)
>
> Joe
>
> --
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "If nature worked that way, the universe would crash
> all the time."
> --Jaron Lanier
>
>
---------------------------------------------------------------------
> 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: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: Support for Date datatypes!!!
Posted by Joe Germuska <Jo...@Germuska.com>.
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 the converse date --> string for
>rendering FormBean values.
I think submitting a patch would be the most effective way to get
this put into plans. But note that the string-to-object conversion
is generally handled in Commons BeanUtils, not directly in Struts.
The Struts "problem" to solve is where to specify the date format
conversion, and unless you want to support only one date format for a
whole application, how to pass date formats along to the form
population process at the right time.
How do you propose to handle the variety of possible date formats?
Between the fact that that's a mildly complicated question and the
fact that at least some Struts developers think that you should just
use String types for all text fields in your forms, I suspect that's
why you haven't seen any "official" support.
But if you submit a patch or at least start a discussion of the
implementation issues, I'm sure you'll get opinions. There are lots
of those around here ;-)
Joe
--
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"If nature worked that way, the universe would crash all the time."
--Jaron Lanier
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Support for Date datatypes!!!
Posted by Jon Wilmoth <jo...@yahoo.com>.
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 the converse date --> string for
rendering FormBean values. I searched the archives
and this seems to have come up a number of times over
the last 3 years, and yet there is still no official
support. I've been working around the issue by
creating an intermediary String field and doing my own
data conversion in the form bean, but I think this is
common enough to support inclusion in the framework.
If this is something that would be approved for
inclusion, I'd be more than glad to help submit a patch.
__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org