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 FrankZammetti:
http://wiki.apache.org/struts/RoughSpots
--
* [plightbo] By running our interceptors and other objects through the
same factories and lifecycle managers that the action classes go through, this
should be a non issue.
* [mrdon] This I'd like to see. I've found myself using these objects so
often in wierd little places, I'd be loath to remove them unless we could prove
100% that their information can be retrieved elsewhere.
* [jcarreira] +1 to Patrick's point... we may need to introduce some more
advanced *Aware interfaces, though, to give people access to the guts if they
really want it.
+ * [frankz] !ActionContext being !ThreadLocal was one of the first "cool"
things I noticed about WW. I'd hate to see that change. The only thing I can
think of that would make me agree to change that is that I think we may find
developers using it in "inappropriate" ways, i.e., an Action calls a business
delegate and the delegate uses !ActionContext. My bet is most people would
agree it should be a "best practice" to not do that. Still, it's cool that you
can!
1. Is `ValidationAware` a good name? Perhaps `Errors` or `ErrorList` would
be a better name.
@@ -117, +118 @@
* [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."
* [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 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.
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.
@@ -155, +157 @@
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
* [jcarreira] Well, that's a relatively simple usecase, and I think it IS
supported... at least we use it at work?
+ * [frankz] I would ask what "real AJAX work" means, because that would
really determine what path makes sense.
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: {{{
@@ -165, +168 @@
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.
* [jcarreira] We've implemented this at work with WebWork fileupload +
DWR + a class that looks at the file as it's uploading to see how big it is on
disk
+ * [frankz] Just an opinion, but this seems to me too specific a use case
for a framework to encapsulate. I think having an example showing how to do
it, perhaps what jcarreira has done at work, would be great, but I for one
wouldn't like the framework offering this out of the box... I think it is
possible for a framework to be able to do TOO much!
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
@@ -173, +177 @@
1. Get rid of the validation framework. i