Tamas Szabo on 22/01/06 07:30, wrote:
There is a legitimate case: when an form can be cancelled, you do
want to skip client-side and server-side validation. That's just
fine because in these case you do want to call the cancelled()
method from DispatchAction, dump out any state you collected,
All of this just adds *ONE MORE REASON* to my list of *NEVER EVER* use
validate=true. I always call validation manually from my Action class
and the sooner people get into a habit of this the way better off they
will be. If you validate or call the form's validate method manually
from your
I'm not sure this solves the problem Rick... partially it does...
As Paul pointed out, the cancel function itself is a legitimate case.
In that situation, you wouldn't want the form to be populated (you
wouldn't care if it was or wasn't I suppose, but ideally why bother
doing the extra work?)
If everyone used dispatch-type Actions, I would disagree because then it
would just be a matter of providing a cancel() method and making sure
that got called. But, since not everyone does (including me whenever I
can avoid it), that's not the end of the story.
Interestingly, the doc for the
Interestingly, the doc for the cancel tag *does* say that validate()
won't be called and that the Action will be called normally. I never
noticed this before. So, at least no one can claim this behavior isn't
documented :)
Yes, but if you don't want to use the cancel tag you probably
If everyone used dispatch-type Actions, I would disagree because then it
would just be a matter
of providing a cancel() method and making sure that got called.
There's actually a funny bug here. cancel() method ALWAYS gets called in a
dispatch action BUT
it's default behavior is to return
Cancelable Actions (independently on the Action type: normal Actions,
DispatchActions) could
even implement a Cancelable interface with a cancel method.
Tamas, good one. I thought of this too but never mentioned it because
implementing interfaces
doesn't seem too cool/accepted in the Struts
On 1/21/06, Paul Benedict [EMAIL PROTECTED] wrote:
Try it yourself!! Just add ?org.apache.struts.taglib.html.CANCEL=true to
any GET URL and your
execute() method will magically be called as if you didn't have any
validation added to your code.
Calling ActionForm.validate() explicitly from
Thanks Craig, that was exactly the right solution. I'm using Tomcat
5.5.12 and adding the dispather elements to the shale filter-mapping did
the trick perfectly.
Thanks again,
Rich
Craig McClanahan wrote:
On 1/21/06, Richard Wallace [EMAIL PROTECTED] wrote:
Hello again,
I'm running
Paul Benedict wrote:
Cancelable Actions (independently on the Action type: normal Actions,
DispatchActions) could
even implement a Cancelable interface with a cancel method.
Tamas, good one. I thought of this too but never mentioned it because
implementing interfaces
doesn't seem too
P.S., Paul, I'd suggest going ahead and opening a ticket for this and
reference this thread... say that a couple of different solutions were
suggested and patches can be easily created once a consensus on the
right answer is reached (I know you said you'd create a patch, and I
would too if
[Moved to a top-level thread, as this doesn't have anything to do with
(either of) the thread(s) it was nested in! :-)]
I think this thread deserves discussion on the dev list, but before I
move it over I thought I'd post a summary to make sure I've captured all
the arguments. I've also
Excellent summary Laurie, thanks! I think you captured all the
pertinent information clearly and concisely. I just suggested to Paul
to open a ticket for this as well, that should probably be mentioned
(with a ticket # if available when you post). Two minor comments below...
Frank
Laurie
...you start a [FRIDAY] thread on comp.jakarta.struts.user.
G.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Not going to rehash the issues including the issues in the new thread
started by Michael and the summary brought up by Laurie in that thread
(and yes Franks this thread is nested, somehow michael's message started
with a new messageId which breaks into a new top level thread for those
clients
OK, transplanted to dev then :)
Frank W. Zammetti wrote:
Excellent summary Laurie, thanks! I think you captured all the
pertinent information clearly and concisely. I just suggested to Paul
to open a ticket for this as well, that should probably be mentioned
(with a ticket # if available
Rick Reumann wrote:
2) Use a DispatchAction. I really don't get why some of you are against
them:) Do you make separate DaoForCreate and DaoForUpdate objects?
My guess is you have one Dao that handles CRUD for a particular type of
concern. To me it's just annoying having separate actions for
(Some of?) the DispactAction variants dispatch to a special method and aren't
subject to the
consequences listed above, but most action implementations don't.
Rick, let me correct something here:
The DispatchAction variants are also subject to the problem with
validate=true WHEN there is no
Laurie, one thing to correct:
Issue: addition of a 'org.apache.struts.action.CANCEL' parameter to any request
will cause
validation to be skipped, but the rest of the request processing / action
invocation cycle to
proceed normally
Should read:
Issue: addition of a
Hello All,
I am trying to pass a string (defined in tiles-defs.xml) to my main
layout, to be used as a key in a tag.
My Setup:
In main-layout.jsp
===
...
div class=crumb
presentation:crumb key=tiles:getAsString name=crumbTitleKey/
link=%=(String)request.getAttribute(page)
Aladin,
You cannot nest JSP tags inside JSP tag attributes. Split them up:
JSP 1.2:
tiles:useAttribute name=crumbTitleKey id=someid /
presentation:crumb key=%=someid% ../
JSP 2.0:
tiles:importAttribute name=crumbTitleKey /
presentation:crumb key=${crumbTitleKey} ../
Paul
Frank W. Zammetti wrote:
You may be 100% right, but it's not especially relevant to this... I'm
sure you wouldn't say the solution is for everyone who is using
automatic validation now to rewrite their apps, are you? :)
No you are right there. I know people like the automatic validation
Rick,
I don't do any business validation with the Validator; I just make sure I get
proper data formats
so that everything is in proper format when going into the service layers. I
want XYZ to be
integers and ABC to be strings.
Paul
__
Do You
Thanks Paul.
Aladin
Paul Benedict wrote:
Aladin,
You cannot nest JSP tags inside JSP tag attributes. Split them up:
JSP 1.2:
tiles:useAttribute name=crumbTitleKey id=someid /
presentation:crumb key=%=someid% ../
JSP 2.0:
tiles:importAttribute name=crumbTitleKey /
presentation:crumb
Paul Benedict wrote:
I don't do any business validation with the Validator; I just make sure I get
proper data formats
so that everything is in proper format when going into the service layers. I
want XYZ to be
integers and ABC to be strings.
Then where is the big 'security' risk? Worst
Rick,
It's a security risk because you're allowing in non-validated data. You could
pass in good data,
bad data, malicious data, etc. You could pass in a string that's a million
characters to your
database, perhaps characters that will appear in SQL, wrong ranges of numbers,
constantly causing
Sending again (it's a work day now in the Middle East).
Thanks - dave
-Original Message-
Hi;
Ok, I use a resource file for all text and then put it in the html page
using c:out, etc. But, what about Hebrew Arabic? They need to be marked
with dir=RTL. I can make the message span
David, I am not sure what the problem is. How is this any different than LTR
text? You could use
c:out escapeXml=false so you don't have to escape anything.
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
Rick Reumann wrote:
The approach isn't invalid as far as basic validation, but for security
I'd say it was not the best way to handle it. Let me ask you and Paul
this... how many times do you see Struts application's built where if
you are Role A you see X Y Z links but if you are Role B you
Ok, I use a resource file for all text and then put it in the
html page using c:out, etc. But, what about Hebrew Arabic?
They need to be marked with dir=RTL. I can make the message
span dir=RTLhi there/span but then I can't escape any
text and have to make sure I have escaped things in
may you would like to take a look at these two:
Yale's CAS : http://www.ja-sig.org/wiki/display/CAS/Home
Acegi : http://acegisecurity.org/
If you're using a real CSS2 browser like Firefox, you can use CSS to enlarge
fonts for the
language you specify:
span[lang='he'] {
font-size: 120%;
}
or maybe something as simple as:
span.rtl {
font-size: 120%;
}
That means you should output span class=rtl.../span
PS: Good idea with the tag
Hi bro, what is your problem?
On 1/23/06, Lixin Chu [EMAIL PROTECTED] wrote:
may you would like to take a look at these two:
Yale's CAS : http://www.ja-sig.org/wiki/display/CAS/Home
Acegi : http://acegisecurity.org/
--
=
The world will be
33 matches
Mail list logo
