You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <hu...@apache.org> on 2006/08/02 01:11:24 UTC
[s2] Validation
In Struts 1, we put the validators in a separate file that's tied to
the mappings through the formbean name, or, alternatively, the path.
In Struts 2, we put the validators in a sepaate file that's tied to
the mappings through the classname.
Why is it that we don't make the validators part of the action
mapping, instead of in a separate element?
I wonder if validators should be more like results. (Pre-results, if
you will.) A mapping could have a default validator mapping. If the
mapping is using wildcards, a different validator mapping could be
selected by a wildcard token, or even an interceptor.
I think one reason people find XML configurations hard to use is
because we keep putting tightly-coupled elements in separate files,
instead of saying it all in one place.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: RE: [s2] Validation
Posted by Jason Carreira <fo...@opensymphony.com>.
> 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, then
> setting up the core design practices and training the
> rest of the team.
>
> We have made extensive use of the CRUD Action pattern
> - easily the bulk of
> the code for the app administration and configuration
> components. It made a
> great deal of sense to me and the other developers -
> a common set of data
> with a small number of closely-related operations on
> that data. Pretty much
> the definition of an object. Seemed cleaner than
> extending that same class
> two or three or four times just to override
> execute().
>
> I realize this capability could be dangerous in the
> wrong hands. ;-) Our
> standard is to only use this pattern when all the
> actions use the same
> domain object(s) and back the same basic view. I
> think this still satisfies
> the Single Responsibility Principle, because there is
> little or no risk of
> breaking other app components if you have to update a
> method in this Action
> class. More likely is that a feature change or bug
> fix will impact the
> entire Action anyway.
>
> We have thus far avoided the whole wild-card
> capability completely, both in
> action definitions and in validation. Stars and
> bangs and brackets - oh my!
> Had the feel of getting dangerously clever, at least
> for a newbie group just
> learning its way around the framework. I can't speak
> to which parts of that
> work and really make life easier (yet). Besides, it
> wasn't documented in
> Jason & Patrick's book. :-) (Where, BTW, the CRUD
> action approach is
> described in the chapter 'Best Practices,' so it's
> always been clear where
> they stand on that. Maybe I've been brainwashed...)
>
> We have run into a couple of validation cases where
> an
> ActionClass-Method-validation.xml would get us into a
> bit of trouble, for
> example when calling 'save()' on a new User vs. an
> existing User. In this
> case, we defined two actions ('saveUser' and
> 'saveNewUser') that mapped to
> the same method and used the
> ActionClass-actionName-validation.xml. True, it
> wouldn't have been much harder to define two methods,
> one of which simply
> delegated to the other. Seems like a basic Java vs.
> XML trade-off.
>
> Still, I favor using the action name because the idea
> is that the validation
> framework is externalized. If you have to make code
> changes - new no-op
> methods or even new no-op class extensions - just to
> provide hooks for your
> validation framework, then it really isn't very
> externalized, is it?
> Defining a new action in XML is in many ways the
> equivalent of a code
> change, but as Jason pointed out the action
> represents the logical app
> operation and may include different interceptors and
> other decorations in
> addition to validation. Mapping multiple actions to
> the same method is a
> convenience in the case where new decorations are
> sufficient to handle all
> needed functional changes. The whole point of
> decorations is to change the
> behavior of a class without having to modify the
> class itself, right?
>
> Not sure my opinion is yet worth a full $.02, but
> there it is. :-) BTW,
> thank you all for your hard work. I was REALLY
> impressed that you committed
> to merging Struts and WebWork back together.
> Resolving honest differences of
> opinion and healing schisms is much harder than
> writing code. It is
> appreciated.
>
> Jay
> --------
> Jay H. Hartley, Ph.D.
> Senior Software Engineer/Architect
> Modius, Inc.
>
Thanks for writing up what I was trying to say better than I was ;-)
Jason
p.s. Glad the book helped.
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=78156#78156
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: [s2] Validation
Posted by "Jay H. Hartley" <ma...@jay.hartley.name>.
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, then
setting up the core design practices and training the rest of the team.
We have made extensive use of the CRUD Action pattern - easily the bulk of
the code for the app administration and configuration components. It made a
great deal of sense to me and the other developers - a common set of data
with a small number of closely-related operations on that data. Pretty much
the definition of an object. Seemed cleaner than extending that same class
two or three or four times just to override execute().
I realize this capability could be dangerous in the wrong hands. ;-) Our
standard is to only use this pattern when all the actions use the same
domain object(s) and back the same basic view. I think this still satisfies
the Single Responsibility Principle, because there is little or no risk of
breaking other app components if you have to update a method in this Action
class. More likely is that a feature change or bug fix will impact the
entire Action anyway.
We have thus far avoided the whole wild-card capability completely, both in
action definitions and in validation. Stars and bangs and brackets - oh my!
Had the feel of getting dangerously clever, at least for a newbie group just
learning its way around the framework. I can't speak to which parts of that
work and really make life easier (yet). Besides, it wasn't documented in
Jason & Patrick's book. :-) (Where, BTW, the CRUD action approach is
described in the chapter 'Best Practices,' so it's always been clear where
they stand on that. Maybe I've been brainwashed...)
We have run into a couple of validation cases where an
ActionClass-Method-validation.xml would get us into a bit of trouble, for
example when calling 'save()' on a new User vs. an existing User. In this
case, we defined two actions ('saveUser' and 'saveNewUser') that mapped to
the same method and used the ActionClass-actionName-validation.xml. True, it
wouldn't have been much harder to define two methods, one of which simply
delegated to the other. Seems like a basic Java vs. XML trade-off.
Still, I favor using the action name because the idea is that the validation
framework is externalized. If you have to make code changes - new no-op
methods or even new no-op class extensions - just to provide hooks for your
validation framework, then it really isn't very externalized, is it?
Defining a new action in XML is in many ways the equivalent of a code
change, but as Jason pointed out the action represents the logical app
operation and may include different interceptors and other decorations in
addition to validation. Mapping multiple actions to the same method is a
convenience in the case where new decorations are sufficient to handle all
needed functional changes. The whole point of decorations is to change the
behavior of a class without having to modify the class itself, right?
Not sure my opinion is yet worth a full $.02, but there it is. :-) BTW,
thank you all for your hard work. I was REALLY impressed that you committed
to merging Struts and WebWork back together. Resolving honest differences of
opinion and healing schisms is much harder than writing code. It is
appreciated.
Jay
--------
Jay H. Hartley, Ph.D.
Senior Software Engineer/Architect
Modius, Inc.
> -----Original Message-----
> From: Jason Carreira [mailto:forum-struts-dev@opensymphony.com]
> 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 it goes against the grain of the "advanced"
> > features like type converters, localization, and especially
> > validation.
> >
>
> I think a lot of long-time WebWork users have said in this
> thread that we don't view it as a poor practice... In fact I
> think all of our best practices involved multiple action
> aliases for Action classes. It doesn't go against the grain
> of any of those, you just have to either customize your
> interceptor stack, or make it context aware like Patrick was
> talking about.
>
> > Yes, and that we've already deprecated the bang-syntax. In
> the head,
> > it's only supported when a compatibility switch is turned on, and I
> > expect it would be removed entirely in 2.1.
> >
> > The next question is whether there will be support for the
> > ActionClass-method-validatation idiom. (Is there still support?)
> >
> > * https://issues.apache.org/struts/browse/WW-1018
> >
> > (After commenting here, I began to rethink how strongly we should
> > support multiple aliases.)
> >
>
> You mean support for the "!" in validation file names? I
> agree that can go... As for context-specific validations,
> that needs to stay. It's one of my requirements for the
> framework, and one of the requirements I'm bringing with me
> to JSR-303.
>
> >
> > Me too. I think when we use multiple alaises, using
> > multiple stacks is
> > a sane approach. It dodges using "magic" names to
> > skip validation.
> > Though, it doesn't provide a way to validate a
> > specific method, unless
> > we use Java or the ActionClass-method-validator idiom
> >
>
> It doesn't have to do with the method, though... It has to do
> with the logical function that your endpoint is executing,
> whether it's for a web page or behind a XMLRPC front end,
> etc. I might map 3 different action aliases to an empty
> execute() method just to get different interceptor stacks applied.
>
> > This sort of special-case handling is why I'm leaning
> > toward
> > one-method per Action. All the commands have a full
> > array of extension
> > points, without any smoke or mirrors.
> >
>
> It leads to too many classes in practice, and removes a key
> functionality that WebWork users depend on.
>
> > In the end, the complexity has to live somewhere.
> > With
> > she-bang-magic-methods, it was living in the
> > framework, creating a lot
> > of special-case code, and creating security issues.
> > With
> > multiple-methods, the complexity moves to swapping
> > stacks and maybe
> > doing some validations outside for the framework.
> > With single-method,
> > the complexity moves to creating more classes.
> >
>
> Ok, so it's about managing complexity. The problem with the
> "!" notation was that the complexity was too much and we
> could never find all of the issues with it, so one would crop
> up now and again. With the multiple aliases, the complexity
> (right now) is on the user to manage their configuration, but
> that could be lessened with wildcards and conventions. With
> single method actions, you have to have lots of classes, and
> there's no opportunity for improvement. If you take out the
> "!" notation, you're left with the other 2 options, and users
> can choose whichever they like. Multiple method aliases
> doesn't preclude you from having a one-to-one mapping for
> actions -> action aliases.
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?threadID=39135&mess
> ageID=78102#78102
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Jason Carreira <fo...@opensymphony.com>.
> 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
> validation.
>
I think a lot of long-time WebWork users have said in this thread that we don't view it as a poor practice... In fact I think all of our best practices involved multiple action aliases for Action classes. It doesn't go against the grain of any of those, you just have to either customize your interceptor stack, or make it context aware like Patrick was talking about.
> Yes, and that we've already deprecated the
> bang-syntax. In the head,
> it's only supported when a compatibility switch is
> turned on, and I
> expect it would be removed entirely in 2.1.
>
> The next question is whether there will be support
> for the
> ActionClass-method-validatation idiom. (Is there
> still support?)
>
> * https://issues.apache.org/struts/browse/WW-1018
>
> (After commenting here, I began to rethink how
> strongly we should
> support multiple aliases.)
>
You mean support for the "!" in validation file names? I agree that can go... As for context-specific validations, that needs to stay. It's one of my requirements for the framework, and one of the requirements I'm bringing with me to JSR-303.
>
> Me too. I think when we use multiple alaises, using
> multiple stacks is
> a sane approach. It dodges using "magic" names to
> skip validation.
> Though, it doesn't provide a way to validate a
> specific method, unless
> we use Java or the ActionClass-method-validator idiom
>
It doesn't have to do with the method, though... It has to do with the logical function that your endpoint is executing, whether it's for a web page or behind a XMLRPC front end, etc. I might map 3 different action aliases to an empty execute() method just to get different interceptor stacks applied.
> This sort of special-case handling is why I'm leaning
> toward
> one-method per Action. All the commands have a full
> array of extension
> points, without any smoke or mirrors.
>
It leads to too many classes in practice, and removes a key functionality that WebWork users depend on.
> In the end, the complexity has to live somewhere.
> With
> she-bang-magic-methods, it was living in the
> framework, creating a lot
> of special-case code, and creating security issues.
> With
> multiple-methods, the complexity moves to swapping
> stacks and maybe
> doing some validations outside for the framework.
> With single-method,
> the complexity moves to creating more classes.
>
Ok, so it's about managing complexity. The problem with the "!" notation was that the complexity was too much and we could never find all of the issues with it, so one would crop up now and again. With the multiple aliases, the complexity (right now) is on the user to manage their configuration, but that could be lessened with wildcards and conventions. With single method actions, you have to have lots of classes, and there's no opportunity for improvement. If you take out the "!" notation, you're left with the other 2 options, and users can choose whichever they like. Multiple method aliases doesn't preclude you from having a one-to-one mapping for actions -> action aliases.
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=78102#78102
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Ted Husted <hu...@apache.org>.
On 8/3/06, Jason Carreira <fo...@opensymphony.com> 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 not a best
practice. Mainly because it goes against the grain of the "advanced"
features like type converters, localization, and especially
validation.
>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 security hole,
>plain and simple.
Yes, and that we've already deprecated the bang-syntax. In the head,
it's only supported when a compatibility switch is turned on, and I
expect it would be removed entirely in 2.1.
The next question is whether there will be support for the
ActionClass-method-validatation idiom. (Is there still support?)
* https://issues.apache.org/struts/browse/WW-1018
(After commenting here, I began to rethink how strongly we should
support multiple aliases.)
> I like the idea of wildcards, and I'd like to be able to specify certain wildcard patterns that
>can be used across many paths and specify interceptor stacks to go with them:
>
> /entity/*/list -> listStack
> /entity/*/edit -> editStack
>
> and then
>
> /entity/invoice/list
>
> would match the first wildcard and have the specific listStack applied.
Me too. I think when we use multiple alaises, using multiple stacks is
a sane approach. It dodges using "magic" names to skip validation.
Though, it doesn't provide a way to validate a specific method, unless
we use Java or the ActionClass-method-validator idiom
This sort of special-case handling is why I'm leaning toward
one-method per Action. All the commands have a full array of extension
points, without any smoke or mirrors.
In the end, the complexity has to live somewhere. With
she-bang-magic-methods, it was living in the framework, creating a lot
of special-case code, and creating security issues. With
multiple-methods, the complexity moves to swapping stacks and maybe
doing some validations outside for the framework. With single-method,
the complexity moves to creating more classes.
-Ted
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Jason Carreira <fo...@opensymphony.com>.
> 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.
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=78016#78016
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Patrick Lightbody <fo...@opensymphony.com>.
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.
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=77994#77994
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Jason Carreira <fo...@opensymphony.com>.
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 security hole, plain and simple.
I like the idea of wildcards, and I'd like to be able to specify certain wildcard patterns that can be used across many paths and specify interceptor stacks to go with them:
/entity/*/list -> listStack
/entity/*/edit -> editStack
and then
/entity/invoice/list
would match the first wildcard and have the specific listStack applied.
> 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, have different stacks. In
> fact, I go just the opposite: I try to have one
> global stack for every action. In cases like yours
> where the stack needs to behave differently, I design
> the interceptor to look for an annotation or
> convention, much like today's WorkflowInterceptor and
> ValidationInterceptor do.
> - I would have one action configured (well, actually
> pulled in via convention) and then use foo!bar
> syntax.
>
> What do you think of that?
>
> Of course, my approach won't work with the efforts
> Don and Ted are pushing for: removing foo!bar syntax
> as a recommended option.
>
> Ted, Don: what would you guys do in the scenario
> Jason provided?
>
> I should point out that in my scenario, there is no
> need for any configuration - just some common
> conventions that tend to work very well (for me). I
> wouldn't even be happy doing a wildcard configuration
> for each entity, though I think that would be better
> than Jason's approach (assuming you could define a
> single stack with different behaviors).
>
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=77987#77987
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Patrick Lightbody <fo...@opensymphony.com>.
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, have different stacks. In fact, I go just the opposite: I try to have one global stack for every action. In cases like yours where the stack needs to behave differently, I design the interceptor to look for an annotation or convention, much like today's WorkflowInterceptor and ValidationInterceptor do.
- I would have one action configured (well, actually pulled in via convention) and then use foo!bar syntax.
What do you think of that?
Of course, my approach won't work with the efforts Don and Ted are pushing for: removing foo!bar syntax as a recommended option.
Ted, Don: what would you guys do in the scenario Jason provided?
I should point out that in my scenario, there is no need for any configuration - just some common conventions that tend to work very well (for me). I wouldn't even be happy doing a wildcard configuration for each entity, though I think that would be better than Jason's approach (assuming you could define a single stack with different behaviors).
> > 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 here's the
> Invoice CRUD action definitions:
>
> <!-- Invoice CRUD Actions -->
> <action name="listInvoice"
> e"
> class="com.eplus.app.invoice.action.InvoiceCrudAction"
> method="list">
> <interceptor-ref name="listStack"/>
> sult name="CRUD-list"
> type="freemarker">/template/eplus/metaDataList.ftl</re
> sult>
> </action>
> <action name="editInvoice"
> "
> class="com.eplus.app.invoice.action.InvoiceCrudAction"
> >
> <interceptor-ref name="editStack"/>
> ction>
> <action name="saveInvoice"
> "
> class="com.eplus.app.invoice.action.InvoiceCrudAction"
> method="save">
> <interceptor-ref name="crudStack"/>
> ction>
> <action name="deleteInvoice"
> "
> class="com.eplus.app.invoice.action.InvoiceCrudAction"
> method="delete">
> <interceptor-ref name="crudStack"/>
> >
> </action>
> at for each entity in the system...
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=77972#77972
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Jason Carreira <fo...@opensymphony.com>.
> 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 here's the Invoice CRUD action definitions:
<!-- Invoice CRUD Actions -->
<action name="listInvoice" class="com.eplus.app.invoice.action.InvoiceCrudAction" method="list">
<interceptor-ref name="listStack"/>
<result name="CRUD-list" type="freemarker">/template/eplus/metaDataList.ftl</result>
</action>
<action name="editInvoice" class="com.eplus.app.invoice.action.InvoiceCrudAction">
<interceptor-ref name="editStack"/>
</action>
<action name="saveInvoice" class="com.eplus.app.invoice.action.InvoiceCrudAction" method="save">
<interceptor-ref name="crudStack"/>
</action>
<action name="deleteInvoice" class="com.eplus.app.invoice.action.InvoiceCrudAction" method="delete">
<interceptor-ref name="crudStack"/>
</action>
repeat for each entity in the system...
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=77960#77960
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Patrick Lightbody <fo...@opensymphony.com>.
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 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 is a pattern I recommend
> and it's very useful. CRUD screens in particular
> almost require it, otherwise you get lots of classes
> and deep hierarchies to try to make the classes as
> common as possible, when they could just be the same
> class.
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=77958#77958
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Jason Carreira <fo...@opensymphony.com>.
> 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 is a pattern I recommend and it's very useful. CRUD screens in particular almost require it, otherwise you get lots of classes and deep hierarchies to try to make the classes as common as possible, when they could just be the same class.
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=77952#77952
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by tm jee <tm...@yahoo.co.uk>.
> In many Struts projects I worked on we deliberately modified the
> functionality to use methods off the same class, and it was one of the
> reasons that I liked webwork so much. I think it is elegant that you
> can use one action class for all/most of the CRUD calls, and the
> interceptors allow for applying / disallowing validation based on the
> standard method names being used.
Yup. I like this approach as well. Using the excludeMethods param of Validation and Workflow interceptor to restrict validation is pretty elegant too for me at least.
> Additionally, I find it sometimes useful to add
> sub-packages for actions that return responses from AJAX calls. I guess
> this could be called syntactic sugar, but it is good to isolate the
> URL's and sometimes I want to keep them together rather than have a
> generic "all-ajax" 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 <ia...@fdar.com>
To: Struts Developers List <de...@struts.apache.org>
Sent: Thursday, 3 August, 2006 11:45:45 PM
Subject: Re: [s2] Validation
Ted Husted wrote:
> On 8/3/06, Ian Roughley <ia...@fdar.com> 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 practice?
>
> The "advanced" (but indispensible) features of the framework are
> designed to follow the class hierarchy. We've put in (a lot of)
> special-case handling to accomodate multiple alaises, but the
> architectural grain is that a logical action is mapped to a Java class
> with a single entry point, and the validations, messaging, and type
> converters are all designed to attach to the class.
>
> The first thing that happens when we start using multiple aliases is
> that we want different validations, messages, or type converters for
> this alias or that alias. For example, we have special-case handling
> for several magic aliases to keep validation from firing on "input"
> and "cancel", and so forth.
>
> The cannonical approach would be to have an Input class and a Cancel
> class, so that they do not inherit validators from some other action.
> With modern IDEs and modern JDKs, maintaining a class for each action
> does not seem so great a burden.
>
> Maintaining a set of very similiar and largely redundant mappings is a
> burden, but given wildcards and other features, we can "normalize" the
> mappings so that we can program-by-difference within the
> configuration, just as we do with Java classes.
>
> 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.
In many Struts projects I worked on we deliberately modified the
functionality to use methods off the same class, and it was one of the
reasons that I liked webwork so much. I think it is elegant that you
can use one action class for all/most of the CRUD calls, and the
interceptors allow for applying / disallowing validation based on the
standard method names being used.
The reasons you list above would make sense for having some "best
practices" for when to use each method, but I wouldn't go as far as
saying that it is "not a recommended practice".
>
>> In webwork I make use of nested packages.
>
> Could you explain a bit more about why this is a good practice? Is it
> synantic sugar, or is the practice providing utility that is not
> feasible with unnested packages?
In a large project there are usually several large divisions, these can
then be split into many sub-divisions. Sometimes even further divisions
can be made. This is much the same way I use class hierarchies - not
too flat, not too deep. Additionally, I find it sometimes useful to add
sub-packages for actions that return responses from AJAX calls. I guess
this could be called syntactic sugar, but it is good to isolate the
URL's and sometimes I want to keep them together rather than have a
generic "all-ajax" package.
Wildcards would definitely assist, but I think we should still account
for nested packages.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Ian Roughley <ia...@fdar.com>.
Ted Husted wrote:
> On 8/3/06, Ian Roughley <ia...@fdar.com> 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 practice?
>
> The "advanced" (but indispensible) features of the framework are
> designed to follow the class hierarchy. We've put in (a lot of)
> special-case handling to accomodate multiple alaises, but the
> architectural grain is that a logical action is mapped to a Java class
> with a single entry point, and the validations, messaging, and type
> converters are all designed to attach to the class.
>
> The first thing that happens when we start using multiple aliases is
> that we want different validations, messages, or type converters for
> this alias or that alias. For example, we have special-case handling
> for several magic aliases to keep validation from firing on "input"
> and "cancel", and so forth.
>
> The cannonical approach would be to have an Input class and a Cancel
> class, so that they do not inherit validators from some other action.
> With modern IDEs and modern JDKs, maintaining a class for each action
> does not seem so great a burden.
>
> Maintaining a set of very similiar and largely redundant mappings is a
> burden, but given wildcards and other features, we can "normalize" the
> mappings so that we can program-by-difference within the
> configuration, just as we do with Java classes.
>
> 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.
In many Struts projects I worked on we deliberately modified the
functionality to use methods off the same class, and it was one of the
reasons that I liked webwork so much. I think it is elegant that you
can use one action class for all/most of the CRUD calls, and the
interceptors allow for applying / disallowing validation based on the
standard method names being used.
The reasons you list above would make sense for having some "best
practices" for when to use each method, but I wouldn't go as far as
saying that it is "not a recommended practice".
>
>> In webwork I make use of nested packages.
>
> Could you explain a bit more about why this is a good practice? Is it
> synantic sugar, or is the practice providing utility that is not
> feasible with unnested packages?
In a large project there are usually several large divisions, these can
then be split into many sub-divisions. Sometimes even further divisions
can be made. This is much the same way I use class hierarchies - not
too flat, not too deep. Additionally, I find it sometimes useful to add
sub-packages for actions that return responses from AJAX calls. I guess
this could be called syntactic sugar, but it is good to isolate the
URL's and sometimes I want to keep them together rather than have a
generic "all-ajax" package.
Wildcards would definitely assist, but I think we should still account
for nested packages.
>
> -Ted.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Ted Husted <hu...@apache.org>.
On 8/3/06, Ian Roughley <ia...@fdar.com> 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 practice?
The "advanced" (but indispensible) features of the framework are
designed to follow the class hierarchy. We've put in (a lot of)
special-case handling to accomodate multiple alaises, but the
architectural grain is that a logical action is mapped to a Java class
with a single entry point, and the validations, messaging, and type
converters are all designed to attach to the class.
The first thing that happens when we start using multiple aliases is
that we want different validations, messages, or type converters for
this alias or that alias. For example, we have special-case handling
for several magic aliases to keep validation from firing on "input"
and "cancel", and so forth.
The cannonical approach would be to have an Input class and a Cancel
class, so that they do not inherit validators from some other action.
With modern IDEs and modern JDKs, maintaining a class for each action
does not seem so great a burden.
Maintaining a set of very similiar and largely redundant mappings is a
burden, but given wildcards and other features, we can "normalize" the
mappings so that we can program-by-difference within the
configuration, just as we do with Java classes.
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.
> In webwork I make use of nested packages.
Could you explain a bit more about why this is a good practice? Is it
synantic sugar, or is the practice providing utility that is not
feasible with unnested packages?
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Ian Roughley <ia...@fdar.com>.
Ted Husted wrote:
> On 8/2/06, Don Brown <mr...@twdata.org> 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 nested packages.
>
>
>> 2. How would you handle action methods?
>
> In the scope of convention over configuraion, I'd suggest that we
> don't utilize multiple action methods. I'm coming to the conclusion
> that multiple aliases on an action is not a good practice, much like
> chaining actions is not a good practice.
>
> If we adopt the perspective that one-method per action is the
> cannonical norm, then everything falls into place. The key trouble
> with one-method per action is it increases the number of similar
> action mappings to maintain. But between wildcards, an extends
> feature, and annotations, that problem goes away.
This is actually a feature that I like in WW/SAF, granted some 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 practice?
>
>
>> 3. The case might not always match
>
> Hmmm, I thought the whole idea behind convention over configruation is
> that we *make* these things match because they are *suppose* to match.
>
>
>> One possible solution would be to introduce "wildcard modifiers" that
>> would let
>> you modify the wildcard-matched value. For example, in problem #3,
>> you would
>> want to have "foo/bar" used for the action class "com.acme.{1}.{2}".
>> You could
>> apply a modifier like so - "com.acme.{1}.{2|capitalize}" - which would
>> capitalize the Action name. The idea from these modifiers comes from
>> Javascript
>> Templates [1].
>>
>> 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 capability. There is a danger in being
>> too fancy for
>> your own good, resulting in a feature that is perceived as too
>> complicated and
>> detrimental to the framework. Whether that applies here is up for
>> discussion.
>
> I'd agree that supporting all fancy alternatives is not a good idea.
> The goal should be to solve use cases, not cater to every whim about
> what should be upper or lower case.
>
> People who want to fine-tune this sort of thing can use configuration
> over convention. Convention over configuration should be for people
> who are actually willing to follow a convention.
>
> And, if we use wildcards to define a default convention, there would
> be nothing preventing someone from defining another wildcard
> convention, suitable to specific needs.
>
>
>>
>> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Jason Carreira <fo...@opensymphony.com>.
> On 8/2/06, Don Brown <mr...@twdata.org> 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 action methods?
>
> In the scope of convention over configuraion, I'd
> suggest that we
> don't utilize multiple action methods. I'm coming to
> the conclusion
> that multiple aliases on an action is not a good
> practice, much like
> chaining actions is not a good practice.
>
I can't imagine how many actions we'd have in this case... CRUD actions, in particular, merge 4 or 5 action configurations into one class. Per domain model class.
> If we adopt the perspective that one-method per
> action is the
> cannonical norm, then everything falls into place.
> The key trouble
> with one-method per action is it increases the number
> of similar
> action mappings to maintain. But between wildcards,
> an extends
> feature, and annotations, that problem goes away.
>
Not the number of mappings, the number of classes. Plus, it gets us back to having to have everything have an execute() method, and you lose the ability to call any class, like you can now.
>
> > 3. The case might not always match
>
> Hmmm, I thought the whole idea behind convention over
> configruation is
> that we *make* these things match because they are
> *suppose* to match.
>
this is true... we should establish the convention and stick with it.
> I'd agree that supporting all fancy alternatives is
> not a good idea.
> The goal should be to solve use cases, not cater to
> every whim about
> what should be upper or lower case.
>
> People who want to fine-tune this sort of thing can
> use configuration
> over convention. Convention over configuration should
> be for people
> who are actually willing to follow a convention.
>
> And, if we use wildcards to define a default
> convention, there would
> be nothing preventing someone from defining another
> wildcard
> convention, suitable to specific needs.
>
Agreed.
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=77896#77896
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Ted Husted <hu...@apache.org>.
On 8/2/06, Don Brown <mr...@twdata.org> 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 the scope of convention over configuraion, I'd suggest that we
don't utilize multiple action methods. I'm coming to the conclusion
that multiple aliases on an action is not a good practice, much like
chaining actions is not a good practice.
If we adopt the perspective that one-method per action is the
cannonical norm, then everything falls into place. The key trouble
with one-method per action is it increases the number of similar
action mappings to maintain. But between wildcards, an extends
feature, and annotations, that problem goes away.
> 3. The case might not always match
Hmmm, I thought the whole idea behind convention over configruation is
that we *make* these things match because they are *suppose* to match.
> One possible solution would be to introduce "wildcard modifiers" that would let
> you modify the wildcard-matched value. For example, in problem #3, you would
> want to have "foo/bar" used for the action class "com.acme.{1}.{2}". You could
> apply a modifier like so - "com.acme.{1}.{2|capitalize}" - which would
> capitalize the Action name. The idea from these modifiers comes from Javascript
> Templates [1].
>
> 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 capability. There is a danger in being too fancy for
> your own good, resulting in a feature that is perceived as too complicated and
> detrimental to the framework. Whether that applies here is up for discussion.
I'd agree that supporting all fancy alternatives is not a good idea.
The goal should be to solve use cases, not cater to every whim about
what should be upper or lower case.
People who want to fine-tune this sort of thing can use configuration
over convention. Convention over configuration should be for people
who are actually willing to follow a convention.
And, if we use wildcards to define a default convention, there would
be nothing preventing someone from defining another wildcard
convention, suitable to specific needs.
>
> Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Jason Carreira <fo...@opensymphony.com>.
> 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 capability. There is a
> danger in being too fancy for
> your own good, resulting in a feature that is
> perceived as too complicated and
> detrimental to the framework. Whether that applies
> here is up for discussion.
>
> Don
>
Yes, that's too complicated.
In ActiveMQ for matching destination names, they have an interesting wildcard syntax that just uses 2 wildcard symbols [1]:
> -> match anything after this
* match any one word
if we had a convention that results were always lowercase, you could get away without those checks, too.
[1] - http://incubator.apache.org/activemq/wildcard.html
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=77892#77892
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Don Brown <mr...@twdata.org>.
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 modifiers" that would let
you modify the wildcard-matched value. For example, in problem #3, you would
want to have "foo/bar" used for the action class "com.acme.{1}.{2}". You could
apply a modifier like so - "com.acme.{1}.{2|capitalize}" - which would
capitalize the Action name. The idea from these modifiers comes from Javascript
Templates [1].
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 capability. There is a danger in being too fancy for
your own good, resulting in a feature that is perceived as too complicated and
detrimental to the framework. Whether that applies here is up for discussion.
Don
Ted Husted wrote:
> On 8/2/06, Patrick Lightbody <fo...@opensymphony.com> 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 wildcard expression:
>
> * <action name="*/*" class="com.acme.{1}.{2}">
>
> So the action reference for "whatever.foo.Bar" would be "/foo/Bar"
>
>
>> Results map to the same directory path with the addition of "-success"
>
> If we use the packages for folder names, and the class names for page
> names, then we could use another clean wilcard expression.
>
> * <result>/{1}/{2}.jsp</result>
>
> So, the nominal result for the foo.Bar action would be /foo/Bar.jsp.
>
> We could consider providing some wildcard defaults in the default
> package, which people could then tweak and override as needed.
>
> -T.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Ted Husted <hu...@apache.org>.
On 8/2/06, Patrick Lightbody <fo...@opensymphony.com> 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 wildcard expression:
* <action name="*/*" class="com.acme.{1}.{2}">
So the action reference for "whatever.foo.Bar" would be "/foo/Bar"
> Results map to the same directory path with the addition of "-success"
If we use the packages for folder names, and the class names for page
names, then we could use another clean wilcard expression.
* <result>/{1}/{2}.jsp</result>
So, the nominal result for the foo.Bar action would be /foo/Bar.jsp.
We could consider providing some wildcard defaults in the default
package, which people could then tweak and override as needed.
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Patrick Lightbody <fo...@opensymphony.com>.
> > - 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 packages) that your actions exist in, such as "com.acme.actions"
- 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
- Results map to the same directory path with the addition of "-success" and are JSP only. Ex: com.acme.actions.foo.BarAction with a SUCCESS result maps to /foo/bar-success.jsp.
- If bar-success.jsp can't be found, try bar.jsp.
- Results can be overridden using a @Result annotation at the class or method level, or both. There you can specify basically what you can specify in XML today.
I think that's it. Does that make sense?
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=77653#77653
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Ted Husted <hu...@apache.org>.
On 8/2/06, Patrick Lightbody <fo...@opensymphony.com> wrote:
> - zero configuration (using conventions instead) for actions and results
OK, now define the ideal conventions. :)
-T.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Ted Husted <hu...@apache.org>.
On 8/2/06, Ted Husted <hu...@apache.org> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Jason Carreira <fo...@opensymphony.com>.
> 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 conversion
> - overrides possible in xml
Yes to these, although you should rarely (very very rarely?) ever need to prod the framework for type conversion... especially when we get the generics support 100%
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=77891#77891
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Patrick Lightbody <fo...@opensymphony.com>.
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 conversion
- overrides possible in xml
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=77604#77604
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Ted Husted <hu...@apache.org>.
On 8/2/06, Patrick Lightbody <fo...@opensymphony.com> 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 wildcard issues :(
Film at 11.
One notion would be the idea of using a combined
mapping/validation/message configuration as a "code-behind", and then
offering the same utilty via annotations.
So, for a given Action class, we might have a single XML, along the lines of
<struts>
<package name="Registration.Retrieve" namespace="/Registration"
extends="MailreaderSupport">
<action name="Retrieve" class="mailreader2.Registration.Retrieve">
<result name="input">/pages/Registration.jsp</result>
<result type="redirect-action">MainMenu</result>
<interceptor-ref name="guest"/>
</action>
</package>
<validators>
<field name="username">
<field-validator type="requiredstring">
<message key="error.username.required"/>
</field-validator>
</field>
<field name="password">
<field-validator type="requiredstring">
<message key="error.password.required"/>
</field-validator>
</field>
</validators>
<messages>
<locale name="en">
<key>error.username.required</key>
<text>User Name is required</key>
<key>error.password.required</key>
< text>Password is required</key>
</locale>
</messages>
</struts>
Which would not necessarily obviate have separate -validation,
-action, and -message files, if desired.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Patrick Lightbody <fo...@opensymphony.com>.
Agreed.
> On 8/25/06, Patrick Lightbody
> <fo...@opensymphony.com> 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 able to bind to the
> method makes the
> idiom seem incomplete.
>
> -Ted.
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> dev-unsubscribe@struts.apache.org
> For additional commands, e-mail:
> dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=82525#82525
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Ted Husted <hu...@apache.org>.
On 8/25/06, Patrick Lightbody <fo...@opensymphony.com> 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 able to bind to the method makes the
idiom seem incomplete.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Ted Husted <hu...@apache.org>.
On 8/25/06, Jason Carreira <fo...@opensymphony.com> 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 take into account things like "I
> was called with the 'foo' execute method in Struts". It will have the concept of validation
> contexts. It will be up to the calling environment to map to the validation context based on
> whatever is going on in that environment.
:) Of course, once JSR 303 does start up, you won't be able to talk
about it much, since the JSR panels are bound by confidentiality
agreements, and so everything drops into FUD mode for a year or three
while the JSR panel sorts things out. :)
And, honestly, if we were to adopt methods-as-context validation in
Struts 2, and the spec doesn't honor it, it's not liable to gain much
traction. Not every JSR finds marketplace acceptance. Specs like JSTL
have been successful, but, in the end, after multiple drafts, it was
because the panel figured out how to combine the best of both Struts 1
tags and Velocity expressions.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Jason Carreira <fo...@opensymphony.com>.
> 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" where foo is the class and
> bar is the "context" (ie: the action name). It might
> be time to instead re-evaluate the context being in
> the file name and instead allow for validation rules
> to be bound to the "context" and/or method invocation
> _inside_ the XML file.
>
> Ie: you'd have one foo-validation.xml and then in
> there you could have validation rules that only map
> to certain action aliases (contexts) or only when
> certain methods are being invoked.
>
> Make sense?
>
> PS: The reason I say the ! syntax should be strictly
> left to a URL pattern thing is that we should
> encourage people experimenting 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.
>
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 take into account things like "I was called with the 'foo' execute method in Struts". It will have the concept of validation contexts. It will be up to the calling environment to map to the validation context based on whatever is going on in that environment.
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=82530#82530
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Patrick Lightbody <fo...@opensymphony.com>.
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" where foo is the class and bar is the "context" (ie: the action name). It might be time to instead re-evaluate the context being in the file name and instead allow for validation rules to be bound to the "context" and/or method invocation _inside_ the XML file.
Ie: you'd have one foo-validation.xml and then in there you could have validation rules that only map to certain action aliases (contexts) or only when certain methods are being invoked.
Make sense?
PS: The reason I say the ! syntax should be strictly left to a URL pattern thing is that we should encourage people experimenting 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
> <fo...@opensymphony.com> 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 well.
>
> OK, then to complete the idiom, do we support
>
> * ActionClass!alias-validation.xml
>
> to specify context-based validation for the alias
> command?
>
> And, do we support
>
> <action name="Something!different"
> class="somePackage.Something"
> method="veryDifferent">
> <result input="veryDifferent.jsp />
> </action>
>
> <action name="Something"
> class="somePackage.Something">
> <result input="Something.jsp />
> </action>
>
> So that an action element could override the settings
> for selected
> "!alias" methods (and let the others "fall-thru" to a
> base action)?
>
> Is the "!" idiom promoting a method to a command
> (which is to say
> "action mapping")?
>
> If so, then I believe the idiom is not fully
> expressed. If the "!"
> idiom is creating a "virtual command", then shouldn't
> we be able to
> declare a "static command" using the same syntax,
> and/or tie other
> resources (like the validator) to the "virtual
> command"?
>
> Should the "!" mean: if this command doesn't exist,
> look for a command
> by the name *!, with a method by the name !*, and
> then use
> "command!method" as the cannonical command name.
>
> I believe the fundamental question is
>
> * When we say Something!diffferent, do we mean to
>
> ** pass "different" as an implicit "method="
> attribute to the
> Something command, or
>
> ** create a new ad-hoc "Something!different" command,
> that inherits
> settings from a Something command.
>
> -Ted.
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> dev-unsubscribe@struts.apache.org
> For additional commands, e-mail:
> dev-help@struts.apache.org
>
>
My
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=82511#82511
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Ted Husted <hu...@apache.org>.
On 8/2/06, Patrick Lightbody <fo...@opensymphony.com> 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 well.
OK, then to complete the idiom, do we support
* ActionClass!alias-validation.xml
to specify context-based validation for the alias command?
And, do we support
<action name="Something!different" class="somePackage.Something"
method="veryDifferent">
<result input="veryDifferent.jsp />
</action>
<action name="Something" class="somePackage.Something">
<result input="Something.jsp />
</action>
So that an action element could override the settings for selected
"!alias" methods (and let the others "fall-thru" to a base action)?
Is the "!" idiom promoting a method to a command (which is to say
"action mapping")?
If so, then I believe the idiom is not fully expressed. If the "!"
idiom is creating a "virtual command", then shouldn't we be able to
declare a "static command" using the same syntax, and/or tie other
resources (like the validator) to the "virtual command"?
Should the "!" mean: if this command doesn't exist, look for a command
by the name *!, with a method by the name !*, and then use
"command!method" as the cannonical command name.
I believe the fundamental question is
* When we say Something!diffferent, do we mean to
** pass "different" as an implicit "method=" attribute to the
Something command, or
** create a new ad-hoc "Something!different" command, that inherits
settings from a Something command.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Jason Carreira <fo...@opensymphony.com>.
-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 how to do something, it really ends up being confusing. Besides, they've already got a way to do validations in many more different ways than these... it's called Java. ;-)
> 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 file, but we can do and-thinking
> and allow the developer to choose what best fits his
> design. I am +1 for your idea, as long as you allow
> separate files too.
>
> Paul
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=77886#77886
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Paul Benedict <pa...@yahoo.com>.
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 file, but we can do and-thinking and allow the developer to choose what best fits his design. I am +1 for your idea, as long as you allow separate files too.
Paul
Ted Husted <hu...@apache.org> wrote: In Struts 1, we put the validators in a separate file that's tied to
the mappings through the formbean name, or, alternatively, the path.
In Struts 2, we put the validators in a sepaate file that's tied to
the mappings through the classname.
Why is it that we don't make the validators part of the action
mapping, instead of in a separate element?
I wonder if validators should be more like results. (Pre-results, if
you will.) A mapping could have a default validator mapping. If the
mapping is using wildcards, a different validator mapping could be
selected by a wildcard token, or even an interceptor.
I think one reason people find XML configurations hard to use is
because we keep putting tightly-coupled elements in separate files,
instead of saying it all in one place.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------
Yahoo! Music Unlimited - Access over 1 million songs.Try it free.
Re: [s2] Validation
Posted by Jason Carreira <fo...@opensymphony.com>.
> 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 module now, having moved away from the per-action approach because it's too much work to manage.
>
> 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
> can tie validation to the action name by naming the
> file ActionClasss-actionName-validation.xml. But you
> still also must have the action class in the filename
> as well.
Well, yeah... but you're directly tied to the action properties for validation, so is that really a bad thing?
>
> 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. It won't
> work, of course, but it would be a great blueprint
> for what we should aim for.
I'd suggest not messing with validation too much right now. If you're interested (really, time-investingly interested) in how validation should look in the future, join JSR-303. I don't think it makes a lot of sense to invest time in new validation features only to replace them with the standard when it comes out.
Jason
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=77887#77887
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Validation
Posted by Patrick Lightbody <fo...@opensymphony.com>.
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 can tie validation to the action name by naming the file ActionClasss-actionName-validation.xml. But you still also must have the action class in the filename as well.
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. It won't work, of course, but it would be a great blueprint for what we should aim for.
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=39135&messageID=77586#77586
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org