According to the roadmap (or at least the one in my head :)), Struts
Action 2 will be implemented in two phases:
Phase 1 - Rename WebWork 2 code, implement Struts 1.x support, minor changes
Phase 2 - Annotations, Zero XML configuration, new easy development modes, etc
The goal of Phase 1 is to get a release out quickly, in the hands of
developers, and help them migrate their code quickly. This probably
translates into Struts Action 2.0.x. Phase 2 I see stretching out
into Struts Action 2.x or even 3.x, as it is where we bring in truely
innovative features that make development easier.
That said, I'm with Jason that we need to ensure these first changes
for Phase 1 aren't too drastic from an end user perspective, but that
doesn't mean we shouldn't try to move around and clean up the API. By
minor changes, I mean from an end user perspective, not from an
architecture perspective, so drastic API changes that have little
impact on today's WebWork 2 applications would fit in this category.
I see this new API as a proposal, meant to feed discussion and not to
be voted on as a whole today. Therefore, let us have a solid
discussion on the particulars of the API, and avoid throwing out the
abused '-1' votes, as those are meant for official votes and carry an
obstructive, negative connotation.
Now for my API comments:
Overall - I like the clean feel of the API and the concious decisions
to minimize the number of interfaces the user needs to be aware of.
It seems to have a minimal conceptual surface area [1] that the Wicket
folks talk about.
o.a.s.action2 - I'd like to hear the design reasoning behind the
Messages changes. I liked the use of Maps in the XWork design as it
made it easier to work with. On the other hand, encapsulating message
operations in the Messages object does reduce the number of
message-handling methods required. Perhaps Messages could extend Map?
Also, I agree we should continue to support plain Messages, as not
all apps need to be localized.
I'm not sure I understand the separation of Validatable and
ErrorAware. In particular, Validatable only has a validate() method
that returns void. Is there really a case you want to validate, but
not have errors sent anywhere? I think of the use case of plugging in
a different validation engine like commons-validator, and this
separation makes it harder. Why not return Messages?
o.a.s.action2.attribute - This is again a feature I'd like to hear the
design reasonings of. I liked the previous use of Maps as they were
easy to test and pass around. Maps can also be extended to provide
the automatic synchonrization feature talked about easily.
o.a.s.action2.servlet - I like how the servlet-related classes are
contained in their own package. This distinction is very important as
I plan to be personally using Action 2 mostly for Portlets.
o.a.s.action2.spi - Again, I love this separation - move all the
framework classes the user rarely deals with out into its own package.
I like making ValueStack a first class interface, and the Interceptor
changes seem reasonable. I am somewhat concerned about the Request
interface though. While the goal of putting everything you need for a
request in one object, it seems to be combining too many roles. For
one, it has servlet object retrieval methods in there that should be
separated, and I'm not sure if it should be handing the execution of
actions and interceptors as well. If the goal is to turn this into a
Tapestry-like Visitor object which holds all the request state, we
should separate out the servlet getters into their own interface to be
combined by the user.
The more I think about this Request object, I can't help but notice it
pushes the roles usually handled by the Action into it. For example,
the Request now holds Messages whereas before we had the
ValidationAware interface for the Action. I'm wondering if it might
be a better plan to decorate a central Request object with these types
of interfaces rather than cluttering the Action. It makes the Action
only really usable if you extend ActionSupport, otherwise you have a
ton of methods to implement, and concievably, you'd want to be sharing
these methods with all your actions anyways.
Anyways, I'm glad to have something concrete we can discuss and toss
darts at. Thanks Bob and Patrick for taking the time to put this
together and I look forward to the feedback.
Don
[1] http://wicket.sourceforge.net/Vision.html
On 5/4/06, Jason Carreira <[EMAIL PROTECTED]> wrote:
Ok, I remember us saying we wanted to clean up a lot of things that weren't
right in the old codebase, but why are we changing everything just for the sake
of change?
Instead of having a pretty good sized community who can easily switch over with
a few tweaks (the WebWork community) and a huge community to write a
compatibility layer and migration docs for, we'll have almost no-one who can
try out the code on a real-world project for a considerable time. It took my
project a couple of weeks of tracking down little things to go from the 2.1.x
codebase to 2.2, and that was all in WebWork, without huge API changes!
Plus, I don't see a lot of these changes as being better, just different. The
messages, for instances. Messages in WebWork work really well... So why are we
changing them? Why the requirement to use message keys? At work we only use
message keys, but that's not the case everywhere. Sometimes it's quicker and
easier to just throw some text in there for the message.
Anyway, needless to say I'm not too excited to see these changes... It will
make the timetable for converting my project over look more like 6 months
instead of 1 month since we don't have time to make this many changes.
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=29317&messageID=56953#56953
---------------------------------------------------------------------
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]
