TED]>
To: dev@struts.apache.org
Sent: Friday, June 15, 2007 1:51:01 PM
Subject: RE: [S2] validation error message params w/ message key?
When the message is evaluated you have an access to the stack, try this:
errorMessage.invalidRange=${getText(fieldName)} must be between ${min} and
${max}, cu
When the message is evaluated you have an access to the stack, try this:
errorMessage.invalidRange=${getText(fieldName)} must be between ${min} and
${max}, current value is ${bar}.
Then have in your resources:
bar=Your display name for field bar
foo=Your display name for field foo
IMHO, Struts
Okay, this doesn't appear to work, unless I'm missing something. I
changed the name a few times and each time it seems as though it is
validating even though I'm not calling the specific action. Here are the
names I've tried:
NewsPersist-newsPersist!save-validation.xml
NewsPersist!save-validat
Haha. Freudian click for sure.
Thanks. I know in WebWork it was the action name and had nothing to do
with the method, so this does make some sense actually, since the action
name is Action!method. Just a something I was pondering Why is the
class name in the file at all? Really it is the
Oops, sorry; meant to not send this.
--- Dave Newton <[EMAIL PROTECTED]> wrote:
> --- Brian Pontarelli <[EMAIL PROTECTED]> wrote:
> > And finally, I have a single validation file
> named:
> >
> > NewsPersist-validation.xml
> >
> > What I figured would work was an XML file named:
> >
> > NewsPe
--- Brian Pontarelli <[EMAIL PROTECTED]> wrote:
> And finally, I have a single validation file named:
>
> NewsPersist-validation.xml
>
> What I figured would work was an XML file named:
>
> NewsPersist-save-validation.xml
>
> This doesn't seem to work however. Any ideas?
Check the archives for
On 8/25/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
I think it's problematic to try to specify things like action methods in the
XML file. Keep in
mind that there's the JSR-303 spec that's getting started up to deal with
validation in a
completely environment-agnostic way. It's not going to
> Ted,
> My opinion on this is that the ! syntax should be
> used strictly as a URL pattern and not anywhere else.
> That means we shouldn't name files like
> foo!bar-validation.xml, but instead figure out
> another way to map it to a context.
>
> Currently, you can name those files
> "foo-bar-val
Agreed.
> On 8/25/06, Patrick Lightbody
> <[EMAIL PROTECTED]> wrote:
> > Make sense?
>
> Yes. Since the validation files are acting like
> code-behinds, being
> able to bind to a code artifact, like the method,
> does make sense to
> me. I can understand why we would also want to bind
> to the
>
On 8/25/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote:
Make sense?
Yes. Since the validation files are acting like code-behinds, being
able to bind to a code artifact, like the method, does make sense to
me. I can understand why we would also want to bind to the
action/context, but *not* bein
Ted,
My opinion on this is that the ! syntax should be used strictly as a URL
pattern and not anywhere else. That means we shouldn't name files like
foo!bar-validation.xml, but instead figure out another way to map it to a
context.
Currently, you can name those files "foo-bar-validation.xml" wh
On 8/2/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote
under [s2] Validation:
One thing I'd add before Jason chimes in is that you can tie validation to the
action name
by naming the file ActionClass-actionName-validation.xml. But you
still also must have
the action class in the filename as we
> OK, I've been lurking on this list for some time, so
> nobody here knows me,
> but I do want to weigh in on this issue on Jason's
> side. I'm relatively new
> to WebWork, using it for a new Web application
> project started in March. I
> was responsible for evaluating the various frameworks
> ava
e Engineer/Architect
Modius, Inc.
> -Original Message-
> From: Jason Carreira [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 04, 2006 6:38 AM
> To: dev@struts.apache.org
> Subject: Re: [s2] Validation
>
> > On 8/3/06, Jason Carreira
> > Ted didn't say depr
> On 8/3/06, Jason Carreira
> Ted didn't say deprecate. Ted said that it didn't
> seem like a best
> practice, in the same way that chaining actions is
> not a best
> practice. Mainly because it goes against the grain of
> the "advanced"
> features like type converters, localization, and
> especia
On 8/3/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
Either way, you're still talking about multiple aliases for one class, which is
what Ted was
saying we should deprecate.
Ted didn't say deprecate. Ted said that it didn't seem like a best
practice, in the same way that chaining actions is n
> I think you missed the main point I was trying to
> make, which is that the concepts of multiple stacks
> is something I avoid entirely. Instead, I believe in
> one stack that is capable of providing different
> behaviors based on conventions.
No, I understood that... I just don't agree.
---
I think you missed the main point I was trying to make, which is that the
concepts of multiple stacks is something I avoid entirely. Instead, I believe
in one stack that is capable of providing different behaviors based on
conventions.
Either way, you're still talking about multiple aliases for one class, which is
what Ted was saying we should deprecate.
For how it's done... Well, I hate the "!" notation... We've had to jump through
a lot of hoops to support it and it still bites us every now and again. Plus,
it's just a sec
OK, I think I see where you are coming from. I guess we are coming across a
difference of opinion, but let me explain how I would do the exact same thing:
- Like you, I would have a single action class that has multiple methods to
invoke (input, save, list, whatever)
- I would not, however, h
> Jason, I have to disagree with you on this. I've
> written a lot of WebWork apps and multiple aliases is
> rarely used (maybe 1-5% of the time for me). Perhaps
> you can give the common examples you come across so
> that we can understand your style better?
>
I think I posted this last week, bu
Jason, I have to disagree with you on this. I've written a lot of WebWork apps
and multiple aliases is rarely used (maybe 1-5% of the time for me). Perhaps
you can give the common examples you come across so that we can understand your
style better?
> > I'm not suggesting that try to make it im
> I'm not suggesting that try to make it impossible to
> use multiple
> alaises. But I am suggesting that the Struts 2 group
> should recognize
> that multiple aliases are not a recommended practice,
> in the same way
> that chaining actions are not a recommended practice.
>
I disagree. Multiple
uot; package.
Agree. :-) And subpackages could be used to group stuff ,say, that one might
not want it to be decorated by sitemesh.
rgds
- Original Message
From: Ian Roughley <[EMAIL PROTECTED]>
To: Struts Developers List
Sent: Thursday, 3 August, 2006 11:45:45 PM
Subject: Re
Ted Husted wrote:
On 8/3/06, Ian Roughley <[EMAIL PROTECTED]> wrote:
This is actually a feature that I like in WW/SAF, granted som times is
makes more sense to use it than others, but that is always going to be a
design decision. Can you further explain why you have come to the
conclusion that
On 8/3/06, Ian Roughley <[EMAIL PROTECTED]> wrote:
This is actually a feature that I like in WW/SAF, granted som times is
makes more sense to use it than others, but that is always going to be a
design decision. Can you further explain why you have come to the
conclusion that they are not good p
> On 8/2/06, Don Brown <[EMAIL PROTECTED]> wrote:
> > Patrick and I talked about doing that, however, we
> came up against several
> > roadblocks:
> >
> > 1. How would you handle nested packages? For
> example: /foo/bar/joe?
>
> Do we need to handle nested packages?
Yes.
>
>
> > 2. How wo
> The modifiers could solve problems 3 and maybe 1
> ("com.acme.{1|slashesToDots}.{2|capitalize}"), and
> perhaps #2 could be solved by
> using the "!" separator instead of the "/" again.
>
> However, the question must be raised whether these
> improvements obscure the
> somewhat advanced wildc
> I would think an ideal application would have the
> following:
>
> - zero configuration (using conventions instead) for
> actions and results
> - overrides possible in struts.xml, including
> wildcards
> - result overrides via annotations if struts.xml is
> too verbose
> - annotations for valida
> Ted,
> Good questions. Related to that - why is it than i18n
> resource bundles are tied to the action class rather
> than the _view_ (the view would tend to make more
> sense, I believe).
In practice I've found it makes more sense to keep them at a higher level... we
keep one resource bundle p
-1 on giving too many options.
The validation framework gives a way to do validations. You can also code your
validations in Java, or build your own hooks into any other validation
framework through interceptors.
Remember, while it seems nice to let people choose from an array of options for
Ted Husted wrote:
On 8/2/06, Don Brown <[EMAIL PROTECTED]> wrote:
Patrick and I talked about doing that, however, we came up against
several
roadblocks:
1. How would you handle nested packages? For example: /foo/bar/joe?
Do we need to handle nested packages?
In webwork I make use of ne
On 8/2/06, Don Brown <[EMAIL PROTECTED]> wrote:
Patrick and I talked about doing that, however, we came up against several
roadblocks:
1. How would you handle nested packages? For example: /foo/bar/joe?
Do we need to handle nested packages?
2. How would you handle action methods?
In
Patrick and I talked about doing that, however, we came up against several
roadblocks:
1. How would you handle nested packages? For example: /foo/bar/joe?
2. How would you handle action methods?
3. The case might not always match
One possible solution would be to introduce "wildcard modifie
On 8/2/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote:
Classes named FooAction map to the action named "foo"
Paths come from sub-packages inside of com.acme.actions. Ex:
com.acme.actions.foo.BarAction -> /foo/bar
If we conform the case, and drop the "Action" suffix, this turns into
a very clea
> > - zero configuration (using conventions instead)
> for actions and results
>
> OK, now define the ideal conventions. :)
Heh - alright. I'll give it a stab. This comes from the conventions I've used
in WebWork for two apps (HostedQA and www.bigbark.net).
- A single package (or set of packag
On 8/2/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote:
- zero configuration (using conventions instead) for actions and results
OK, now define the ideal conventions. :)
-T.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For add
I would think an ideal application would have the following:
- zero configuration (using conventions instead) for actions and results
- overrides possible in struts.xml, including wildcards
- result overrides via annotations if struts.xml is too verbose
- annotations for validations and type conve
On 8/2/06, Ted Husted <[EMAIL PROTECTED]> wrote:
So, for a given Action class, we might have a single XML, along the lines of
Which is to say there might be a
mailreader2/Register/
* Retrieve.java
* Retrieve.xml
with the aforementioned elemens.
-T.
-
On 8/2/06, Patrick Lightbody <[EMAIL PROTECTED]> wrote:
Perhaps the best thing to do to address these little issues is to mock out what
an
ideal webapp would look like using ideal configurations/annotations.
I'm trying to do that now with the MailReader application, but I'm
running into wildca
Ted,
Good questions. Related to that - why is it than i18n resource bundles are tied
to the action class rather than the _view_ (the view would tend to make more
sense, I believe).
This is the kind of stuff we should clean up with Struts 2.
One thing I'd add before Jason chimes in is that you c
Ted, scenario:
You have a wizard form bean. You have 5 stages. Each stage is a different
validation. All use the same action mapping and class. Do you really want to
put all 5 validations in the action mapping? I wouldn't BUT... Why not allow
both ways? Either-or thinking is this file or that f
42 matches
Mail list logo
