I agree with Dave as well. I ended up creating one interceptor and one
interface. The interceptor registers a PreResultListener. I then just
check for Action.INPUT in the result code. If input is returned it will
call the prepareInputErrors method if it's available.
So far it works perfectly.
Just read Dave's thought. Much better.
On 11/29/08, Burton Rhodes <[EMAIL PROTECTED]> wrote:
> Just a thought but why don't put a redirect acrtion in your result
> 'input' on your update action. That way if it fails it will run
> prepareEdit.
>
> On 11/29/08, Adam Ruggles <[EMAIL PROTECTED]> wrote
--- On Sat, 11/29/08, Burton Rhodes <[EMAIL PROTECTED]> wrote:
> Just a thought but why don't put a redirect acrtion in your result
> 'input' on your update action. That way if it fails it will run
> prepareEdit.
Under default circumstances you'd lose your error messages.
Dave
Just a thought but why don't put a redirect acrtion in your result
'input' on your update action. That way if it fails it will run
prepareEdit.
On 11/29/08, Adam Ruggles <[EMAIL PROTECTED]> wrote:
>
> I have a problem I'm trying to solve when the validation fails on a crud
> action. This action h
Do you think I would need to check the actionErrors/fieldErrors rather then
just check for the input return value?
newton.dave wrote:
>
> You could just check to see if there are any errors before running the
> prepare logic; this could be done in an interceptor as well
> "prepareWhenErrors" o
You could just check to see if there are any errors before running the prepare
logic; this could be done in an interceptor as well "prepareWhenErrors" or
something.
Dave
--- On Sat, 11/29/08, Adam Ruggles <[EMAIL PROTECTED]> wrote:
> I have a problem I'm trying to solve when the validation
> fa
6 matches
Mail list logo
