I think it is good to tie together the valdation and
conversion of the strings to objects and objects to
properly formatted strings.
I'm curious to know if how you have and/or plan to tie
this in with your beans (ActionForm). Will they just
have setters and getters for strings and you will use
your format class as you need it outside of the beans
or do you have the functionality built into your bean
(custom PropertyDescriptors and/or something like
String getDateAsText(), Date getDateValue()).
David
--- Rey Francois <[EMAIL PROTECTED]> wrote:
> See also the posting I made a few days ago regarding
> validation. I've pasted
> it below.
> The main idea is to use the java.text.Format class
> to do the validation and
> transformation
> between Strings and objects (both ways). The XML
> customization you're
> talking about should achieve
> this double goal: validation and transformation.
>
> François Rey
> Financial WebSuite
> The Capital Markets Company
> http://www.capco.com/
>
> --------------------- begin paste
> ----------------------------------------
>
> In our case, we have chosen to use the
> java.text.Format as a superclass of
> all our validation and formatting classes. I would
> suggest Struts to
> consider this approach. Our decision derives from
> the following
> requirements:
>
> 1 Validation of Strings data according to a
> specified format
> The basic requirement is to validate that a string
> complies to a specified
> format. For example, for a string representing a
> date, the requirement is to
> make sure it is of the form: dd/mm/yyyy.
>
> 2 Parsing Strings to Objects and vice-versa
> Beyond the simple aspect of validating the format of
> an input string, it is
> also often required to transform the validated
> string into a usable form for
> further processing. In Java this means creating an
> object instance from the
> string. With the date example, this could mean
> creating a java.util.Date
> object.
> On the other hand, it is also required to perform
> the reverse operation. In
> the case of an instance of a java.util.Date, it
> should be possible to get a
> string representation of it according to a specified
> format.
>
> 3 String buffer parsing and formatting
> It should be easy to parse only a certain part of a
> larger string when the
> latter contains the formatting of several elements.
> Conversely, it should be
> easy to append the string representation of an
> object to an existing string.
> This can be useful for example in the context of
> marshalling object
> instances into an XML representation.
>
> 4 Independence of the usage context
> The classes involved should be coupled to any
> context of usage. This is to
> allow maximum reuse of the logic in various
> contexts. For example the
> framework should not depend on the HTTP request of
> the Servlet API.
> This should enable the creation of a library of
> formatter that can be used
> in various projects. This library can contain basic
> formatters, but also
> more business oriented ones such as account number
> formatting, etc.
>
> 5 Internationalization
> In some cases it is necessary to have the parsing
> and validation processing
> aware of locale-specific factors. The date example
> is again a very good
> illustration of this requirement, whereby in the
> United States dates are of
> the form mm/dd/yyyy, while in Europe dates are of
> the form dd/mm/yyyy. In
> the context of a graphical user interface, this is
> an important requirement.
>
> The java.text.Format class satisfies all the above
> requirements. It is a
> standard Java object, so using it should be
> consistent with future Java
> developments. Finally, J2SE already proposes some
> formatters for numeric
> values, date, and messages.
>
> In our context, these format classes will be used
> for:
> - HTTP request parameter validation
> - Handling of request and return buffer to and from
> legacy systems
> - Displaying of the data elements in an HTML
> front-end
>
> Eventually, beyond the use of Format classes, we
> intend to create a sort of
> format class instance pool, whereby pre-initialized
> format classes are
> stored for repetitive usage. This avoids the
> creation and initialization of
> an object each time a validation/formatting has to
> be performed. The Struts
> digester would be a great tool for initializing this
> pool.
>
> Comments welcomed!
>
> --------------------------- end paste
> ---------------------------------------
>
> -----Original Message-----
> From: Nick Pellow
> [mailto:[EMAIL PROTECTED]]
> Sent: 28 February 2001 08:07
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Validating bean properties (WAS: Re:
> Stupd question
> aboutStruts and EJB.)
>
>
> Martin,
>
>
> [EMAIL PROTECTED] wrote:
> >
> > Actually, the plan is to build exactly this type
> of validation into Struts
> > 1.1. In particular, I am hoping to incorporate it
> into the automated bean
> > creation tool, one way or another.
>
> Yup, I minutes after my lost post, I received the
> post for Volunteer for
> Validation
> Framework. Wish I had read that first! The
> validation stuff sure could
> be interesting.
>
> > The idea is to define your bean(s) in an XML file,
> and have the tool
> > generate the actual bean code for you. When you
> define a bean, you can
> > specify its type, along with some other validation
> rules (yet to be
> > determined). The tool will create a validate()
> method, and that method
> will
> > populate ActionErrors as appropriate.
>
> > My original thought was to generate code based on
> the validation rules.
> > However, David Winterfeldt has written an
> interesting validator that runs
> > off an XML spec directly. This may be a better
> approach, in that you can
> > modify the rules later without recreating the
> bean, among other things.
>
> I was considering an approach where coders wrote
> validation code in Java
> (we all know java!)
> yet the Struts framework executed it. You would
> extend or implement a
> common java class/interface defining a single
> method,
> public ValidationErrors validate(); say.
> That is then mapped to the form field in an xml file
> somewhere.
>
> Struts, however could ship all the standard
> validations (such as Strings
> to ints)
> together.
>
> It is something I have not given much thought to
> yet, but would be
> interested in
> exploring further.
>
>
> > I'm not sure how this will all fall out in the
> end, but I will be very
> > surprised if Struts 1.1 does not include ways of
> automating the creation
> of
> > form beans, and ways of specifying validation
> rules without writing code.
> > There are several people interested in working on
> each of these topics, so
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
