Hello all,
My name is Brian Dittmer. I'm a third year Computer Science and
Engineering student at The Ohio State University and plan on applying
for the Google Summer of Code project and work on the Struts Ti
project. I've already talked with Patrick about some of my ideas but he
recommended I hop on the list and see what you guys think. After taking
a look at the rough spots page on the wiki
(http://wiki.apache.org/struts/RoughSpots) I've narrowed down my
possible contributions to a few different areas:
Under Bob's concerns
-----------------------
-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...
-Add better support for file uploads.
-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
-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:
Under Tim's concerns
----------------------
-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
<http://wiki.apache.org/struts/ActionContext>.getSession(). Actions
should in general have a type-safe and transparent way to do this, e.g.
by subclassing ActionContext
<http://wiki.apache.org/struts/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.
There has also been talk of working a conversion kit from Struts 1.x
apps to Struts Ti. That's something else I'd be interested in working
on, however my general Struts 1.x knowledge is limited (I have been
working with WebWork since v1 though).
If anyone has any other ideas or comments please share them. Let me
know what everybody thinks and I definitely look forward to working with
you guys.
Regards,
Brian
P.S.
The deadline for the application is Monday so sharing ideas/thoughts
sooner rather than later is preferred ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
