Well, validate=false is now on my action and in the code is
DynaValidatorForm dynForm = (DynaValidatorForm) form;
ActionErrors dynFormErrors = dynForm.validate(mapping, request);
if (! dynFormErrors.isEmpty()) {
logger.debug(invalid form);
saveErrors(request, errors);
return
Allistair Crossley wrote the following on 9/20/2004 6:12 AM:
DynaValidatorForm dynForm = (DynaValidatorForm) form;
ActionErrors dynFormErrors = dynForm.validate(mapping, request);
I just tested this and it works fine.
--
Rick
-
To
Allistair Crossley wrote the following on 9/17/2004 8:40 AM:
however, because I am forced to use a tile definition or JSP in the
input parameter of the action for when the validation fails, i am unable
to load page attributes for that pid from my backend navigation system
and this is breaking my
Hi All,
I am coming up against a limitation of using DynaActionForm that I wonder if someone
can confirm or deny.
All our Action classes extend a SecuredBaseAction. This SecuredBaseAction does a few
important things per request like making sure the user is validated and also loading
page
Now, my understanding was that DynaActionForm manages to populate a map of
form fields, match them up against validation rules, and if it fails, it
would KEEP the previous request but add errors into it and FORWARD back to
the view, therefore KEEPING all the request attributes. It does not
I would agree with him. I can suggest you the same.
Jitender Kumar C.V.
but that's bad practice. very bad.
-Original Message-
From: Jitender K Chukkavenkata [mailto:[EMAIL PROTECTED]
Sent: 17 September 2004 12:51
To: Struts Users Mailing List
Subject: Re: DynaActionForm and previous request attributes (no answer
found in archives for similar problems)
what I have already described in some detail. the use of base actions is a good
pattern to use as one can group common behaviour into them, such as authentication or
ensuring other properties. in our case we do both, security AND ensuring some session
lists for user (i.e those things that make
how to invalidate the session when user clicks the close(cross) button
which will display at the right side of the browser when we open a
page..
On Fri, 17 Sep 2004 08:01:45 -0400, James Mitchell [EMAIL PROTECTED] wrote:
What is 'bad practice'?
--
James Mitchell
Software Engineer / Open
managing a request attribute in the session by setting it and then making sure we
pop it out at the view is messing and defies the semantic use of the request scope.
that's why it is bad practice.
Don't shoot me if I'm wrong but HTTP is stateless so without any of:
cookie, session, browser
You can put JavaScript on every page that will attempt to send the browser
to a specific url when the browser is closing, but that would be browser
specific and it is VERY likely that your action will never get called for
most users. This is the web, if you want that feature you will need to go
when i submit my form to the action, the action maps my form to a DynaActionForm and
binds the values.
now, along with my form, i actually do submit something called PID (page id) which is
the current page at time of submission. therefore, my dyna form will have the page id
for which i need
not quite .. when i arrive initially at the view governed by somePage.jsp yes, there
are a bunch of request attributes set up. on this page is my form. as a hidden
variable to the form I copy the existing page id because this must be present for our
SecuredBaseAction to know what properties to
13 matches
Mail list logo
