I totally agree. Its seems like a one or two man show. If I didnt have
immediate needs and a restriction to jsp because of fear of new things, I
would be playing around with it more. I just dont like apps too heavily
reliant on xml because my collegues and I are having a real hard time with
it. Xml is very picky, and I hate xslt for presenation with very few
exceptions. Their validation is pretty far along, maybe as old as struts.
I read about Enhydra atleast a year or a year and a half ago. Barracuda's
founder is on the Struts list, and I am on the Barracudas list. It doesnt
have as much activity and it seems as though they are still working out some
larger bugs.
----- Original Message -----
From: "David Winterfeldt" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 14, 2001 12:31 AM
Subject: Re: Client/Server Side Validation for Struts 1.1
> I just saw the type conversion thread going on in the
> user list, but I've thought about this for a bit and
> you mentioned possibly modeling or taking code from an
> existing framework.
>
> How closely have you looked at Barracuda Ted? Some of
> what they do is interesting. I think we could make an
> ActionForm derivitive that loosely followed their
> steps in processing an object.
>
> Barracuda
> -------------
> FormMap
> FormElement
> key - the key/property name
> type - the FormType (ie. String, Boolean,
> Integer, etc)
> defaultVal - the default value (ie. the value to
> be used if the key is not present in the form source)
> validator - FormValidators responsible for
> validating this particular element
> allowMultiples - is it possible for this key to
> have multiple values in the form source
>
>
> add these other fields to the field element in the
> valdation.xml
>
> public class BarracudaActionForm extends ActionForm {
> Map formMap = new HashMap();
>
> public Map getFormMap() { return formMap; }
>
> public void setFormMap(Map formMap)
> this.formMap = formMap;
> }
>
> public void reset(ActionMapping mapping,
> HttpServletRequest request) {
> formMap.clear();
> }
>
> }
>
> populate map
>
> perform transformations from map to real objects using
> subclasses of java.text.Format as Rey Francois has
> suggested, if the transformation was successful remove
> the item from the Map. (Struts html tags would need to
> be able to try the Map first and then the actual
> ActionForm property. This could tie in with a dynamic
> ActionForm class)
>
> populate default values
>
> perform other validations
>
> Or we could make a transformation class for the
> general transformation package you suggested and you
> would pass in any two JavaBeans and it could map
> values between the two. Something like this could be
> used from a short cut method in the ActionForm.
>
> public Object getDataBean() {
> // Class name could come from an xml
> transform/mapping file
> Object bean =
> Class.forName(className).newInstance();
> Transformation.transform(this, bean);
> return bean;
> }
>
> It seems from discussions that most people would
> prefer the latter based on current usage on the lists,
> but you wouldn't need two classes with the first
> approach and it is from a working framework. What is
> your opinion?
>
> David
>
>
> --- Ted Husted <[EMAIL PROTECTED]> wrote:
> > I still have the feeling that we lack a decent
> > foundation package to do
> > the grunt work of typecasting and String formatting,
> > so that things like
> > a Validation servlet and something like a
> > <bean:transform
> > picture="##/##/##" > tag could share a common
> > codebase.
> >
> > We might want to start with something like this:
> >
> > <
> >
> http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg01522.html
> > >
> >
> > Perhaps as an extension to java.text.Format, as Rey
> > Francois has been
> > suggesting:
> >
> > <
> >
> http://www.mail-archive.com/struts-user@jakarta.apache.org/msg02711.html
> > >
> >
> > And then look at how we can use this package to
> > extend the Validation
> > servlet and enhance the bean tags.
> >
> > It's a little confusing now, since validations,
> > conversions, and
> > transformations and are closely linked, but appear
> > at different points
> > in the input / store / output continuum. Even so, I
> > think the processes
> > have enough in common to create a cohesive package,
> > even if you would
> > not use every method on any one layer of a MVC
> > application.
> >
> >
> > -- Ted Husted, Husted dot Com, Fairport NY USA.
> > -- Custom Software ~ Technical Services.
> > -- Tel 716 737-3463.
> > -- http://www.husted.com/about/struts/
>
>
> __________________________________________________
> Do You Yahoo!?
> Spot the hottest trends in music, movies, and more.
> http://buzz.yahoo.com/
>
