[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 -- 1. How does WW help the user with state management? As far as I can tell, if I want to keep a 'user' object around I have to interact with the map returned by ActionContext.getSession(). Actions should in general have a type-safe and transparent way to do this, e.g. by subclassing ActionContext and providing getUser()/setUser() which store the user in session. This allows for re-working of the storage strategy (e.g. write a cookie and lookup the user each time) without affecting actions. - * [crazybob] I prefer an injection-based approach. You can use the `ScopeInterceptor` which pulls an object of the session and passed it to your action. Or you can use Spring. + * [crazybob] I prefer an injection-based approach. You can use the `ScopeInterceptor` to pull an object off the session and pass it to your action. Or you can use Spring to inject session-scoped objects into your action (though I would avoid Spring personally). 1. In tandem with the previous point, since Actions are already stateful, it'd be nice to have the ActionContext injected into the Action. One benefit is when a newbie developer needs it, the linkage is obvious (they don't have to a priori know about the ActionContext, they're being handed in it on a platter). If the developer can subclass ActionContext, it would also encourage them to implement a base action which accepts the context inject and leveraging the fact that JDK 1.5 allows co-variant returns, also write a getContext() method that returns the down-casted type; they wouldn't have to do ((MyActionContext) ActionContext.getContext()).getUser() for example, just getContext().getUser(). * [frankz] This might well address the issue of !ActionContext being !ThreadLocal. If it was injected, it wouldn't need to be !ThreadLocal to get the same basic effect, and maybe more importantly, it wouldn't automatically be available to helper classes as it is as a !ThreadLocal. That would address my concern about inappropriate usage of !ActionContext. @@ -313, +313 @@ * [martinc] The big issue with the JDK version is app servers. This comes in two parts. First is whether all of the major app server vendors have products available that support the desired SDK version. I believe we're OK in that regard with JDK 1.5. The bigger issue is customer acceptance. Enterprise customers, especially, tend to standardise on their app server, and they are not quick to upgrade. Unless the application vendor has a great deal of influence over the customer's infrastructure, the vendor has to live with whatever app server version is in use at the customer site. It is rare, then, that the application vendor can dictate the JDK version. On the other hand, the customer usually couldn't care less what version of Struts the application was built with. * [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 drive design decisions. + * [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.
[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
The comment on the change is:
fixed comment formatting so numbers stay intact.
--
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
+ * [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
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`.
@@ -23, +23 @@
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...
+ * [jcarreira] A new instance per action configuration, right? Not
per-invocation...
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.
+ * [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.
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 {
@@ -38, +38 @@
}
}}}
- [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...
+ * [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...
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 :-)
+ * [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 :-)
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?
- [jcarreira] See the TokenSessionInterceptor and the stuff it does to
re-render the same result if you post the form more than once. That was the
reason for the complexity in finding the result to execute. It's a nice
feature, but I agree it makes the code harder to read.
+ * [jcarreira] See the TokenSessionInterceptor and the stuff it does to
re-render the same result if you post the form more than once. That was the
reason for the complexity in finding the result to execute. It's a nice
feature, but I agree it makes the code harder to read.
1. `ActionInvocation.invokeActionOnly()`. Does this need to be public?
Sounds dangerous.
- [jcarreira] Not sure... This may be part of the same TokenSession stuff...
can't remember
[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]
