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
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
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:
with their own
ActionMapper any time they choose. They could, for example, change ! to be /
so that it looks more like a path. We wouldn't want to bleed our the !
pattern to other parts of the application.
On 8/2/06, Patrick Lightbody
[EMAIL PROTECTED] wrote
under [s2] Validation:
One thing I'd
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* being
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
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
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
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
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
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
especially
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 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
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
available,
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
-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,
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 per
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
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 wildcard
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 would you handle
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
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
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 dev@struts.apache.org
Sent: Thursday, 3 August, 2006 11:45:45 PM
Subject: Re: [s2] Validation
Ted Husted wrote:
On 8/3/06
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 aliases
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
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, but
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,
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
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.
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.
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
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
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.
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
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
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 clean
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
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
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
38 matches
Mail list logo
