You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Joe Germuska <Jo...@Germuska.com> on 2004/12/03 16:59:19 UTC
ActionForm.validateForm(...) to replace ActionForm.validate(...)
In order to push forward on full deprecation of ActionErrors, I
propose adding the following method to ActionForm:
public ActionMessages validateForm(ActionMapping mapping,
HttpServletRequest request) {
return validate(mapping, request);
}
and then changing one line in the Request Processing chain:
ActionMessages errors = form.validate(mapping, request);
to
ActionMessages errors = form.validateForm(mapping, request);
I'm not sure now why we haven't done this earlier. Someone suggested
it on one of the lists a while ago and it seemed clear once I saw it,
but I haven't had time to do anything about it.
My inclination is to do this only on the 1.3 (HEAD) branch, and to
make the change in RequestProcessor.java even though it is slated for
obsolescence, and then also to make the change in
o.a.s.chain.AbstractValidateActionForm (which actually still uses
ActionErrors, actually.)
If it didn't seem strange that it hasn't been done already, I might
have just gone ahead and done it without raising the question -- so
I'm wondering if I'm missing something?
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionForm.validateForm(...) to replace
ActionForm.validate(...)
Posted by Joe Germuska <Jo...@Germuska.com>.
At 11:59 AM -0800 12/3/04, Martin Cooper wrote:
>We did just get Commons Resources promoted out of the sandbox, and I'm
>hopeful that we'll get that puppy released soon. Finally!
I think I'll go ahead and do it anyway. It will only take a few
minutes, and then it will be done no matter how long it takes to get
the conversion to commons-resources done -- I'm assuming it will be a
someone complex conversion...
Joe
>--
>Martin Cooper
>
>
>On Fri, 3 Dec 2004 11:37:38 -0800 (PST), David Graham
><gr...@yahoo.com> wrote:
>> We didn't do it earlier because we wanted to use commons-resources for
>> message passing. That hasn't happened so we may as well add the
>> validateForm() method and deprecate validate().
>>
>> David
>>
>>
>>
>> --- Joe Germuska <Jo...@Germuska.com> wrote:
>>
>> > In order to push forward on full deprecation of ActionErrors, I
>> > propose adding the following method to ActionForm:
>> >
>> > public ActionMessages validateForm(ActionMapping mapping,
>> >
>>HttpServletRequest request) {
>> >
>> > return validate(mapping, request);
>> >
>> > }
>> >
>> > and then changing one line in the Request Processing chain:
>> >
>> > ActionMessages errors = form.validate(mapping, request);
>> > to
>> > ActionMessages errors = form.validateForm(mapping, request);
>> >
>> > I'm not sure now why we haven't done this earlier. Someone suggested
>> > it on one of the lists a while ago and it seemed clear once I saw it,
>> > but I haven't had time to do anything about it.
>> >
>> > My inclination is to do this only on the 1.3 (HEAD) branch, and to
>> > make the change in RequestProcessor.java even though it is slated for
>> > obsolescence, and then also to make the change in
>> > o.a.s.chain.AbstractValidateActionForm (which actually still uses
>> > ActionErrors, actually.)
>> >
>> > If it didn't seem strange that it hasn't been done already, I might
>> > have just gone ahead and done it without raising the question -- so
>> > I'm wondering if I'm missing something?
>> >
>> > Joe
>> >
>> > --
>> > Joe Germuska
>> > Joe@Germuska.com
>> > http://blog.germuska.com
>> > "Narrow minds are weapons made for mass destruction" -The Ex
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>> >
>>
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionForm.validateForm(...) to replace ActionForm.validate(...)
Posted by Ted Husted <hu...@apache.org>.
Yes, I would like to start by introducing the new interfaces as "experimental" and not start deprecating members until we are sure of the migration path. Later, when the time comes, if there was solid support in the community for removing the legacy classes, then yes, the rest could follow. Though, I suspect that once we get there, we may find that it is just as easy to leave the original members in place, or available through a supplemental "struts-classic" JAR, so that the new can be used alongside the old.
When a project becomes as popular as Struts, keeping all of our friends, silver and gold, is vital to the health of the community. A lot of people (including ourselves) have a lot invested in "Struts Classic", and we want to be sure that there is a clear migration path.
For example, if we ever want to make significant changes to the XML configuration, we could use XSLT to transform an existing configuration into a new format at load-time. Using transformations might be a cool way to switch to Spring under the covers, but still provide support for a IDE-friendly DTDs.
The cool thing about the composable request processor is that the "gear-heads" can edit the Chain to use only the components they need. Chain also eliminates the complexity of "special-case" branching. By giving everyone a "bite at the apple", special cases (like XSLT pre-processing) can be cleanly handled by separate commands.
-Ted.
On Mon, 06 Dec 2004 16:59:44 -0600, Hubert Rabago wrote:
>�On Mon, 6 Dec 2004 07:02:12 -0500, Ted Husted <hu...@apache.org>
>�wrote:
>
>>�I'd suggest that we plan on adding new interfaces in 1.3.x, so
>>�that people (incluiding us) can start migrating to contexts, but
>>�that we hold back on new deprecations until we've had some time
>>�to work with contexts and new signatures. Once we have it sorted
>>�out, and have working examples in the distribution, then we can
>>�start deprecating (what will then be) overlapping signatures.
>>
>>�So, we might start by adding experimental context-based
>>�interfaces and signatures in 1.3, deprecate overlapping
>>�signatures in 1.4, and then start removing obsolete members in
>>�1.5.
>>
>
>�If so, then to further clarify:
>�In 1.3, Actions and ActionForms written for 1.2 would work, and
>�will not even get deprecation warnings at compile time. In 1.4,
>�Actions and ActionForms written for 1.2 would still work, though
>�some methods would be deprecated.
>�In 1.5, Actions and ActionForms written for 1.2 would no longer
>�work.
>
>�Right?
>
>�Hubert
>
>�--------------------------------------------------------------------
>�- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>�additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionForm.validateForm(...) to replace ActionForm.validate(...)
Posted by Hubert Rabago <hr...@gmail.com>.
On Mon, 6 Dec 2004 07:02:12 -0500, Ted Husted <hu...@apache.org> wrote:
>
> I'd suggest that we plan on adding new interfaces in 1.3.x, so that people (incluiding us) can start migrating to contexts, but that we hold back on new deprecations until we've had some time to work with contexts and new signatures. Once we have it sorted out, and have working examples in the distribution, then we can start deprecating (what will then be) overlapping signatures.
>
> So, we might start by adding experimental context-based interfaces and signatures in 1.3, deprecate overlapping signatures in 1.4, and then start removing obsolete members in 1.5.
>
If so, then to further clarify:
In 1.3, Actions and ActionForms written for 1.2 would work, and will
not even get deprecation warnings at compile time.
In 1.4, Actions and ActionForms written for 1.2 would still work,
though some methods would be deprecated.
In 1.5, Actions and ActionForms written for 1.2 would no longer work.
Right?
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionForm.validateForm(...) to replace ActionForm.validate(...)
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
Yes I guess that would be better.
Niall
----- Original Message -----
From: "Eddie Bush" <ea...@swbell.net>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Saturday, December 04, 2004 2:49 AM
Subject: Re: ActionForm.validateForm(...) to replace
ActionForm.validate(...)
> Wouldn't it be kind of us to at least return a boolean indicator of
whether
> there were any validation issues? I suppose we could check the
> ValidationContext once the validateForm method returns, but it does seem a
> nice convenience to return a boolean indicator ...
>
> Eddie
>
> ----- Original Message -----
> From: "Niall Pemberton" <ni...@blueyonder.co.uk>
> To: "Struts Developers List" <de...@struts.apache.org>
> Sent: Friday, December 03, 2004 8:12 PM
> Subject: Re: ActionForm.validateForm(...) to replace
> ActionForm.validate(...)
>
>
> >I wasn't proposing changing the validation model at all - but with the
> > advent of Chain we could deprecate the validate(mapping, request) method
> > in
> > favour of a validate(Context) method in ActionForm. This would provide
> > more
> > flexibility and cause less confusion because the method name has stayed
> > the
> > same. I would also suggest that the new validate method shouldn't return
> > anything, with the ActionForm being responsible for sticking the
messages
> > in
> > the Context. That way if/when thing move to commons resources we won't
> > face
> > the same problem again.
> >
> > Niall
> >
> > ----- Original Message -----
> > From: "Joe Germuska" <Jo...@Germuska.com>
> > To: "Niall Pemberton" <ni...@blueyonder.co.uk>; "Struts
> > Developers
> > List" <de...@struts.apache.org>
> > Sent: Friday, December 03, 2004 9:09 PM
> > Subject: Re: ActionForm.validateForm(...) to replace
> > ActionForm.validate(...)
> >
> >
> >> At 8:41 PM +0000 12/3/04, Niall Pemberton wrote:
> >> >Wouldn't it be better to get rid of this in 1.3 with the move to
Chain?
> >> >Doesn't everything get thrown up in the air and re-defined at that
point
> >> >including Action's being deprecated in favour of objects that just
> > implement
> >> >the Command interface?
> >>
> >> I guess I had figured on 1.3 being more transitional than that. But,
> >> even if one were to use a command instead of an action, we haven't
> >> talked (yet) about changing the validation model.
> >>
> >> I haven't heard anyone propose a major change to the model of "Struts
> >> populates an ActionForm and calls a method on it which tests its
> >> validity and is able to return a bundle of messages explaining
> >> validation errors if there are any." My preference would be to defer
> >> any changes that dramatic until 1.4, although with the chain, it
> >> would be a little easier for people to prototype those kinds in the
> >> sandbox or on SourceForge (or whereever...)
> >>
> >> Perhaps it is worth trying to come up with a more future proof
> >> implementation, though. This isn't a burning issue -- clearly people
> >> are confused about the ActionMessages/ActionErrors situation, but I
> >> think that's "under control." By future-proof, I mean something that
> >> passes in the resources-equivalent of ActionMessages, and possibly
> >> which passes in something like a "ValidationContext" which would
> >> eliminate the explicit dependency on HttpServletRequest.
> >>
> >> Joe
> >>
> >>
> >>
> >> >Niall
> >> >
> >> >----- Original Message -----
> >> >From: "Martin Cooper" <mf...@gmail.com>
> >> >To: "Struts Developers List" <de...@struts.apache.org>
> >> >Sent: Friday, December 03, 2004 7:59 PM
> >> >Subject: Re: ActionForm.validateForm(...) to replace
> >> >ActionForm.validate(...)
> >> >
> >> >
> >> >> We did just get Commons Resources promoted out of the sandbox, and
> >> >> I'm
> >> >> hopeful that we'll get that puppy released soon. Finally!
> >> >>
> >> >> --
> >> >> Martin Cooper
> >> >>
> >> >>
> >> >> On Fri, 3 Dec 2004 11:37:38 -0800 (PST), David Graham
> >> >> <gr...@yahoo.com> wrote:
> >> >> > We didn't do it earlier because we wanted to use
commons-resources
> > for
> >> >> > message passing. That hasn't happened so we may as well add the
> >> >> > validateForm() method and deprecate validate().
> >> >> >
> >> >> > David
> >> >> >
> >> >> >
> >> >> >
> >> >> > --- Joe Germuska <Jo...@Germuska.com> wrote:
> >> >> >
> >> >> > > In order to push forward on full deprecation of ActionErrors, I
> >> >> > > propose adding the following method to ActionForm:
> >> >> > >
> >> >> > > public ActionMessages validateForm(ActionMapping mapping,
> >> >> > >
> >> >> HttpServletRequest
> >> >request) {
> >> >> > >
> >> >> > > return validate(mapping, request);
> >> >> > >
> >> >> > > }
> >> >> > >
> >> >> > > and then changing one line in the Request Processing chain:
> >> >> > >
> >> >> > > ActionMessages errors = form.validate(mapping,
request);
> >> >> > > to
> >> >> > > ActionMessages errors = form.validateForm(mapping,
> > request);
> >> >> > >
> >> >> > > I'm not sure now why we haven't done this earlier. Someone
> > suggested
> >> >> > > it on one of the lists a while ago and it seemed clear once I
saw
> > it,
> >> >> > > but I haven't had time to do anything about it.
> >> >> > >
> >> >> > > My inclination is to do this only on the 1.3 (HEAD) branch, and
> >> >> to
> >> >> > > make the change in RequestProcessor.java even though it is
slated
> > for
> >> >> > > obsolescence, and then also to make the change in
> >> >> > > o.a.s.chain.AbstractValidateActionForm (which actually still
uses
> >> >> > > ActionErrors, actually.)
> >> >> > >
> >> >> > > If it didn't seem strange that it hasn't been done already, I
> > might
> >> >> > > have just gone ahead and done it without raising the
question --
> > so
> >> >> > > I'm wondering if I'm missing something?
> >> >> > >
> >> >> > > Joe
> >> >> > >
> >> >> > > --
> >> >> > > Joe Germuska
> >> >> > > Joe@Germuska.com
> >> >> > > http://blog.germuska.com
> >> >> > > "Narrow minds are weapons made for mass destruction" -The Ex
> >> >> > >
> >> >> >
> >> ---------------------------------------------------------------------
> >> >> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> > > For additional commands, e-mail: dev-help@struts.apache.org
> >> > > > >
> >> >> > >
> >> >> >
> >> >> >
> >> >> > __________________________________________________
> >> >> > Do You Yahoo!?
> >> >> > Tired of spam? Yahoo! Mail has the best spam protection around
> >> >> > http://mail.yahoo.com
> >> >> >
> >> >> >
> >> >> >
> >> >>
> > > ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> > For additional commands, e-mail: dev-help@struts.apache.org
> >> >> >
> >> >> >
> >> >>
> >>
> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >> For additional commands, e-mail: dev-help@struts.apache.org
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> >---------------------------------------------------------------------
> >> >To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> >For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >> --
> >> Joe Germuska
> >> Joe@Germuska.com
> >> http://blog.germuska.com
> >> "Narrow minds are weapons made for mass destruction" -The Ex
> >>
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
>
>
> ---
> avast! Antivirus: Outbound message clean.
> Virus Database (VPS): 0449-1, 12/02/2004
> Tested on: 12/3/2004 8:49:54 PM
> avast! - copyright (c) 2000-2004 ALWIL Software.
> http://www.avast.com
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionForm.validateForm(...) to replace ActionForm.validate(...)
Posted by Eddie Bush <ea...@swbell.net>.
Wouldn't it be kind of us to at least return a boolean indicator of whether
there were any validation issues? I suppose we could check the
ValidationContext once the validateForm method returns, but it does seem a
nice convenience to return a boolean indicator ...
Eddie
----- Original Message -----
From: "Niall Pemberton" <ni...@blueyonder.co.uk>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Friday, December 03, 2004 8:12 PM
Subject: Re: ActionForm.validateForm(...) to replace
ActionForm.validate(...)
>I wasn't proposing changing the validation model at all - but with the
> advent of Chain we could deprecate the validate(mapping, request) method
> in
> favour of a validate(Context) method in ActionForm. This would provide
> more
> flexibility and cause less confusion because the method name has stayed
> the
> same. I would also suggest that the new validate method shouldn't return
> anything, with the ActionForm being responsible for sticking the messages
> in
> the Context. That way if/when thing move to commons resources we won't
> face
> the same problem again.
>
> Niall
>
> ----- Original Message -----
> From: "Joe Germuska" <Jo...@Germuska.com>
> To: "Niall Pemberton" <ni...@blueyonder.co.uk>; "Struts
> Developers
> List" <de...@struts.apache.org>
> Sent: Friday, December 03, 2004 9:09 PM
> Subject: Re: ActionForm.validateForm(...) to replace
> ActionForm.validate(...)
>
>
>> At 8:41 PM +0000 12/3/04, Niall Pemberton wrote:
>> >Wouldn't it be better to get rid of this in 1.3 with the move to Chain?
>> >Doesn't everything get thrown up in the air and re-defined at that point
>> >including Action's being deprecated in favour of objects that just
> implement
>> >the Command interface?
>>
>> I guess I had figured on 1.3 being more transitional than that. But,
>> even if one were to use a command instead of an action, we haven't
>> talked (yet) about changing the validation model.
>>
>> I haven't heard anyone propose a major change to the model of "Struts
>> populates an ActionForm and calls a method on it which tests its
>> validity and is able to return a bundle of messages explaining
>> validation errors if there are any." My preference would be to defer
>> any changes that dramatic until 1.4, although with the chain, it
>> would be a little easier for people to prototype those kinds in the
>> sandbox or on SourceForge (or whereever...)
>>
>> Perhaps it is worth trying to come up with a more future proof
>> implementation, though. This isn't a burning issue -- clearly people
>> are confused about the ActionMessages/ActionErrors situation, but I
>> think that's "under control." By future-proof, I mean something that
>> passes in the resources-equivalent of ActionMessages, and possibly
>> which passes in something like a "ValidationContext" which would
>> eliminate the explicit dependency on HttpServletRequest.
>>
>> Joe
>>
>>
>>
>> >Niall
>> >
>> >----- Original Message -----
>> >From: "Martin Cooper" <mf...@gmail.com>
>> >To: "Struts Developers List" <de...@struts.apache.org>
>> >Sent: Friday, December 03, 2004 7:59 PM
>> >Subject: Re: ActionForm.validateForm(...) to replace
>> >ActionForm.validate(...)
>> >
>> >
>> >> We did just get Commons Resources promoted out of the sandbox, and
>> >> I'm
>> >> hopeful that we'll get that puppy released soon. Finally!
>> >>
>> >> --
>> >> Martin Cooper
>> >>
>> >>
>> >> On Fri, 3 Dec 2004 11:37:38 -0800 (PST), David Graham
>> >> <gr...@yahoo.com> wrote:
>> >> > We didn't do it earlier because we wanted to use commons-resources
> for
>> >> > message passing. That hasn't happened so we may as well add the
>> >> > validateForm() method and deprecate validate().
>> >> >
>> >> > David
>> >> >
>> >> >
>> >> >
>> >> > --- Joe Germuska <Jo...@Germuska.com> wrote:
>> >> >
>> >> > > In order to push forward on full deprecation of ActionErrors, I
>> >> > > propose adding the following method to ActionForm:
>> >> > >
>> >> > > public ActionMessages validateForm(ActionMapping mapping,
>> >> > >
>> >> HttpServletRequest
>> >request) {
>> >> > >
>> >> > > return validate(mapping, request);
>> >> > >
>> >> > > }
>> >> > >
>> >> > > and then changing one line in the Request Processing chain:
>> >> > >
>> >> > > ActionMessages errors = form.validate(mapping, request);
>> >> > > to
>> >> > > ActionMessages errors = form.validateForm(mapping,
> request);
>> >> > >
>> >> > > I'm not sure now why we haven't done this earlier. Someone
> suggested
>> >> > > it on one of the lists a while ago and it seemed clear once I saw
> it,
>> >> > > but I haven't had time to do anything about it.
>> >> > >
>> >> > > My inclination is to do this only on the 1.3 (HEAD) branch, and
>> >> to
>> >> > > make the change in RequestProcessor.java even though it is slated
> for
>> >> > > obsolescence, and then also to make the change in
>> >> > > o.a.s.chain.AbstractValidateActionForm (which actually still uses
>> >> > > ActionErrors, actually.)
>> >> > >
>> >> > > If it didn't seem strange that it hasn't been done already, I
> might
>> >> > > have just gone ahead and done it without raising the question --
> so
>> >> > > I'm wondering if I'm missing something?
>> >> > >
>> >> > > Joe
>> >> > >
>> >> > > --
>> >> > > Joe Germuska
>> >> > > Joe@Germuska.com
>> >> > > http://blog.germuska.com
>> >> > > "Narrow minds are weapons made for mass destruction" -The Ex
>> >> > >
>> >> >
>> ---------------------------------------------------------------------
>> >> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> > > For additional commands, e-mail: dev-help@struts.apache.org
>> > > > >
>> >> > >
>> >> >
>> >> >
>> >> > __________________________________________________
>> >> > Do You Yahoo!?
>> >> > Tired of spam? Yahoo! Mail has the best spam protection around
>> >> > http://mail.yahoo.com
>> >> >
>> >> >
>> >> >
>> >>
> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> > For additional commands, e-mail: dev-help@struts.apache.org
>> >> >
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >> For additional commands, e-mail: dev-help@struts.apache.org
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> >---------------------------------------------------------------------
>> >To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> >For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>> --
>> Joe Germuska
>> Joe@Germuska.com
>> http://blog.germuska.com
>> "Narrow minds are weapons made for mass destruction" -The Ex
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0449-1, 12/02/2004
Tested on: 12/3/2004 8:49:54 PM
avast! - copyright (c) 2000-2004 ALWIL Software.
http://www.avast.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionForm.validateForm(...) to replace
ActionForm.validate(...)
Posted by Joe Germuska <Jo...@Germuska.com>.
At 2:12 AM +0000 12/4/04, Niall Pemberton wrote:
>I wasn't proposing changing the validation model at all - but with the
>advent of Chain we could deprecate the validate(mapping, request) method in
>favour of a validate(Context) method in ActionForm. This would provide more
>flexibility and cause less confusion because the method name has stayed the
>same. I would also suggest that the new validate method shouldn't return
>anything, with the ActionForm being responsible for sticking the messages in
>the Context. That way if/when thing move to commons resources we won't face
>the same problem again.
This is probably better. I agree with you and Eddie that we may as
well return boolean as a courtesy.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionForm.validateForm(...) to replace ActionForm.validate(...)
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
I wasn't proposing changing the validation model at all - but with the
advent of Chain we could deprecate the validate(mapping, request) method in
favour of a validate(Context) method in ActionForm. This would provide more
flexibility and cause less confusion because the method name has stayed the
same. I would also suggest that the new validate method shouldn't return
anything, with the ActionForm being responsible for sticking the messages in
the Context. That way if/when thing move to commons resources we won't face
the same problem again.
Niall
----- Original Message -----
From: "Joe Germuska" <Jo...@Germuska.com>
To: "Niall Pemberton" <ni...@blueyonder.co.uk>; "Struts Developers
List" <de...@struts.apache.org>
Sent: Friday, December 03, 2004 9:09 PM
Subject: Re: ActionForm.validateForm(...) to replace
ActionForm.validate(...)
> At 8:41 PM +0000 12/3/04, Niall Pemberton wrote:
> >Wouldn't it be better to get rid of this in 1.3 with the move to Chain?
> >Doesn't everything get thrown up in the air and re-defined at that point
> >including Action's being deprecated in favour of objects that just
implement
> >the Command interface?
>
> I guess I had figured on 1.3 being more transitional than that. But,
> even if one were to use a command instead of an action, we haven't
> talked (yet) about changing the validation model.
>
> I haven't heard anyone propose a major change to the model of "Struts
> populates an ActionForm and calls a method on it which tests its
> validity and is able to return a bundle of messages explaining
> validation errors if there are any." My preference would be to defer
> any changes that dramatic until 1.4, although with the chain, it
> would be a little easier for people to prototype those kinds in the
> sandbox or on SourceForge (or whereever...)
>
> Perhaps it is worth trying to come up with a more future proof
> implementation, though. This isn't a burning issue -- clearly people
> are confused about the ActionMessages/ActionErrors situation, but I
> think that's "under control." By future-proof, I mean something that
> passes in the resources-equivalent of ActionMessages, and possibly
> which passes in something like a "ValidationContext" which would
> eliminate the explicit dependency on HttpServletRequest.
>
> Joe
>
>
>
> >Niall
> >
> >----- Original Message -----
> >From: "Martin Cooper" <mf...@gmail.com>
> >To: "Struts Developers List" <de...@struts.apache.org>
> >Sent: Friday, December 03, 2004 7:59 PM
> >Subject: Re: ActionForm.validateForm(...) to replace
> >ActionForm.validate(...)
> >
> >
> >> We did just get Commons Resources promoted out of the sandbox, and I'm
> >> hopeful that we'll get that puppy released soon. Finally!
> >>
> >> --
> >> Martin Cooper
> >>
> >>
> >> On Fri, 3 Dec 2004 11:37:38 -0800 (PST), David Graham
> >> <gr...@yahoo.com> wrote:
> >> > We didn't do it earlier because we wanted to use commons-resources
for
> >> > message passing. That hasn't happened so we may as well add the
> >> > validateForm() method and deprecate validate().
> >> >
> >> > David
> >> >
> >> >
> >> >
> >> > --- Joe Germuska <Jo...@Germuska.com> wrote:
> >> >
> >> > > In order to push forward on full deprecation of ActionErrors, I
> >> > > propose adding the following method to ActionForm:
> >> > >
> >> > > public ActionMessages validateForm(ActionMapping mapping,
> >> > > HttpServletRequest
> >request) {
> >> > >
> >> > > return validate(mapping, request);
> >> > >
> >> > > }
> >> > >
> >> > > and then changing one line in the Request Processing chain:
> >> > >
> >> > > ActionMessages errors = form.validate(mapping, request);
> >> > > to
> >> > > ActionMessages errors = form.validateForm(mapping,
request);
> >> > >
> >> > > I'm not sure now why we haven't done this earlier. Someone
suggested
> >> > > it on one of the lists a while ago and it seemed clear once I saw
it,
> >> > > but I haven't had time to do anything about it.
> >> > >
> >> > > My inclination is to do this only on the 1.3 (HEAD) branch, and to
> >> > > make the change in RequestProcessor.java even though it is slated
for
> >> > > obsolescence, and then also to make the change in
> >> > > o.a.s.chain.AbstractValidateActionForm (which actually still uses
> >> > > ActionErrors, actually.)
> >> > >
> >> > > If it didn't seem strange that it hasn't been done already, I
might
> >> > > have just gone ahead and done it without raising the question --
so
> >> > > I'm wondering if I'm missing something?
> >> > >
> >> > > Joe
> >> > >
> >> > > --
> >> > > Joe Germuska
> >> > > Joe@Germuska.com
> >> > > http://blog.germuska.com
> >> > > "Narrow minds are weapons made for mass destruction" -The Ex
> >> > >
> >> >
> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> > > For additional commands, e-mail: dev-help@struts.apache.org
> > > > >
> >> > >
> >> >
> >> >
> >> > __________________________________________________
> >> > Do You Yahoo!?
> >> > Tired of spam? Yahoo! Mail has the best spam protection around
> >> > http://mail.yahoo.com
> >> >
> >> >
> >> >
> >>
> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> > For additional commands, e-mail: dev-help@struts.apache.org
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >>
> >
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >For additional commands, e-mail: dev-help@struts.apache.org
>
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionForm.validateForm(...) to replace
ActionForm.validate(...)
Posted by Joe Germuska <Jo...@Germuska.com>.
At 8:41 PM +0000 12/3/04, Niall Pemberton wrote:
>Wouldn't it be better to get rid of this in 1.3 with the move to Chain?
>Doesn't everything get thrown up in the air and re-defined at that point
>including Action's being deprecated in favour of objects that just implement
>the Command interface?
I guess I had figured on 1.3 being more transitional than that. But,
even if one were to use a command instead of an action, we haven't
talked (yet) about changing the validation model.
I haven't heard anyone propose a major change to the model of "Struts
populates an ActionForm and calls a method on it which tests its
validity and is able to return a bundle of messages explaining
validation errors if there are any." My preference would be to defer
any changes that dramatic until 1.4, although with the chain, it
would be a little easier for people to prototype those kinds in the
sandbox or on SourceForge (or whereever...)
Perhaps it is worth trying to come up with a more future proof
implementation, though. This isn't a burning issue -- clearly people
are confused about the ActionMessages/ActionErrors situation, but I
think that's "under control." By future-proof, I mean something that
passes in the resources-equivalent of ActionMessages, and possibly
which passes in something like a "ValidationContext" which would
eliminate the explicit dependency on HttpServletRequest.
Joe
>Niall
>
>----- Original Message -----
>From: "Martin Cooper" <mf...@gmail.com>
>To: "Struts Developers List" <de...@struts.apache.org>
>Sent: Friday, December 03, 2004 7:59 PM
>Subject: Re: ActionForm.validateForm(...) to replace
>ActionForm.validate(...)
>
>
>> We did just get Commons Resources promoted out of the sandbox, and I'm
>> hopeful that we'll get that puppy released soon. Finally!
>>
>> --
>> Martin Cooper
>>
>>
>> On Fri, 3 Dec 2004 11:37:38 -0800 (PST), David Graham
>> <gr...@yahoo.com> wrote:
>> > We didn't do it earlier because we wanted to use commons-resources for
>> > message passing. That hasn't happened so we may as well add the
>> > validateForm() method and deprecate validate().
>> >
>> > David
>> >
>> >
>> >
>> > --- Joe Germuska <Jo...@Germuska.com> wrote:
>> >
>> > > In order to push forward on full deprecation of ActionErrors, I
>> > > propose adding the following method to ActionForm:
>> > >
>> > > public ActionMessages validateForm(ActionMapping mapping,
>> > > HttpServletRequest
>request) {
>> > >
>> > > return validate(mapping, request);
>> > >
>> > > }
>> > >
>> > > and then changing one line in the Request Processing chain:
>> > >
>> > > ActionMessages errors = form.validate(mapping, request);
>> > > to
>> > > ActionMessages errors = form.validateForm(mapping, request);
>> > >
>> > > I'm not sure now why we haven't done this earlier. Someone suggested
>> > > it on one of the lists a while ago and it seemed clear once I saw it,
>> > > but I haven't had time to do anything about it.
>> > >
>> > > My inclination is to do this only on the 1.3 (HEAD) branch, and to
>> > > make the change in RequestProcessor.java even though it is slated for
>> > > obsolescence, and then also to make the change in
>> > > o.a.s.chain.AbstractValidateActionForm (which actually still uses
>> > > ActionErrors, actually.)
>> > >
>> > > If it didn't seem strange that it hasn't been done already, I might
>> > > have just gone ahead and done it without raising the question -- so
>> > > I'm wondering if I'm missing something?
>> > >
>> > > Joe
>> > >
>> > > --
>> > > Joe Germuska
>> > > Joe@Germuska.com
>> > > http://blog.germuska.com
>> > > "Narrow minds are weapons made for mass destruction" -The Ex
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> > > For additional commands, e-mail: dev-help@struts.apache.org
> > > >
>> > >
>> >
>> >
>> > __________________________________________________
>> > Do You Yahoo!?
>> > Tired of spam? Yahoo! Mail has the best spam protection around
>> > http://mail.yahoo.com
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> > For additional commands, e-mail: dev-help@struts.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionForm.validateForm(...) to replace ActionForm.validate(...)
Posted by Ted Husted <hu...@apache.org>.
On Fri, 03 Dec 2004 20:41:27 +0000, Niall Pemberton wrote:
> Wouldn't it be better to get rid of this in 1.3 with the move to
> Chain?
Just to clarify my understanding:
* The head is 1.3.x.
* The patch to #32490 would be applied to both head and 1.2.x branch so that we could roll 1.2.7.
The good news is that things like #32490 are unlikely to happen in 1.3.x, since taglibs will be a separate distribution. :)
I'm back now and should be able to update the Roadmap page tommorrow night and will include mention of adding a "validator(ActionContext)" method.
I'd suggest that we plan on adding new interfaces in 1.3.x, so that people (incluiding us) can start migrating to contexts, but that we hold back on new deprecations until we've had some time to work with contexts and new signatures. Once we have it sorted out, and have working examples in the distribution, then we can start deprecating (what will then be) overlapping signatures.
So, we might start by adding experimental context-based interfaces and signatures in 1.3, deprecate overlapping signatures in 1.4, and then start removing obsolete members in 1.5.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionForm.validateForm(...) to replace ActionForm.validate(...)
Posted by Niall Pemberton <ni...@blueyonder.co.uk>.
Wouldn't it be better to get rid of this in 1.3 with the move to Chain?
Doesn't everything get thrown up in the air and re-defined at that point
including Action's being deprecated in favour of objects that just implement
the Command interface?
Niall
----- Original Message -----
From: "Martin Cooper" <mf...@gmail.com>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Friday, December 03, 2004 7:59 PM
Subject: Re: ActionForm.validateForm(...) to replace
ActionForm.validate(...)
> We did just get Commons Resources promoted out of the sandbox, and I'm
> hopeful that we'll get that puppy released soon. Finally!
>
> --
> Martin Cooper
>
>
> On Fri, 3 Dec 2004 11:37:38 -0800 (PST), David Graham
> <gr...@yahoo.com> wrote:
> > We didn't do it earlier because we wanted to use commons-resources for
> > message passing. That hasn't happened so we may as well add the
> > validateForm() method and deprecate validate().
> >
> > David
> >
> >
> >
> > --- Joe Germuska <Jo...@Germuska.com> wrote:
> >
> > > In order to push forward on full deprecation of ActionErrors, I
> > > propose adding the following method to ActionForm:
> > >
> > > public ActionMessages validateForm(ActionMapping mapping,
> > > HttpServletRequest
request) {
> > >
> > > return validate(mapping, request);
> > >
> > > }
> > >
> > > and then changing one line in the Request Processing chain:
> > >
> > > ActionMessages errors = form.validate(mapping, request);
> > > to
> > > ActionMessages errors = form.validateForm(mapping, request);
> > >
> > > I'm not sure now why we haven't done this earlier. Someone suggested
> > > it on one of the lists a while ago and it seemed clear once I saw it,
> > > but I haven't had time to do anything about it.
> > >
> > > My inclination is to do this only on the 1.3 (HEAD) branch, and to
> > > make the change in RequestProcessor.java even though it is slated for
> > > obsolescence, and then also to make the change in
> > > o.a.s.chain.AbstractValidateActionForm (which actually still uses
> > > ActionErrors, actually.)
> > >
> > > If it didn't seem strange that it hasn't been done already, I might
> > > have just gone ahead and done it without raising the question -- so
> > > I'm wondering if I'm missing something?
> > >
> > > Joe
> > >
> > > --
> > > Joe Germuska
> > > Joe@Germuska.com
> > > http://blog.germuska.com
> > > "Narrow minds are weapons made for mass destruction" -The Ex
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > > For additional commands, e-mail: dev-help@struts.apache.org
> > >
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionForm.validateForm(...) to replace ActionForm.validate(...)
Posted by Martin Cooper <mf...@gmail.com>.
We did just get Commons Resources promoted out of the sandbox, and I'm
hopeful that we'll get that puppy released soon. Finally!
--
Martin Cooper
On Fri, 3 Dec 2004 11:37:38 -0800 (PST), David Graham
<gr...@yahoo.com> wrote:
> We didn't do it earlier because we wanted to use commons-resources for
> message passing. That hasn't happened so we may as well add the
> validateForm() method and deprecate validate().
>
> David
>
>
>
> --- Joe Germuska <Jo...@Germuska.com> wrote:
>
> > In order to push forward on full deprecation of ActionErrors, I
> > propose adding the following method to ActionForm:
> >
> > public ActionMessages validateForm(ActionMapping mapping,
> > HttpServletRequest request) {
> >
> > return validate(mapping, request);
> >
> > }
> >
> > and then changing one line in the Request Processing chain:
> >
> > ActionMessages errors = form.validate(mapping, request);
> > to
> > ActionMessages errors = form.validateForm(mapping, request);
> >
> > I'm not sure now why we haven't done this earlier. Someone suggested
> > it on one of the lists a while ago and it seemed clear once I saw it,
> > but I haven't had time to do anything about it.
> >
> > My inclination is to do this only on the 1.3 (HEAD) branch, and to
> > make the change in RequestProcessor.java even though it is slated for
> > obsolescence, and then also to make the change in
> > o.a.s.chain.AbstractValidateActionForm (which actually still uses
> > ActionErrors, actually.)
> >
> > If it didn't seem strange that it hasn't been done already, I might
> > have just gone ahead and done it without raising the question -- so
> > I'm wondering if I'm missing something?
> >
> > Joe
> >
> > --
> > Joe Germuska
> > Joe@Germuska.com
> > http://blog.germuska.com
> > "Narrow minds are weapons made for mass destruction" -The Ex
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: ActionForm.validateForm(...) to replace ActionForm.validate(...)
Posted by David Graham <gr...@yahoo.com>.
We didn't do it earlier because we wanted to use commons-resources for
message passing. That hasn't happened so we may as well add the
validateForm() method and deprecate validate().
David
--- Joe Germuska <Jo...@Germuska.com> wrote:
> In order to push forward on full deprecation of ActionErrors, I
> propose adding the following method to ActionForm:
>
> public ActionMessages validateForm(ActionMapping mapping,
> HttpServletRequest request) {
>
> return validate(mapping, request);
>
> }
>
> and then changing one line in the Request Processing chain:
>
> ActionMessages errors = form.validate(mapping, request);
> to
> ActionMessages errors = form.validateForm(mapping, request);
>
> I'm not sure now why we haven't done this earlier. Someone suggested
> it on one of the lists a while ago and it seemed clear once I saw it,
> but I haven't had time to do anything about it.
>
> My inclination is to do this only on the 1.3 (HEAD) branch, and to
> make the change in RequestProcessor.java even though it is slated for
> obsolescence, and then also to make the change in
> o.a.s.chain.AbstractValidateActionForm (which actually still uses
> ActionErrors, actually.)
>
> If it didn't seem strange that it hasn't been done already, I might
> have just gone ahead and done it without raising the question -- so
> I'm wondering if I'm missing something?
>
> Joe
>
> --
> Joe Germuska
> Joe@Germuska.com
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction" -The Ex
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org