[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 -- result name=inputaddPerson.jsp/result /action}}}The ValidationInterceptor should still cause an input result to occur but if we make it through to invoking the action and there is no execute method we return the value of the configured assumed result. + 1. When an action returns `LOGIN`, save the request in the session (even POSTs) and enable the user to re-execute it after login. + == What JDK Version? == * [jcarreira] We've been using JDK 1.5 on Tomcat 5+ for over a year... Everything we write and wire together is using generics and 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
--
param name=namespace/${actionNamespace}/param
/result
}}} My point is this feature enables a new style of development, one closer
to RoR and, IMO, easier for the newbie, without affecting anyone else.
+ * [crazybob] Assuming you have a `getResult()` method and you've defined
a global result, your second example could look like this: {{{
+ result = ActionRedirectResult(bar, foo);
+ return CUSTOM;
+ }}} A Ruby on Rails analog would look like this: {{{
+ public void execute() {
+ ...
+ if (foo) {
+ redirectToAction(foo, bar);
+ }
+ else {
+ forwardToAction(tee);
+ }
+ }
+ }}} If the user doesn't call a result method, we would use an intelligent
default. You could implement this using an interceptor and an action support
class. However, I'm with Jason: I've never needed this and I like the
seperation.
== Nice to haves ==
-
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. Clean up documentation. Focus on quality not quantity. * [jcarreira] Didn't you read the book? ;-) * [tm_jee] +1 What do you think about the reference docs, we put a lot of effort in it. Of course there's still lots of room for improvement. We'll continue to do our best. :-) + + 1. Do we want to keep `ModelDriven`? + + 1. Do we want `ValidationAware` (or its equivalent) to take message keys or actual messages. It takes the actual messages in WW2. `ActionMessages` in Struts takes keys. I'm a fan of keys; we would no longer need `TextProvider`. Pat suggested we take keys, and in the event that we don't find a message for the given key, pass the key along as the message. I think I'd rather fail fast. + + 1. Craig McC mentioned that we might want to use this in a portlet. Does this mean I should completely abstract us from `HttpServletRequest`/`PortletRequest`? == Patrick's issues == - 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. Craig McC mentioned that we might want to use this in a portlet. Does this mean I should completely abstract us from `HttpServletRequest`/`PortletRequest`? * [mrdon] +1, at least in some form. This was the goal of the generic ActionContext, I believe. Cocoon has been struggling with the same issue, and they are leaning towards implementing the HttpServletRequest, et al with a portlet impl to solve this problem. They used to have this generic Environment api, but they are in the process of giving that up, I believe, favoring this servlet api approach. I wonder if we shouldn't find out more about their results and adopt them. + + 1. Add action and method attributes to the submit button tag so users don't have to know about the action:Name and method:name conventions. == Patrick's issues == - 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 -- with annotations instead. For a detailed example, take a look at how Shale's Tiger Extensions package lets you get the functionality of a ViewController interface without having to say implements ViewController in your action class. + * [crazybob] +1 for keeping the `Action` interface--it enforces that `execute()` is the default method. 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`. * [plightbo] +1 on this - sounds like Bob has a good handle on what it takes to make a nice API. I'll defer to him on this. @@ -38, +39 @@ subtlety here to take into account -- there is a difference between APIs that application developers should depend on versus those extending the framework should be allowed to extend. The latter category of folks can be presumed to be smaller, as well as more willing to deal with occastional API breakages. + * [crazybob] +1 for impl package naming convention. I think we should focus on the application developer API for the initial release and then introduce a more featureful extension API in a later release. 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. @@ -89, +91 @@ you are in exactly the same boat. The Servlet API considers this a feature rather than a bug, because a Filter can actually wrap the incoming request and response objects to provide extra functionality -- this at least wouldn't be possible in the case of a thread-local state object. + * [crazybob] Good point (Though it is possible with a thread local API. Your code can set the thread local to your wrapped object and then restore the original object in a finally block. Not ideal.) * [craigmcc] Interceptors need access to the servlet API -- doesn't anyone care about making it possible to write applications that work for portlets too? I would hope that we all work towards a world where direct access to the underlying servlet API objects is considered an anti-pattern. + * [crazybob] Another good point. 1. Is `ValidationAware` a good name? Perhaps `Errors` or `ErrorList` would be a better name. @@ -143, +147 @@ * [jcarreira] I think it's great that you want to take the HTTP spec at its word... most users don't care though. * [crazybob] I'm not arguing semantics. There are real security implications to using GET when you should use POST, not to mention products like Google Web Accelerator will reak havok on your site. As framework developers, we should make using POST as easy as GET for users. To not help users do the right thing in this situation would be irresponsible, and not in the letter of the law sense. * [frankz] Perhaps a new attribute on the action mapping? type=view or type=update? This would really make the mapping of a specific various type, not the underlying Action, which might be better because the type is abstracted from the actual implementation and the Action class itself can house both types of functions (i.e., something like a !DispatchAction), but the framework can know to treat them differently as appropriate. I'm not one of those no XML config! folks, I actually still prefer it to annotations, but having an analogous annotation would be a good idea too. + * [crazybob] In addition to view and update, we might want chained view and chained update. Can anyone else think of more stereotypes? Can you think of a better name than stereotype? Strategy? 1. On the OGNL value stack `#request` refers to request attributes and `#parameters` refers to the parameters. We could rename these `#request` for request parameters and `#requestAttributes` for request attributes. @@ -178, +183 @@ 1. Enable Java package import in configuration so you don't have to repeat the same package name over and over (like WW1 does). * [jcarreira] +1 if it can be made sane... It can get confusing. It also makes tool support worse (i.e. IDEA can find it as a fully qualified class name) + * [crazybob] Regarding tool support, I like writing less code, and this doesn't preclude using fully qualified class names if you still want to. Hopefully this new exposure will bring us real tool support and this won't be an issue. 1. The ajax support is pitiful. Have a look at how stripes does it. Ajax for validation is trivial and not that impressive, but people are going to want to do real ajax work, and
[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 -- * [tfenne] I think you *have* to support JDK 1.5, and it should be the default. If it's not too hard to provide 1.4 compatibility great, but I think all examples, defaults etc. should leverage 1.5. Generics allow you to do much more for the user without asking for configuration information. If a user wants to use JDK 1.5 enums, it should work, etc. etc. If it's extra work on the user's part to make 1.5 features work, simplicity goes out the window. * [frankz] I think this is one of those things to be really careful about the perception people may form. If Action1 is going to continue to develop and be supported, even if to a lesser degree, then forcing 1.5 for Action2 is probably fine. However, I know at my company, we are stuck on 1.4, and won't be changing for a long time. I also know that we are not unique in this regard. If we can't move to Action2. so long as Action1 is still around and being supported, that's fine. But if we can't move to Action2 and it even '''seems''' like Action1 isn't getting enough attention, that wouldn't look so good to us. Ultimately, if both can be supported, I think that is still the best answer. I definitely think the points made about moving to 1.5 are totally valid, but I think that may lock out a lot of people who might otherwise use Action2, so if that can be avoided, so much the better. * [crazybob] Someone made the point earlier on that if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too. With a little time, 1.4 will become irrelevant. I'm fine with supporting 1.4, but 1.5 should be the priority, and we shouldn't let 1.4 support negatively impact design decisions. -* [gdinwiddie] WRT if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too, I don't think that's necessarily true. In companies where I've worked, the choice of what libraries are used for app development are often made by the developers of that app, but choice of app server (which dictates JDK version), is generally made at a higher level, and often by a slow-moving committee. + * [gdinwiddie] WRT if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too, I don't think that's necessarily true. In companies where I've worked, the choice of what libraries are used for app development are often made by the developers of that app, but choice of app server (which dictates JDK version), is generally made at a higher level, and often by a slow-moving committee. + * [crazybob] You're right. That's actually been my experience, too. I'm fine with supporting 1.4 (though I'd prefer not to have to write the code as I haven't used it for some time). - 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
--
* [crazybob] There's no reason we can't support both `String` and
`Result` return types for action methods. I think we should encourage `String`
though. Can you provide some example use cases for when `String` isn't enough?
* [frankz] A few that come to mind... the ability to choose between
redirect and forward based on decisions made in code (you could argue that you
can have two result's defined, one with type redirect and one with type
forward, but then that starts to clutter the config file I think)... the
ability to add parameters to a forwarded result (i.e., if you wanted to forward
to another action, how can you add parameters just by returning a String?
Well, unless the processor expects and can deal with a query string appended I
support)... the ability to add an anchor name to the response... the
opportunity to include additional objects in the response (i.e., what if you
had some sort of ViewSupport object that the presentation can make use of... it
might be more intuitive to add it to a Result than to directly add it as a
request attribute, and that also makes for better abstraction from the servlet
API). I'm sure there's more, and I'm sure there are ways to accomplish most
of these things without returning an object, but I think the clarity of the
resultant code is greater by returning a Result object, and it opens up
possibilities I can't think of (i.e., functionality encapsulated in that object
independant of tbe interceptor stack).
* [mrdon] For further reading:
http://forums.opensymphony.com/thread.jspa?threadID=23621tstart=45
+ * [crazybob] I'm not sold on this. 1) The result pulls values from the
value stack, not the request attributes. 2) I ran into a case recently where I
''thought'' I wanted to return a real object at first: I wanted the action to
dynamically select a redirect URL. I ended up doing this: {{{
+ result name=... type=redirect${url}/result
+ }}} 3) Enabling users to return either a real object or a string is going to
impact the interceptor API, too. :( 4) Wait a second... you can do what you
want right now! Create a new result type which looks up a `Result` object on
the value stack and delegates to it. Then map a global result to the new type.
For example, you could return `CUSTOM`, and the the result type would execute
the `Result` returned from `getCustomResult()` on your action. ;)
+
== Nice to haves ==
1. Inheritance is not a good way to reuse code between actions. One work
around is to use the strategy pattern to swap in different implementations of
interfaces like `ValidationAware`. It would be nice if the framework had
built-in support for mixins using cglib or Dynaop. For example, instead of
extending a class that implements `ValidationAware`, SAF could extend an action
class at runtime and implement the `ValidationAware` methods by delegating them
to another object (a mixin): {{{
-
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. Allow indexable parameters similar to how it works in struts (with indexed=true) but being able to take advantage of XWork's advanced type conversion features. See: [https://issues.apache.org/struts/browse/WW-1189]. This is unfortunately not trivial at all. 1. Get rid of the use of static constant variables that are used in the key in the stack and accessed all over the place like XWorkNullHandler.CREATE_NULL_OBJECTS etc. I've started to do that with the OgnlContextState class, but it's not complete and I'm not sure if that's the best way to do it. 1. Specify and simplify Interceptor scope. Currently, you have an Interceptor that calls actionInvocation.invoke() and then returns a different result than actionInvocation.invoke() returns, the actionInvocation.invoke() result will be used anyway. This is confusing and muddies the meaning of the Interceptor API, which IMHO should simply wrap the action not the action all the way through to the end of the result. The reason it's set up the way it is, as I understand it, is so that Interceptors can clean up resources like connections after the result is returned. However, I wonder if we can implement a request based object that can take care of such resources and destroy them at the end of the request rather than using Interceptors in this way. - + * [crazybob] That was really surprising and confusing to me at first, too. I thought it would have been more intuitive for the result to run after all the interceptors returned. I'm not sure whether we should change it or not. I like the idea of interceptors being able to clean up after results a lot more than I like the idea of an interceptor being able to return a different result. == Tim's Issues == I'm new around here, so be nice ;) I probably have a lot less WW experience than most, so I apologize in advance if I'm flat out wrong about some of the things here. - 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
The comment on the change is:
Posting comments on behalf of Hani.
--
* [plightbo] As Gabe said, we already discussed this. And the last post
on the subject was that we should do it. We still should.
* [Gabe] I've created an XWork JIRA for a solution to the same use case
here. [http://jira.opensymphony.com/browse/XW-387] I'd be happy to contribute
the code.
+ 1. Allow paths in action names. For example `action
name=reports/myreport`.
+
+ 1. Enable Java package import in configuration so you don't have to repeat
the same package name over and over (like WW1 does).
+
+ 1. The ajax support is pitiful. Have a look at how stripes does it. Ajax
for validation is trivial and not that impressive, but people are going to want
to do real ajax work, and webwork does absolutely nothing to help in that
regard. I'd like to for example be able to easily invoke actions and get at
some kind of result to display, and have webwork provide at least some of the
wiring
+
+ 1. The default theme for the ui tags should be simple. The current stuff is
too dumb to get right on the first go, which gives an awful impression. It's
NOT intuitive to write: {{{
+ table
+ ww:textfield label=Enter blah /
+ /table
+ }}}
+
+ 1. File upload should support progress notification. Have a look at
webwork-multipart on java.net, it's based on the pell parser but has a progress
API.
+
+ 1. Better error checking for UI tags. The freemarker error message, while
great for freemarker users, look like gibberish. People should not be forced to
learn freemarker. So in such cases, the tags themselves should check the
parameters and report back sane messages, even if that check is duplicated in
the templates
+
+ 1. Defaults should be JSP all the way. People know it and like it, despite
all the limitations. Allow for other view technologies, but don't force people
to learn stuff they don't want to. Learning ww is enough of a pain as it is
+
+ 1. Get rid of the validation framework. it's stupid and pointless, validate
methods are good enough.
+
+ 1. Ditch xwork as a separate project, nobody uses it or cares about it
+
+ 1. Add java5 support to ognl. It's silly that it still doesn't handle enums
(that I know of).
+
+ 1. Clean up documentation. Focus on quality not quantity.
+
== Patrick's issues ==
My concerns aren't as detailed as Bob's, but I would like to see these
general themes promoted by the framework:
@@ -160, +186 @@
1. Address the confusing issue of the validation/workflow lifecycle and
different methods (this is mentioned in more detail above, but it is something
that is problematic). Right now we sort of hack it by making the input method
a special case in webwork-default.xml.
* [jcarreira] +1 : Carlos at G**gle had some good ideas for this...
basically stuff like if your action method is foo() then you'd have
prepareFoo() and validateFoo(), but then I added that the prepare() and
validate() methods should be the defaults that we call for all action methods.
* [crazybob] Interesting idea. Might be overkill (i.e. at that point,
the user should probably create another action class).
+ * [hani] No magic method names. If you want to do that, use annotations
so you have a good chance of IDE support dealing with it. For example
@Validate/@Prepare etc, with parameters to indicate what request you'd like it
involved for, in the case where you need multiples of them
1. Don't encourage lots of interceptor stacks. Ideally the normal user
should never need to deal with them. It is better to have a larger stack that
has optional features that could be turned on through annotations or marker
interfaces than to encourage users to build their own stacks.
* [jcarreira] I think we should have some pre-defined ones for standard
things: view vs. CRUD vs. action - do somthing that's not CRUD. We should
then use annotations to make it where you can declaratively associate a
particular action method with a stereotype which is mapped to an interceptor
stack, etc.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Struts Wiki] Update of RoughSpots by Bob Lee
Who did this edit? It says by Bob Lee but one of the comments is tagged as hani - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=26827messageID=52884#52884 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Struts Wiki] Update of RoughSpots by Bob Lee
Like I said in the update comment, I passed along some comments on behalf of Hani (I also removed dups and clarified a couple). I'm working on refactoring the list. It makes better sense to break the issues down by category, not the person who submitted them. Bob On 4/21/06, Jason Carreira [EMAIL PROTECTED] wrote: Who did this edit? It says by Bob Lee but one of the comments is tagged as hani - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=26827messageID=52884#52884 - 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 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
The comment on the change is:
Responses to Jason's comments.
--
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. ;))
+
+ We have a small number of existing WebWork users compared to the number of
Struts users we'll (hopefully) eventually have. This is a new framework (if
only in name) and a major release. This is our one chance to break
compatibility. We must get it right now, because we will *not* be able to fix
most of these problems later (the cost of breaking existing Struts users will
almost always outweigh the value of the fix).
+
+ We do not need to expose Struts users to XWork; they do not care. At the very
least we should build a thin abstraction layer to isolate users from XWork.
XWork should be an implementation detail not part of the SAF API. We can make
most of the following changes in SAF's abstraction layer and avoid breaking
existing XWork users.
1. Looking up a `ResultConfig` should be a one-liner. Right now we have to:
{{{
ActionConfig config = invocation.getProxy().getConfig();
@@ -14, +18 @@
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?
* [jcarreira] I'm not sure about this... The Action interface is kind of
just a marker interface, but at least it gives us SOMETHING to point users to
+ * [crazybob] I'll buy that. We do need to move the constants out and
encourage users to use static import (Effective Java Item 17).
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`.
@@ -24, +29 @@
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.
* [jcarreira] A new instance per action configuration, right? Not
per-invocation...
+ * [crazybob] Last I tested it was per invocation (I remember because it
surprised me). This is actually a non-issue. We'll create a custom
`ConfigurationProvider` for Struts which won't have this problem.
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).
* [jcarreira] The idea was that people would forget to do
invocation.invoke() and be confused... Easier for users just to implement a
before() method when that's all they need. I agree on the stack traces though.
+ * [crazybob] It's kind of hard to forget to call `invocation.invoke()`;
you have to return something. ;) Interceptors are already an expert feature
anyway.
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 {
@@ -39, +46 @@
}}}
* [jcarreira] These 2 are orthogonal... Getting rid of ThreadLocals is
problematic. I think we'd end up breaking 90% of old WebWork apps if we did,
and it's still not clear that everything could be covered if we did... I like
the idea though, and Patrick and I really wanted to do this out of the gate,
but backwards compatibility with WebWork 1.x at a macro-level made us think
otherwise...
+ * [crazybob] Interceptors need access to the servlet API. They shouldn't
have to call a `ThreadLocal` if we can avoid it and they shouldn't need to
cast. We shouldn't worry about breaking old WebWork apps (see new opening
paragraphs). Let's get it right the first time around because we will not be
able to fix it later.
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.
* [jcarreira] It __is__ well specified... There are some things that the
ActionProxy / ActionInvocation let you do that a merged one doesn't... for
instance easily knowing when you're done :-)
+ * [crazybob] Does specified ==
[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 -- * [plightbo] + 1 again. * [mrdon] This I don't agree with. From a framework developer, I understand the logic, but from a user, it is arrogant. I think we should allow people to extend Struts in ways we haven't imagined, and restricting access like this says, We know more than you and will force you to do it our way. + * [crazybob] I don't think we should make everything final or anything, but I do think we should differentiate between the published API and the implementation through package organization, excluding stuff from the Javadocs, etc. Users can know that we won't change the published API out from under them, but that if they depend on implementation classes, we may break them (reluctantly). It's the polite thing to do, and it frees us up to refactor and improve our implementation. 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. @@ -89, +90 @@ * [jcarreira] We don't want to allow for extension? * [crazybob] Extension through interfaces and methods? Yes. Public/protected fields? Absolutely not! * [mrdon] I dunno, are you planning to make protected getters/setters for every field? I've found protected fields to be invaluable when extending frameworks (again, subscribing to the believe we should let the user do what they want and not artifically restrict them). I do wish you could declare the fields _only_ available to subclasses and not to the whole package. + * [crazybob] Absolutely, methods instead of fields. Methods enable us to hook access if need be, change the underlying implementation, manage thread safety, protect our own code against unexpected conditions/states, etc. Fields are OK within a package, but when it comes to public APIs, better safe than sorry a year from now. 1. Rename `ActionInvocation` to `Invocation` or `Request`. Shorter is better. @@ -170, +172 @@ * [MJ] With JDK 1.5 as a requirement for SAF2-based projects, users may be inclined to take a look at [http://stripes.mc4j.org/confluence/display/stripes/Home Stripes] first. It is compact, it features event-dispatching, built-in validation and conversion, Action and !ActionForm being one entity, and it allows to forgo XML config files by using annotations. The last feature alone is worth sack o'gold. If SAF2 is going to require JDK 1.5, it should allow XML-free configuration, at least for simple use cases. * [plightbo] I use JDK 1.5 as well. I think we really should think about doing this. Non-1.5 options exist (WebWork 2.2 and Struts 1.3), and we're really at a close point where it is no longer unreasonable to require 1.5 (1.6 will have been out for almost 6 months by the time we hit a final release). * [mrdon] I'd like to use Java 5, but use retroweaver to continue to support 1.4. If we keep XML in addition to annotations, that should be very doable. + * [crazybob] Sounds good. We'll also need to handle JDK-1.5 only APIs (concurrency for example). - 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]
[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
[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]
[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 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]
