Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of flakie@gmail.com designates
 64.233.182.188 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Df+Pvv+/mBetK6vxx8W3uHN/kSgsoAGQmegurUHvdwDUijf6XVr1/rQh7v70h+s8IPfklwjVc1gW2AXbuRr8ddQCrTmVwnOGikEFapUETg8MVjdMxluFo1CuIy7LzbFYWnqNjfz9hanDLjoJoNr2qjaAZWsNKlMqXXYN4fHoRLM=
Message-ID: <adca5f7d0604181123l5da01d4bve710b061356aa8ca@mail.gmail.com>
Date: Tue, 18 Apr 2006 13:23:56 -0500
From: "Eric Rank" <flakie@gmail.com>
To: "Struts Users Mailing List" <user@struts.apache.org>
Subject: Re: How to execute code in an Action when ActionForm validation
 fails?
In-Reply-To: <583d4dff0604181059p551e4f84wdcc3736a11e4aaca@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <adca5f7d0604181039y62805635m29063676f15bdb68@mail.gmail.com>
	 <583d4dff0604181059p551e4f84wdcc3736a11e4aaca@mail.gmail.com>

Thanks Rick,

I agree that the manual validation approach is very good at keeping
related code in one place. This is how I'm currently choosing to solve
this problem.

However, I feel that it's sloppy because it requires additional logic.
I try to avoid using unecessary logic for the sake of keeping code
readable. When I have a bunch of nested logic to sift through, it
doesn't take more than 3 levels before I begin to lose my place in my
own neural memory stack. Suddenly, 'execute' starts doing too much.

In my mind, optionally implementing an interface / method designed to
run when the form validation fails seems very elegant to me. The code
is much more compartmentalized. Only, it doesn't work :-P That said,
what you mention about being careful with the RequestProcessor is
something I agree with.

Thanks for your feedback! I'm curious about this chaining and
interceptor business too. What's it all about?

Eric Rank


On 4/18/06, Rick Reumann <rickcr@gmail.com> wrote:
> On 4/18/06, Eric Rank <flakie@gmail.com> wrote:
>
> > From reading a bit on Rick Reumann's site
> > (http://www.learntechnology.net/validate-manually.do)
> > a simple way to handle this is to call the validate method within the
> > execute method of the Action. There's a bit of logic that has to be
> > processed in order to capture errors, but it works pretty well.
> > However, I personally feel like it could lead to some sloppy "execute"
> > code.
>
> Just curious what you think might be sloppy? One of struts biggest
> weaknesses is in the validation side of things. I just happen to
> prefer a consistent approach that is easy to understand, easy to
> debug, and easy to code - hence I call validation manually from my
> Action and don't ever use validate=3D"true" in my action mapping.
>
> Extending the request processor in my opinion is a bad idea. One of
> the main reasons is it becomes very difficult for someone coming on to
> your project to figure out what is going on, since it's not typical to
> have to mess with that class. Obviously you have a lot of power if you
> want to start messing with that class, but I avoid it.
>
> I haven't been following the latest Struts 1.3 stuff as closely as I'd
> like so maybe someone else has some ideas that could help since I
> think they've introduced more interceptor/chain types of things that
> could aid in what you want. (Then again, I'm still not convinced all
> this injection stuff is all it's cracked up to be. The trend seems to
> be to make things so loosely coupled to the point that it's confusing
> to often figure out 'what is causing' what to occur. It gets annoying
> in my opinion to have to keep searching through different xml files to
> figure out what is going on </rant>).
>
> --
> Rick
> http://www.learntechnology.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org