[Struts Wiki] Update of RoughSpots by plightbo
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 plightbo: http://wiki.apache.org/struts/RoughSpots -- [phil] This is, depending on what you want, fairly easy to really complicated. You can easily register a new FreemarkerExceptionHandler in components.template.FreemarkerTemplateEngine to limit the stacktraces. But it will still be gibberish if you don't know what happens (eg. Error on line 43, column 13 in template/simple/select.ftl - stack.findString(parameters.listValue) is undefined. It cannot be assigned to itemValue] - that hardly tells you you specified a non-existant method for listValue in your select box). Solution: we should do more checking in the components instead before rendering. 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 - [tm_jee] Hmm... are you suggesting that we should support JSP template as well? WebWork currently does support JSP view, just theat there's no theme/templates written in JSP due to JSP not being able to be packaged and displayed from a jar file in the classpath. + * [tm_jee] Hmm... are you suggesting that we should support JSP template as well? WebWork currently does support JSP view, just theat there's no theme/templates written in JSP due to JSP not being able to be packaged and displayed from a jar file in the classpath. + * [plightbo] Agreed - examples, default results, etc should be JSP. However, we need to keep UI tags in a template language so they can be used in all view technologies. Right now that is FreeMarker, though if we can find a template language that is more like JSP (say, without the scripplets), I would like to switch to that. 1. Get rid of the validation framework. it's stupid and pointless, validate methods are good enough. * [jcarreira] -1 I take offense at this... It's neither stupid NOR pointless, and we use it extensively. It's the best validation framework I've seen out there, and NO, validate methods are NOT enough. For instance, we define reusable validations for our domain models and use them for both the web front end as well as web services and batch imports. * [tmjee] -1 If possible please don't do so. I use it and like it. I guess (for me at least), sometimes for simple validation it is nice to be able to just describe it (using xml or annotation). Plus the validation could be tied to DWR for ajax support. Being able to write custom validator is really cool. Please reconsider this. :-) * [frankz] -1 as well. If you had said the validation framework could stand to be enhanced and expanded on a bit, I'd agree, but I definitely think it should be there, not pointless or stupid at all. Declarative validation is a fantastic approach, especially with validator being a separate Commons component. For instance, we are working on a project at work that is going to use Validator and the CoR implementation in JWP as the basis for a rules engine... I put together a proof of concept showing how we could use the exact same validations in the web front-end via AJAX calls as in the Web Service interface for other systems to call on. Being able to write those validations in XML without having to write actual code was a great thing. * [crazybob] I think sharing validations between AJAX and Java more than justifies the framework. I would like to see us replace most if not all of the XML with annotations. - * [rainerh] -1 on removing the valdation framework. This is one of the best, if not the best validation framework I've seen so far. + * [rainerh] -1 on removing the validation framework. This is one of the best, if not the best validation framework I've seen so far. 1. Ditch xwork as a separate project, nobody uses it or cares about it * [jcarreira] You're kidding, right? We've discussed this already @@ -243, +244 @@ * [crazybob] What needs to be done here? We wrote a type converter for enums. Is there more to it? * [rainerh] +1 as well * [tm_jee] +1 + * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). 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. :-) + * [plightbo] The reference docs are great, but we failed terribly on the
[Struts Wiki] Update of RoughSpots by plightbo
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 plightbo:
http://wiki.apache.org/struts/RoughSpots
--
}
}}}
+ * [plightbo] The overall
RuntimeConfiguration/ConfigurationManager/ConfigurationProvider/Configuration
stuff is very confusing. As long as we abstract it away, I don't care if it
stays or goes. One thing I would note is that the APIs should try to pass
around a fully populated ActionConfig where possible (currently some APIs
simply take a String namespace and String actionName - leaving out the method
name).
+
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).
+ * [plightbo] Related to this, I would encourage us to try to find a
solution (using Bob's mix-in suggestion below, or possibly just taking
advantage of the value stack) that would make ActionSupport much simpler. This
would encourage using POJOs more.
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.
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.
+ * [plightbo] + 1 again.
+
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.
+
+ * [plightbo] I don't really care. This ties more in to the next item...
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.
+ * [plightbo] Agreed, by abstracting most configuration out, we can
control the lifecycle. I think the lifecycle should be either once per
interceptor or once per invocation. Currently the implementation is too
cumbersome (once per unique action configuration).
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.
+ * [plightbo] Big +1.
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 {
@@ -47, +57 @@
* [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
