Re: XWork and Struts Action 2.0
On 4/17/06, Gabe [EMAIL PROTECTED] wrote: It's telling that the lion's share of code related issues we've discussed so far about Struts 2 on this list (Annotation driven actions, pluggability of expression language, use of dev mode, etc., etc.) are really issues that should be brought to the XWork project and aren't really within the scope of what the Webwork project was. Thus, if we don't move over XWork, an important task would be to redefine that relationship. And, IMHO, these are all issues that we should defer until after an initial SAF 2.0.0 release is made available. For now, I would suggest that we keep the focus on phase 1 of the plan, which was to release SAF 2.0.0 based on the WW 2.2.2 codebase without making any unnecessary changes. Let's prove that we can move WebWork over and make a release, before digging into XWork. Once we have a 2.0.0 release under our belt, then we can move forward on phase 2, where we continue improving and evolving the codebase. If XWork would like to join the ASF, then the time to contemplate that step would be during phase 2. * http://wiki.apache.org/struts/StrutsTi We don't need to do everything in one fell swoop. We have all the time we need, but it's important to retain project velocity so that we can release early and release often. I've just gotten back from teaching a four-day training course based on the WebWork/Action2 version of the infamous Struts MailReader. The course went well, and I'm finding that Struts Action 1 skills translate well to WebWork 2.2. It's true that to teach the whole framework, you do have to dip into the XWork jar quite often, but whether the XWork jar comes from OpenSymphony or ASF wouldn't make much difference. Like Jason, I would be -1 on (re)integrating XWork and WebWork, since that would be a slipperly slope. What we need to do most is clarify the boundary between XWork and SAF, so that web developers can see how useful separating concerns can be. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
Don Brown wrote: Bob Lee wrote: Also, how do the tags relate to JSTL? Are we just going to ignore JSTL? Or are we going to use JSTL for JSP with some WebWork-specific extensions and the WebWork tags for other template engines? I personally prefer the latter option. Struts has always tried to work well with standards, and JSTL should be no exception. I guess the question is whether the overlap tags will be deleted or just deprecated. I'm fine with deleted. One of the features I like the most about the WW tags is themes. If we move to JSTL tags, is there a corresponding feature? This is the basis for the ajax integration. Are we going to continue using OGNL, or are we going to use JSP EL? This is a good, yet complicated question that has seen much discussion lately. The bottom line is there are features in OGNL that we can't live without: type conversions, projection, and method calls to name a few. If we can somehow either a) extend the JSP EL to support these features or b) implement OGNL behind the JSP EL API's, I see a future in closer collaboration. From what I understand, both are possible, just waiting for someone to step up and do the work. Good to see you on the list, and congrats on the marriage. I admit I was a little jealous as to its location :) Don Bob On 4/17/06, Jason Carreira [EMAIL PROTECTED] wrote: -1 to moving it over. XWork is not just part of WebWork, it's used other places. You're more than welcome to help do the cleanup in XWork for a 2.0 release. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=26278messageID=51716#51716 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
Ian Roughley wrote: Don Brown wrote: Bob Lee wrote: Also, how do the tags relate to JSTL? Are we just going to ignore JSTL? Or are we going to use JSTL for JSP with some WebWork-specific extensions and the WebWork tags for other template engines? I personally prefer the latter option. Struts has always tried to work well with standards, and JSTL should be no exception. I guess the question is whether the overlap tags will be deleted or just deprecated. I'm fine with deleted. One of the features I like the most about the WW tags is themes. If we move to JSTL tags, is there a corresponding feature? This is the basis for the ajax integration. I don't think this is an either/or decision, but one of eliminating the overlap. JSTL provides some formatting, conditionals, loops, and XML manipulation, while Action 2 tags provide visual and form tags. The only reason we might want to keep the Action 2 tags that overlap is if they provide value for other presentation technologies, since JSTL is only for JSP. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
This doesn't concern XWork itself. Huh? I thought we were talking about moving it? The question is can Struts continue to depend on XWork externally and actually be cohesive? I want one comprehensive manual. I don't necesarily want the servlet API to be readily available, but when I need it, I'd prefer not to go through a ThreadLocal. Okay, so make your Action implement ServletContextAware, ServletRequestAware, etc. - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=26278messageID=51893#51893 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
On 4/18/06, Jason Carreira [EMAIL PROTECTED] wrote: This doesn't concern XWork itself. Huh? I thought we were talking about moving it? I didn't say anything about moving it. Okay, so make your Action implement ServletContextAware, ServletRequestAware, etc. I was specifically thinking about interceptors. We never access servlet classes in actions, but we sometimes need to in interceptors. Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
On 4/18/06, Jason Carreira [EMAIL PROTECTED] wrote: This doesn't concern XWork itself. Huh? I thought we were talking about moving it? I didn't say anything about moving it. Ahh, you're talking about forking it and copying the source into Struts Action 2? -(as many as I'm allowed to vote) - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=26278messageID=51950#51950 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action1] cleaning up the build
On 4/14/06, Wendy Smoak [EMAIL PROTECTED] wrote: ... to get the Javadoc generated for the site, add this to action/pom.xml: reporting plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId configuration aggregatetrue/aggregate /configuration ... I built the javadoc plugin to try the aggregation feature, which partially works. It builds the aggregated Javadoc fine, but then fails afterwards. Brett is aware of it and http://jira.codehaus.org/browse/MJAVADOC-66 has been opened. Looking at the output, which I'll post an example of tonight, I think we need to re-package the app that's using the example package. (Cookbook?) It looks strange in the consolidated list of packages. Don/James... do you want to pull all the xdocs up from the sub-modules of Action and have them all in action/trunk/src/site/ ? I would imagine that eventually, all the reports (JUnit test results, etc.,) will be able to be aggregated and the sub-sites wouldn't be necessary. I'm not sure yet, but making Action's 'site' a module might work better: action/trunk/site/src/site. The WADI incubator project has a similar structure and might be worth looking at: http://svn.apache.org/repos/asf/incubator/wadi/trunk/ -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
On 4/18/06, Jason Carreira [EMAIL PROTECTED] wrote: Ahh, you're talking about forking it and copying the source into Struts Action 2? No... but I do think we should shield Struts users from the XWork API/documentation as much as possible (i.e. a lot more than WebWork does). I _suppose_ it's nice that you can drop down to XWork and do non-web things, but I don't think we need to expose 99.9% of Struts users to this. For starters, we should have a struts.xml, not an xwork.xml. Both Jason and Ted mentioned compatibility. Ted, I completely support the need to maintain velocity. We've been using WebWork heavily for about a year and a half. I think maintaining backward compatibility after you release Struts 2.0.0 is an order of magnitude more important than maintaining backward compatibility with WebWork. It will be harder for me at first, but I'd like to see us take this opportunity to smooth over some of the rough spots so we don't have to break compatibility again down the road. I think support for generics is a must. Struts 2.0.0 will require JDK 1.5, right? For example, getParameters() should return MapString, String[]. Thanks, Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
On 4/18/06, Bob Lee [EMAIL PROTECTED] wrote: No... but I do think we should shield Struts users from the XWork API/documentation as much as possible (i.e. a lot more than WebWork does). I _suppose_ it's nice that you can drop down to XWork and do non-web things, but I don't think we need to expose 99.9% of Struts users to this. For starters, we should have a struts.xml, not an xwork.xml. I would tend to disagree. I feel that the separate of concerns between XWork and a web application front end are important. I don't believe it would be helpful to start lumping things back together again. I would definately feel that this would be too big of a change for SAF 2.0.0. No matter how simple it sounds, there would be some detail that created a showstopper, and then another, and August would turn into February. I do think one problem is that our approach to referring to XWork in the WW book and documentation is inconsistent. There is a tendency to refer to everything as WebWork when it is not. Moving forward, I think we simply need to be more carefult to say XWork when we mean XWork and SAF when we mean SAF, and perhaps just refer to the framework when we do not care to make the distinction. I think support for generics is a must. Struts 2.0.0 will require JDK 1.5, right? For example, getParameters() should return MapString, String[]. No, Struts Action 2.0 will *not* require Java 1.5. I'm sure some future release will increment the platform, but right now, most everyone I know is using Java 1.4 in production. Action 2.0 is meant to be something that we can all start using in production now. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
Ted, The below reason (3rd paragraph, man i wish yahoo did the little things) is why we should probably decide to move XWork over now or forever hold our peace, unless of course phase I is supposed to be an alpha or preview release and phase II is mainly when Action 2 will be in production. In that case we can do anything we want and change it later. However, if we start creating a lingo and pass that lingo on to users creating production apps based on it, then changing that lingo would lead to frustrated developers. I agree that moving over XWork has it's issues (2nd paragraph), but an important question to weigh against that is how do we want to set up the framework long term. Notice how much more elegant it is to say Struts Web, Struts Core and just SAF than to say SAF, XWork and the framework respectively. Another important question is whether we would want to go through XWork to decide what to take out and add in in preparation for action 2, for example, creating an XWork 2.0 if XWork is to stay at OS. Also, I want to make it clear that moving XWork over (1st paragraph) does not imply lumping everything together, something I am strongly against as well. In fact I was more worried about XWork related features being added to SAF 2 if they are seperate, but it seems like everyone here is pretty committed to not let that happen. Gabe - Original Message From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List dev@struts.apache.org Sent: Tuesday, April 18, 2006 3:24:06 PM Subject: Re: XWork and Struts Action 2.0 I would tend to disagree. I feel that the separate of concerns between XWork and a web application front end are important. I don't believe it would be helpful to start lumping things back together again. I would definately feel that this would be too big of a change for SAF 2.0.0. No matter how simple it sounds, there would be some detail that created a showstopper, and then another, and August would turn into February. I do think one problem is that our approach to referring to XWork in the WW book and documentation is inconsistent. There is a tendency to refer to everything as WebWork when it is not. Moving forward, I think we simply need to be more carefult to say XWork when we mean XWork and SAF when we mean SAF, and perhaps just refer to the framework when we do not care to make the distinction. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
On 4/18/06, Ted Husted [EMAIL PROTECTED] wrote: I would tend to disagree. I feel that the separate of concerns between XWork and a web application front end are important. I don't believe it would be helpful to start lumping things back together again. Providing Struts users with a complete, cohesive API doesn't preclude this separation. I do think one problem is that our approach to referring to XWork in the WW book and documentation is inconsistent. There is a tendency to refer to everything as WebWork when it is not. Moving forward, I think we simply need to be more carefult to say XWork when we mean XWork and SAF when we mean SAF, and perhaps just refer to the framework when we do not care to make the distinction. This is exactly what I'm talking about. 99.9% of users (100% of Struts users) don't care about this separation, and they have trouble with it. Even the authors have trouble keeping it straight. No, Struts Action 2.0 will *not* require Java 1.5. I'm sure some future release will increment the platform, but right now, most everyone I know is using Java 1.4 in production. Action 2.0 is meant to be something that we can all start using in production now. Without saying whether we should support 1.4 or not, realistically we're talking about Struts 2.0.0 in production some time after August depending how long it takes users to port their applications, not right now, at this moment, right? JDK 1.6 comes out in the fall at which point 1.4 will be two major releases behind. We must embrace 1.5. We should keep in mind that: - 1.4 support will add complexity and require more development time - 1.4 will become less relevant pretty quickly - 1.4 users have two other options: Struts 1.2 and WebWork 2.2 Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[action2] Java 5 support (was XWork and Struts Action 2.0)
This has been a topic I've been wondering about for a while: would it be possible to move to Java 5, then use a tool such as Retroweaver [1] to provide Java 1.4 support? I'm not prepared to completely abandon Java 1.4 users, but Bob does make some good points regarding the concern for falling too far behind. Does anyone have any experience with such an approach? Don [1] http://retroweaver.sourceforge.net/ Bob Lee wrote: Without saying whether we should support 1.4 or not, realistically we're talking about Struts 2.0.0 in production some time after August depending how long it takes users to port their applications, not right now, at this moment, right? JDK 1.6 comes out in the fall at which point 1.4 will be two major releases behind. We must embrace 1.5. We should keep in mind that: - 1.4 support will add complexity and require more development time - 1.4 will become less relevant pretty quickly - 1.4 users have two other options: Struts 1.2 and WebWork 2.2 Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
On 4/18/06, Bob Lee [EMAIL PROTECTED] wrote: Without saying whether we should support 1.4 or not, realistically we're talking about Struts 2.0.0 in production some time after August depending how long it takes users to port their applications, not right now, at this moment, right? JDK 1.6 comes out in the fall at which point 1.4 will be two major releases behind. We must embrace 1.5. We should keep in mind that: - 1.4 support will add complexity and require more development time - 1.4 will become less relevant pretty quickly - 1.4 users have two other options: Struts 1.2 and WebWork 2.2 Here's the thing: When a committer votes +1 on a release, it's taken to mean that the committer is using the release in production his or herself, and that he or she will support the release with patches and posts to the user list. Technically, we only need three +1s to create a release, but we like to think more than three committers will be available to support a release. It doesn't matter what all the world is doing. What matters is what the committers are doing with their own applications. We aren't creating the framework just for other people to use. We are creating the framework that we want to use with our own applications, and then sharing the wealth with the general public. The Apache term is We eat our own dog food. Before we ask anyone else to put a release in to production, we put it into production ourselves. So, the minimum release platform has to match what the vast majority of committers are now using in production. If the vast majority of committers are using 1.5, then 1.5 would be an option. But that's the only argument that matters. We need the committers to be using 1.5 at their own shops before we could consider changing the release platform here. If someone were to setup that rough spots page, we could also include a section where the committers could sign-up for 1.4 or 1.5 support, based on what they are doing at work. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
You mean we have committers who aren't running 1.5 yet? For shame. ;) I'll set up the rough spots page. Bob On 4/18/06, Ted Husted [EMAIL PROTECTED] wrote: When a committer votes +1 on a release, it's taken to mean that the committer is using the release in production his or herself, and that he or she will support the release with patches and posts to the user list. Technically, we only need three +1s to create a release, but we like to think more than three committers will be available to support a release. It doesn't matter what all the world is doing. What matters is what the committers are doing with their own applications. We aren't creating the framework just for other people to use. We are creating the framework that we want to use with our own applications, and then sharing the wealth with the general public. The Apache term is We eat our own dog food. Before we ask anyone else to put a release in to production, we put it into production ourselves. So, the minimum release platform has to match what the vast majority of committers are now using in production. If the vast majority of committers are using 1.5, then 1.5 would be an option. But that's the only argument that matters. We need the committers to be using 1.5 at their own shops before we could consider changing the release platform here. If someone were to setup that rough spots page, we could also include a section where the committers could sign-up for 1.4 or 1.5 support, based on what they are doing at work. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsAction2 by Bob Lee
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Bob Lee: http://wiki.apache.org/struts/StrutsAction2 -- General thoughts on Webwork * ActionContext - Webwork provides an !ActionContext, which is a wrapper around a number of important objects. This may sound a little mundane, but it's not! Read on! - + * RoughSpots - Things to clean up before 2.0.0. + References * [http://www.mail-archive.com/dev%40struts.apache.org/msg13815.html Original Proposal] - The original !WebWork merger proposal on the Struts dev mailing list * [http://www.opensymphony.com/webwork WebWork] - The Webwork site at !OpenSymphony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by Bob Lee
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Bob Lee: http://wiki.apache.org/struts/RoughSpots New page: Describe RoughSpots here. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
On 4/18/06, Bob Lee [EMAIL PROTECTED] wrote: I'll set up the rough spots page. http://wiki.apache.org/struts/RoughSpots?action=show Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by Bob Lee
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by Bob Lee:
http://wiki.apache.org/struts/RoughSpots
--
- Describe RoughSpots here.
+ * Looking up a `ResultConfig` should be a one-liner. Right now you have to:
{{{
+ ActionConfig config = invocation.getProxy().getConfig();
+ Map results = config.getResults();
+ ResultConfig resultConfig;
+ synchronized (config) {
+ resultConfig = (ResultConfig) results.get(resultCode);
+ }
+ }}}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by Bob Lee
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by Bob Lee:
http://wiki.apache.org/struts/RoughSpots
--
- * Looking up a `ResultConfig` should be a one-liner. Right now you have to:
{{{
+ * Looking up a `ResultConfig` should be a one-liner. Right now you have to:
{{{
ActionConfig config = invocation.getProxy().getConfig();
Map results = config.getResults();
ResultConfig resultConfig;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by Bob Lee
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by Bob Lee:
http://wiki.apache.org/struts/RoughSpots
--
- * Looking up a `ResultConfig` should be a one-liner. Right now you have to:
{{{
+ 1. Looking up a `ResultConfig` should be a one-liner. Right now you have
to: {{{
- ActionConfig config = invocation.getProxy().getConfig();
+ ActionConfig config = invocation.getProxy().getConfig();
- Map results = config.getResults();
+ Map results = config.getResults();
- ResultConfig resultConfig;
+ ResultConfig resultConfig;
- synchronized (config) {
+ synchronized (config) {
- resultConfig = (ResultConfig) results.get(resultCode);
+ resultConfig = (ResultConfig) results.get(resultCode);
- }
+ }
}}}
+ 1. We don't really need the `Action` interface anymore. Should we get rid
of it? It has constant fields for result names. Should we move these to a class
named `ResultNames` and encourage users to static import them as needed?
+
+ 1. Only put classes in root package that most users need to know about. For
example, most don't need to know about `Default*` or `ObjectFactory`.
+
+ 1. Only make classes/members public if we're willing to guarantee future
compatibility. Everything else should be package-private or excluded from the
Javadocs.
+
+ 1. Remove `destroy()` and `init()` from `Interceptor`. They don't make much
sense until the interceptor lifecycle is specified (see next item). I've never
needed them, yet it's a pain to implement empty methods every time I implement
an interceptor. Users can use the constructor/finalizer or we can create
additional lifecycle interfaces.
+
+ 1. Specify `Interceptor` lifecycle. Right now if you apply an interceptor
to a single action, you get a new instance every time. If you define an
interceptor in a stack, the same instance gets reused.
+
+ 1. Get rid of `AroundInterceptor`. Having `before()` and `after()` methods
doesn't make things simpler. It reduces flexibility. You can't return a
different result. You can't handle exceptions cleanly. The actual interceptor
class doesn't appear in the stack trace (you see `AroundInterceptor` over and
over).
+
+ 1. Try to get rid of thread locals: `ActionContext` and
`ServletActionContext`. At least make them package-private. Sometimes
interceptors need access to the servlet API. In this case, they should
implement a servlet-aware interceptor interface. For example: {{{
+ class MyInterceptor implements HttpInterceptor {
+ public String intercept(HttpInvocation i) {
+ HttpServletRequest request = i.getRequest();
+ ...
+ }
+ }
+ }}}
+
+ 1. Is `ValidationAware` a good name? Perhaps `Errors` or `ErrorList` would
be a better name.
+
+ 1. Merge `ActionContext` and `ActionProxy` into `ActionInvocation` (at
least from the users' perspective). Better specify what happens during
chaining/action tags.
+
+ 1. I'm not sure I'd expect `ActionInvocation.getResult()` to recurse over
chain results. Maybe we should have two methods? `getResult()` and
`getFinalResult()`. I've never needed this so I don't know.
+
+ 1. `ActionInvocation.invokeActionOnly()`. Does this need to be public?
Sounds dangerous.
+
+ 1. Eliminate non-private fields. Protected fields in `ActionConfig` for
example.
+
+ 1. Rename `ActionInvocation` to `Invocation` or `Request`. Shorter is
better.
+
+ 1. `TextProvider` is a bad name. The JDK refers to these as messages
everywhere.
+
+ 1. Come up with a clean way to separate view actions from update
actions. For example, you may have `view()` and `update()` methods in the same
action class. Right now XWork has `MethodFilterInterceptor`, but that's not a
very clean solution. You don't want validation or the
`DefaultWorkflowInterceptor` to run for the `view()` method. My current project
has separate interceptor stacks, but it would be nice if there was some first
class support for this. We could flag action invocations as view or update
(using an enum). We could automatically choose a mode based on whether the
request is an HTTP GET or POST. Or we could set the mode based on an annotation
on the action method. Or some other way...
+
+ 1. On the OGNL value stack `#request` refers to request attributes and
`#parameters` refers to the parameters. I think we should rename these
`#request` for request parameters and `#requestAttributes` for request
attributes.
+
+ == Nice to haves ==
+
+ 1. Inheritance is a sucky way to reuse code between actions. It would be
nice if the framework had built-in support for mixins using cglib or Spring.
For example, instead of me extending a class that implements `ValidationAware`,
Struts can extends my action class at runtime and implement the
`ValidationAware` methods by delegating them to another object
DO NOT REPLY [Bug 39121] - [Shale] Implement use of Commons Validator Javascript
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39121. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39121 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2006-04-18 23:11 --- Reopening for documentation review. Are these pages up to date with the changes? http://struts.apache.org/struts-shale/features-commons-validator.html http://wiki.apache.org/struts/Shale/Validation -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by Bob Lee
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by Bob Lee:
http://wiki.apache.org/struts/RoughSpots
--
1. On the OGNL value stack `#request` refers to request attributes and
`#parameters` refers to the parameters. I think we should rename these
`#request` for request parameters and `#requestAttributes` for request
attributes.
+ 1. Warnings and failing siltently sucks. For example, if we can't find a
method in a given action class, blow up ASAP (at load time). We shouldn't be
fuzzy and do stuff like try to find a method named `doXxx()` when we can't find
a method named `xxx()` (WebWork had backward compatibility restrictions, but we
don't need to perpetuate them).
+
+ 1. Add better support for file uploads.
+
+ 1. Don't eat/wrap exceptions. Throw them through to the container. Don't
eat exceptions that occur in getters.
+
+ 1. Modify `ParametersInterceptor` to sort parameter names by depth (using
bucket sort) and then map them in that order (shallowest first), so we can
create objects and then map fields to those objects in the same action
invocation without hacks like applying the `ParametersInterceptor` twice or
chaining.
+
== Nice to haves ==
- 1. Inheritance is a sucky way to reuse code between actions. It would be
nice if the framework had built-in support for mixins using cglib or Spring.
For example, instead of me extending a class that implements `ValidationAware`,
Struts can extends my action class at runtime and implement the
`ValidationAware` methods by delegating them to another object (a mixin): {{{
+ 1. Inheritance is a sucky way to reuse code between actions. I've actually
had to use the strategy pattern to swap in different implementations of stuff
like `ValidationAware`. It would be nice if the framework had built-in support
for mixins using cglib or Spring. For example, instead of me extending a class
that implements `ValidationAware`, Struts can extend my action class at runtime
and implement the `ValidationAware` methods by delegating them to another
object (a mixin): {{{
abstract class MyAction implements Validateable, ValidationAware {
public void validate() {
addActionError(...);
}
}
- }}}
+ }}} You could specify mixin implementation classes by convention (defaults),
in the `struts.xml`, or using annotations.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by Bob Lee
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Bob Lee: http://wiki.apache.org/struts/RoughSpots -- addActionError(...); } } - }}} You could specify mixin implementation classes by convention (defaults), in the `struts.xml`, or using annotations. + }}} You could specify mixin implementation classes by convention (defaults), in the `struts.xml`, or using annotations. This could also be a simpler alternative to action chaining in many cases. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] JAVAWUG BOF XVII / Friday 28th April 2006 @ 19:00 / Oracl e City of London
Dear All The JAVAWUG (Java Web User Group) has rescheduled the BOF XVIII (Number 17) from Thursday 20th April to now Friday 20th April 2006. The birds-of-feather will still take place at the same venue, Oracle's City of London office between 7-9:30 pm. The presentations are and the confirmed speakers are: Prashanth, S. ``J2EE: Security on Websphere'' Peter Pilgrim ``Experiences With WebWork'' Afterwards members can retire to the nearby the ``All Bar One'' pub/restaurant for more in depth discussion dinner, food and drink ... The address is: Oracle City Of London One South Place London, England EC2M 2RB. If you would like to attend, please REGISTER so that you can be added to the SECURITY DETAIL Join the http://groups.google.com/group/javawug JAVAWUG at Google Groups and ``Send an Email to the list you are attending'' Alternatively send mail to myself at peter dot pilgrim at credit-suisse.com and duncan dot mills at oracle.com Here is some relevant travel information: By Underground: - Moorgate: Take the Moorgate East exit, turn right, one block to South Place. Bank: Take the Northern line to Moorgate. Liverpool Street: Take the Broadgate exit, turn right onto South Place Map: http://www.oracle.com/global/uk/corporate/locations/citymap.html The venue has graciously been organised by Duncan Mills of Oracle Corp. We all appreciate this generous gift. http://www.javawug.com/ http://jroller.com/page/peter_pilgrim PS: The presentations will be recorded and I hope to upload them all Google Video Site. search against JAVAWUG for the last video uploads. ==== -- Peter Pilgrim ( Windows XP / Thunderbird 1.5 ) __ _ _ _ / //__ // ___// ___/ + Serverside Java / /___/ // /__ / /__ + Struts / // ___// ___// ___/ + Expresso Committer __/ // /__ / /__ / /__ + Independent Contractor /___/////// + Intrinsic Motivation On Line Resume || \\=== `` http://www.xenonsoft.demon.co.uk/no-it-striker.html '' - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Trivial Update of RoughSpots by Bob Lee
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by Bob Lee:
http://wiki.apache.org/struts/RoughSpots
--
== Nice to haves ==
- 1. Inheritance is a sucky way to reuse code between actions. I've actually
had to use the strategy pattern to swap in different implementations of stuff
like `ValidationAware`. It would be nice if the framework had built-in support
for mixins using cglib or Spring. For example, instead of me extending a class
that implements `ValidationAware`, Struts can extend my action class at runtime
and implement the `ValidationAware` methods by delegating them to another
object (a mixin): {{{
+ 1. Inheritance is a sucky way to reuse code between actions. I've actually
had to use the strategy pattern to swap in different implementations of stuff
like `ValidationAware`. It would be nice if the framework had built-in support
for mixins using cglib or Dynaop. For example, instead of me extending a class
that implements `ValidationAware`, Struts can extend my action class at runtime
and implement the `ValidationAware` methods by delegating them to another
object (a mixin): {{{
abstract class MyAction implements Validateable, ValidationAware {
public void validate() {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: XWork and Struts Action 2.0
This is a great list, thanks for taking the time to put it up. I may not agree with everything, but it is sure to spark conversation :) Don Bob Lee wrote: On 4/18/06, Bob Lee [EMAIL PROTECTED] wrote: I'll set up the rough spots page. http://wiki.apache.org/struts/RoughSpots?action=show Bob - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Trivial Update of EventActionDispatcher by WendySmoak
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by WendySmoak: http://wiki.apache.org/struts/EventActionDispatcher -- /** * Instantiate event dispatcher */ - protected ActionDispatcher dispatcher = + protected ActionDispatcher dispatcher = - new EventActionDispatcher (this, false); + new EventActionDispatcher(this); /** * Use event dispatcher to call an appropriate event handler. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by MichaelJouravlev
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by MichaelJouravlev: http://wiki.apache.org/struts/RoughSpots The comment on the change is: Plugged in EventActionDispatcher information -- 1. `TextProvider` is a bad name. The JDK refers to these as messages everywhere. - 1. Come up with a clean way to separate view actions from update actions. For example, you may have `view()` and `update()` methods in the same action class. Right now XWork has `MethodFilterInterceptor`, but that's not a very clean solution. You don't want validation or the `DefaultWorkflowInterceptor` to run for the `view()` method. My current project has separate interceptor stacks, but it would be nice if there was some first class support for this. We could flag action invocations as view or update (using an enum). We could automatically choose a mode based on whether the request is an HTTP GET or POST. Or we could set the mode based on an annotation on the action method. Or some other way... + 1. Come up with a clean way to separate view actions from update actions. For example, you may have `view()` and `update()` methods in the same action class. Right now XWork has `MethodFilterInterceptor`, but that's not a very clean solution. You don't want validation or the `DefaultWorkflowInterceptor` to run for the `view()` method. My current project has separate interceptor stacks, but it would be nice if there was some first class support for this. We could flag action invocations as view or update (using an enum). We could automatically choose a mode based on whether the request is an HTTP GET or POST. Or we could set the mode based on an annotation on the action method. Or some other way... (MJ: Using GET for render and POST for submit works well unless you want to trigger event with a link. Also, these links might help: DataEntryForm, EventActionDispatcher) 1. On the OGNL value stack `#request` refers to request attributes and `#parameters` refers to the parameters. I think we should rename these `#request` for request parameters and `#requestAttributes` for request attributes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of FormView by angelozerr
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by angelozerr: http://wiki.apache.org/struts/FormView -- * add style class error to the field which has error. * set focus to the first field which has error. + FormView can be used without Struts (JSP Only), by using FormView Servlet, to load your configuration (like Plugin Struts). + You can find FormView Web Site at http://formview.sourceforge.net/ and download JAR at http://sourceforge.net/projects/formview. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by Bob Lee
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by Bob Lee: http://wiki.apache.org/struts/RoughSpots -- 1. `TextProvider` is a bad name. The JDK refers to these as messages everywhere. - 1. Come up with a clean way to separate view actions from update actions. For example, you may have `view()` and `update()` methods in the same action class. Right now XWork has `MethodFilterInterceptor`, but that's not a very clean solution. You don't want validation or the `DefaultWorkflowInterceptor` to run for the `view()` method. My current project has separate interceptor stacks, but it would be nice if there was some first class support for this. We could flag action invocations as view or update (using an enum). We could automatically choose a mode based on whether the request is an HTTP GET or POST. Or we could set the mode based on an annotation on the action method. Or some other way... (MJ: Using GET for render and POST for submit works well unless you want to trigger event with a link. Also, these links might help: DataEntryForm, EventActionDispatcher) + 1. Come up with a clean way to separate view actions from update actions. For example, you may have `view()` and `update()` methods in the same action class. Right now XWork has `MethodFilterInterceptor`, but that's not a very clean solution. You don't want validation or the `DefaultWorkflowInterceptor` to run for the `view()` method. My current project has separate interceptor stacks, but it would be nice if there was some first class support for this. We could flag action invocations as view or update (using an enum). We could automatically choose a mode based on whether the request is an HTTP GET or POST. Or we could set the mode based on an annotation on the action method. Or some other way... + * MJ: Using GET for render and POST for submit works well unless you want to trigger event with a link. Also, these links might help: DataEntryForm, EventActionDispatcher + * crazybob: Triggering an event should still be a POST (though the framework should make it easy). From the HTTP spec.: GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. 1. On the OGNL value stack `#request` refers to request attributes and `#parameters` refers to the parameters. I think we should rename these `#request` for request parameters and `#requestAttributes` for request attributes. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of StrutsAction2 by TedHusted
Dear Wiki user, You have subscribed to a wiki page or wiki category on Struts Wiki for change notification. The following page has been changed by TedHusted: http://wiki.apache.org/struts/StrutsAction2 -- General thoughts on Webwork * ActionContext - Webwork provides an !ActionContext, which is a wrapper around a number of important objects. This may sound a little mundane, but it's not! Read on! - * RoughSpots - Things to clean up before 2.0.0. + * RoughSpots - Some things that could be addressed before 2.0.0. References * [http://www.mail-archive.com/dev%40struts.apache.org/msg13815.html Original Proposal] - The original !WebWork merger proposal on the Struts dev mailing list - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Trivial Update of RoughSpots by TedHusted
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by TedHusted:
http://wiki.apache.org/struts/RoughSpots
The comment on the change is:
Conform pronouns to use we throughout
--
+ Some things that could be addresssed before Action 2.0.0.
+
- 1. Looking up a `ResultConfig` should be a one-liner. Right now you have
to: {{{
+ 1. Looking up a `ResultConfig` should be a one-liner. Right now we have to:
{{{
ActionConfig config = invocation.getProxy().getConfig();
Map results = config.getResults();
ResultConfig resultConfig;
@@ -17, +19 @@
1. Remove `destroy()` and `init()` from `Interceptor`. They don't make much
sense until the interceptor lifecycle is specified (see next item). I've never
needed them, yet it's a pain to implement empty methods every time I implement
an interceptor. Users can use the constructor/finalizer or we can create
additional lifecycle interfaces.
- 1. Specify `Interceptor` lifecycle. Right now if you apply an interceptor
to a single action, you get a new instance every time. If you define an
interceptor in a stack, the same instance gets reused.
+ 1. Specify `Interceptor` lifecycle. Right now if we apply an interceptor to
a single action, we get a new instance every time. If we define an interceptor
in a stack, the same instance gets reused.
- 1. Get rid of `AroundInterceptor`. Having `before()` and `after()` methods
doesn't make things simpler. It reduces flexibility. You can't return a
different result. You can't handle exceptions cleanly. The actual interceptor
class doesn't appear in the stack trace (you see `AroundInterceptor` over and
over).
+ 1. Get rid of `AroundInterceptor`. Having `before()` and `after()` methods
doesn't make things simpler. It reduces flexibility. We can't return a
different result. You can't handle exceptions cleanly. The actual interceptor
class doesn't appear in the stack trace (we see `AroundInterceptor` over and
over).
1. Try to get rid of thread locals: `ActionContext` and
`ServletActionContext`. At least make them package-private. Sometimes
interceptors need access to the servlet API. In this case, they should
implement a servlet-aware interceptor interface. For example: {{{
class MyInterceptor implements HttpInterceptor {
@@ -34, +36 @@
1. Merge `ActionContext` and `ActionProxy` into `ActionInvocation` (at
least from the users' perspective). Better specify what happens during
chaining/action tags.
- 1. I'm not sure I'd expect `ActionInvocation.getResult()` to recurse over
chain results. Maybe we should have two methods? `getResult()` and
`getFinalResult()`. I've never needed this so I don't know.
+ 1. Should `ActionInvocation.getResult()` recurse over chain results? Maybe
we should have two methods? `getResult()` and `getFinalResult()`. Is there a
good use case for this?
1. `ActionInvocation.invokeActionOnly()`. Does this need to be public?
Sounds dangerous.
@@ -42, +44 @@
1. Rename `ActionInvocation` to `Invocation` or `Request`. Shorter is
better.
- 1. `TextProvider` is a bad name. The JDK refers to these as messages
everywhere.
+ 1. Is `TextProvider` a good name? The JDK refers to these as messages
everywhere.
- 1. Come up with a clean way to separate view actions from update
actions. For example, you may have `view()` and `update()` methods in the same
action class. Right now XWork has `MethodFilterInterceptor`, but that's not a
very clean solution. You don't want validation or the
`DefaultWorkflowInterceptor` to run for the `view()` method. My current project
has separate interceptor stacks, but it would be nice if there was some first
class support for this. We could flag action invocations as view or update
(using an enum). We could automatically choose a mode based on whether the
request is an HTTP GET or POST. Or we could set the mode based on an annotation
on the action method. Or some other way...
+ 1. Come up with a clean way to separate view actions from update
actions. For example, we might have `view()` and `update()` methods in the same
action class. Right now XWork has `MethodFilterInterceptor`, but that's not a
very clean solution. Do we want validation or the `DefaultWorkflowInterceptor`
to run for the `view()` method? One solution is separate interceptor stacks,
but it would be nice if there were some first class support for this. We could
flag action invocations as view or update (using an enum). We could
automatically choose a mode based on whether the request is an HTTP GET or
POST. Or we could set the mode based on an annotation on the action method. Or
some other way...
* MJ: Using GET for render and POST for submit works well unless you want
to trigger event with a link. Also, these links might help:
[Struts Wiki] Update of RoughSpots by Bob Lee
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Struts Wiki for change
notification.
The following page has been changed by Bob Lee:
http://wiki.apache.org/struts/RoughSpots
--
- Some things that could be addresssed before Action 2.0.0.
+ Some things that could be addresssed before Action 2.0.0. (If we don't
address them, we'll be stuck supporting them throughout all eternity or until
Struts 3.0.0, whichever comes first. ;))
1. Looking up a `ResultConfig` should be a one-liner. Right now we have to:
{{{
ActionConfig config = invocation.getProxy().getConfig();
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
A clean way to separate view actions from update actions
I decided to pull this out to the mailing list to keep Rough Spots page [1] cleaner. crazybob: Come up with a clean way to separate view actions from update actions. ... [As one of the options] we could flag action invocations as view or update (using an enum). We could automatically choose a mode based on whether the request is an HTTP GET or POST. MichaelJ: Using GET for render and POST for submit works well unless you want to trigger event with a link. crazybob: Triggering an event should still be a POST (though the framework should make it easy). From the HTTP spec.: 'GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval.' What actually should be done by a particular developer of a particular application is a religious question. There is no legal way known to me that allows to send POST request via a link without using Javascript. Web applications take actions and change their state using links all the time. Heck, take any web-based client, be it GMail or Yahoo, they use links. Take CRUD application, the view/edit/delete actions are usually made with links because putting three buttons on every line would look ugly (well, modern apps use Javascript and highlighing, but this is another story). I've been there and came back. Yes, using POST is cleaner HTTP-wise, but the goal of a framework is to simplify programmers' job, not to prohibit them from doing something. Also if you noticed, HTTP spec says SHOULD NOT, not MUST NOT. So, using GET is not prohibited, it is simply frowned upon, but as I said everyone uses links for actions and state change. Therefore, while a framework should teach good practices, it should not prohibit from something that is technically feasible, but just unacceptable for framework designers. I don't want framework to work against me. Need no gods (have I already said that?) So, as you responded, triggering an event *should* be a POST, but it is not like it *must be*. Framework should allow to use both POST and GET to trigger an event. Obviously, using POST vs. GET as a division point between submit and render is simple. Therefore it might be sensible to agree, that POST always triggers input phase, while GET requires further screening. I suggest taking a look at EventActionDispatcher [2] class and its usage in Struts 1.x [3]. Basically, you define events that an action (sorry, actionbean) responds to. If event is found in the request, this is input phase. Appropriate event handler is called, as well as validation/conversion (though I would really-really prefer to call validation/conversion/etc manually without having to implement a bunch of interfaces). If event is not found, then this is a render phase. Plain and simple. Michael. [1] http://wiki.apache.org/struts/RoughSpots [2] http://wiki.apache.org/struts/EventActionDispatcher [3] http://wiki.apache.org/struts/DataEntryForm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A clean way to separate view actions from update actions
I'll buy that, but users should understand that malicious users can put HTML like this on other sites: img src=http://yoursite/deleteAccount; That's not to say that POSTs are 100% immune to this sort of thing. They're just slightly less susceptible. The safe solution is to emded some sort of unique token in the URL, but I'll leave that topic for another day. This is why I went on to say, or we could set the mode based on an annotation on the action method. Or some other way... My thinking is we could set the mode based on GET/POST and let users override it in the Struts configuration or using annotations. Bob On 4/18/06, Michael Jouravlev [EMAIL PROTECTED] wrote: I decided to pull this out to the mailing list to keep Rough Spots page [1] cleaner. crazybob: Come up with a clean way to separate view actions from update actions. ... [As one of the options] we could flag action invocations as view or update (using an enum). We could automatically choose a mode based on whether the request is an HTTP GET or POST. MichaelJ: Using GET for render and POST for submit works well unless you want to trigger event with a link. crazybob: Triggering an event should still be a POST (though the framework should make it easy). From the HTTP spec.: 'GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval.' What actually should be done by a particular developer of a particular application is a religious question. There is no legal way known to me that allows to send POST request via a link without using Javascript. Web applications take actions and change their state using links all the time. Heck, take any web-based client, be it GMail or Yahoo, they use links. Take CRUD application, the view/edit/delete actions are usually made with links because putting three buttons on every line would look ugly (well, modern apps use Javascript and highlighing, but this is another story). I've been there and came back. Yes, using POST is cleaner HTTP-wise, but the goal of a framework is to simplify programmers' job, not to prohibit them from doing something. Also if you noticed, HTTP spec says SHOULD NOT, not MUST NOT. So, using GET is not prohibited, it is simply frowned upon, but as I said everyone uses links for actions and state change. Therefore, while a framework should teach good practices, it should not prohibit from something that is technically feasible, but just unacceptable for framework designers. I don't want framework to work against me. Need no gods (have I already said that?) So, as you responded, triggering an event *should* be a POST, but it is not like it *must be*. Framework should allow to use both POST and GET to trigger an event. Obviously, using POST vs. GET as a division point between submit and render is simple. Therefore it might be sensible to agree, that POST always triggers input phase, while GET requires further screening. I suggest taking a look at EventActionDispatcher [2] class and its usage in Struts 1.x [3]. Basically, you define events that an action (sorry, actionbean) responds to. If event is found in the request, this is input phase. Appropriate event handler is called, as well as validation/conversion (though I would really-really prefer to call validation/conversion/etc manually without having to implement a bunch of interfaces). If event is not found, then this is a render phase. Plain and simple. Michael. [1] http://wiki.apache.org/struts/RoughSpots [2] http://wiki.apache.org/struts/EventActionDispatcher [3] http://wiki.apache.org/struts/DataEntryForm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: A clean way to separate view actions from update actions
Also, the first couple paragraphs in the DefaultActionMapper section describe how WebWork handles this sort of dispatching: http://opensymphony.com/webwork/wikidocs/ActionMapper.html Bob On 4/18/06, Michael Jouravlev [EMAIL PROTECTED] wrote: I decided to pull this out to the mailing list to keep Rough Spots page [1] cleaner. crazybob: Come up with a clean way to separate view actions from update actions. ... [As one of the options] we could flag action invocations as view or update (using an enum). We could automatically choose a mode based on whether the request is an HTTP GET or POST. MichaelJ: Using GET for render and POST for submit works well unless you want to trigger event with a link. crazybob: Triggering an event should still be a POST (though the framework should make it easy). From the HTTP spec.: 'GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval.' What actually should be done by a particular developer of a particular application is a religious question. There is no legal way known to me that allows to send POST request via a link without using Javascript. Web applications take actions and change their state using links all the time. Heck, take any web-based client, be it GMail or Yahoo, they use links. Take CRUD application, the view/edit/delete actions are usually made with links because putting three buttons on every line would look ugly (well, modern apps use Javascript and highlighing, but this is another story). I've been there and came back. Yes, using POST is cleaner HTTP-wise, but the goal of a framework is to simplify programmers' job, not to prohibit them from doing something. Also if you noticed, HTTP spec says SHOULD NOT, not MUST NOT. So, using GET is not prohibited, it is simply frowned upon, but as I said everyone uses links for actions and state change. Therefore, while a framework should teach good practices, it should not prohibit from something that is technically feasible, but just unacceptable for framework designers. I don't want framework to work against me. Need no gods (have I already said that?) So, as you responded, triggering an event *should* be a POST, but it is not like it *must be*. Framework should allow to use both POST and GET to trigger an event. Obviously, using POST vs. GET as a division point between submit and render is simple. Therefore it might be sensible to agree, that POST always triggers input phase, while GET requires further screening. I suggest taking a look at EventActionDispatcher [2] class and its usage in Struts 1.x [3]. Basically, you define events that an action (sorry, actionbean) responds to. If event is found in the request, this is input phase. Appropriate event handler is called, as well as validation/conversion (though I would really-really prefer to call validation/conversion/etc manually without having to implement a bunch of interfaces). If event is not found, then this is a render phase. Plain and simple. Michael. [1] http://wiki.apache.org/struts/RoughSpots [2] http://wiki.apache.org/struts/EventActionDispatcher [3] http://wiki.apache.org/struts/DataEntryForm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 39121] - [Shale] Implement use of Commons Validator Javascript
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=39121.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=39121
--- Additional Comments From [EMAIL PROTECTED] 2006-04-19 02:14 ---
(In reply to comment #4)
Reopening for documentation review. Are these pages up to date with the
changes?
http://struts.apache.org/struts-shale/features-commons-validator.html
http://wiki.apache.org/struts/Shale/Validation
I believe that they do describe the current validator. The areas expanded on
were not specifically addressed in the documentation anyway. The area that
was fuzzy before was defining a new validation rule. There was not any direct
association of a method parameter with a variable. The logic just happed to
assemble the parameters in a predefined order based on the know set of rules.
This was also true for substitution of message parameters associated with
variables.
However, we might want to expand on how you can create a custom rule. The
CommonsVaidatorTestCase shows and example.
JSP:
s:commonsValidator type=testRule2 message={0} must be one of the
following: {2}. arg=Favorite Color
s:validatorVar name=enumerations value=black, yellow, red/
/s:commonsValidator
validation.xml
global
validator name=testRule2
classname=org.apache.shale.validator.CommonsValidatorTestCase
method=isValid
methodParams=java.lang.String, java.lang.String
msg=errors.invalid
/validator
/global
formset
form name=org.apache.shale.validator.testRule2
field property=testRule2
arg position=0 name=message key=arg resource=false/
arg position=1 name=message key=submittedValue
resource=false/
arg position=2 name=message key=enumerations
resource=false/
arg position=0 name=parameter key=submittedValue
resource=false/
arg position=1 name=parameter key=enumerations
resource=false/
/field
/form
/formset
Rule Method:
//test validation rule
public static boolean isValid(String value, String colors) {
StringTokenizer tokenizer = new StringTokenizer(colors, ,);
while (tokenizer.hasMoreTokens()) {
String color = tokenizer.nextToken().trim();
if (value.equals(color))
return true;
}
return false;
}
Do you thing that something like this would be a good addition?
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r395124 - in /struts/action/trunk/src: ./ site/
Author: wsmoak Date: Tue Apr 18 21:10:42 2006 New Revision: 395124 URL: http://svn.apache.org/viewcvs?rev=395124view=rev Log: Move documentation up to top-level Struts Action site. (Part 1) Added: struts/action/trunk/src/ struts/action/trunk/src/site/ - copied from r395117, struts/action/trunk/core/src/site/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r395126 - /struts/action/trunk/core/src/site/
Author: wsmoak Date: Tue Apr 18 21:11:48 2006 New Revision: 395126 URL: http://svn.apache.org/viewcvs?rev=395126view=rev Log: Move documentation up to top-level Struts Action site. (Part 2) Removed: struts/action/trunk/core/src/site/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
svn commit: r395128 - /struts/action/trunk/pom.xml
Author: wsmoak Date: Tue Apr 18 21:12:48 2006 New Revision: 395128 URL: http://svn.apache.org/viewcvs?rev=395128view=rev Log: Add reporting config for the Javadoc plugin. (Aggregation will only work with 2.0-SNAPSHOT.) Modified: struts/action/trunk/pom.xml Modified: struts/action/trunk/pom.xml URL: http://svn.apache.org/viewcvs/struts/action/trunk/pom.xml?rev=395128r1=395127r2=395128view=diff == --- struts/action/trunk/pom.xml (original) +++ struts/action/trunk/pom.xml Tue Apr 18 21:12:48 2006 @@ -116,6 +116,18 @@ /build +reporting +plugins +plugin +groupIdorg.apache.maven.plugins/groupId +artifactIdmaven-javadoc-plugin/artifactId +configuration +aggregatetrue/aggregate +/configuration +/plugin +/plugins +/reporting + dependencies/ repositories - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26322] - WebLogic
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26322. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26322 [EMAIL PROTECTED] changed: What|Removed |Added Summary|WebLogic hot-deploy breaks |WebLogic |Tiles; TilesRequestProcessor| |is not serializable | -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 26322] - WebLogic hot-deploy breaks Tiles
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=26322. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=26322 [EMAIL PROTECTED] changed: What|Removed |Added Summary|WebLogic|WebLogic hot-deploy breaks ||Tiles -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action1] cleaning up the build
On 4/18/06, Don Brown [EMAIL PROTECTED] wrote: We definitely need an action/src/site directory to contain the root site.xml that others inherit, and if you can get over the aforementioned issue, then collecting all docs there would work for me. I moved action/core/src/site up to src/site, and here's the aggregated Javadoc: http://cvs.apache.org/builds/struts/maven/test-site/struts-action/apidocs/ I'm working with snapshots of the site and javadoc plugins, so if any of the configuration causes a problem with the latest released versions, just comment it out or let me know. Thanks, -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
