New Topic - API

[Wes Wannemacher <we...@wantii.com>]

I am carrying the Guice thread over here because I'm getting lost a bit...

Don, you bring up quite a few good points and I don't want to come off
as argumentative, but I don't necessarily agree with all of them...
This thread can hopefully talk to the "API Problem"

You brought up a point about how you have been using webwork 2.1.7
(possibly a forked version of it to support your forked
picocontainer?). I have a few struts apps, but my apps probably more
exemplify typical struts2-user usage because they do not have near as
many deployments as most Atlassian products. The main difference is
that I have never had any problems upgrading from 2.0.x to 2.1.x or
2.1.x to 2.1.y. The main reason I can think of is that I really don't
mess with internals from the web-app. My web-apps are typically
Actions, Interceptors, JSPs and some Freemarker. The lack of API that
you pointed to as the problem that keeps you stuck to specific
versions in your products, is the problem that you've overridden
internals only to see those internals change? I am not going to
disagree that we don't maintain an API internally, but the basic
objects (Actions, Interceptors, Results) have all remained static as
far back as I've used Struts2. If we were to come up with an API,
which objects/services internally are the ones that have caused you
guys the biggest problems? If a cleaner, more stable API is something
that would benefit you guys, I don't see a problem with making that a
goal... What would concern me, though, is that when you have knowledge
of the internals, you would always be tempted to override with your
own implementations if you know it would be easier. To use the ol' car
analogy... I know nothing of how my car runs (well, I have the basic
knowledge, but you get the picture). It gets me to and from work and
that is how I use it. My younger brother who runs a body shop is
constantly telling me the things I should do to squeeze out an extra
MPG or gain a few HP. My response is usually to ask him how his Camaro
is doing... The truth is that his Camaro is sitting in his garage with
about 5 half-finished projects strewn about. The example may not be
clear, but what I am trying to get to is that there are really two
APIs within the "struts 2 project." The main API is what I would say
is visible to users: Actions, Interceptors, Results and Tag Templates.
>From those objects, I believe our users can solve 95% of their
problems. The other 5% I would consider the "advanced" problems that
can be solved with custom implementations of internal objects like the
ActionMapper or ConfigurationProvider.

If you agree that there are two psuedo-APIs, and that the basic one
(Actions, Interceptors, Results, etc.) is stable, then that would mean
the lack of API problem really falls into the advanced API area. I
would agree that we have problems here because we make changes to both
XWork and Struts Core all the time to support new features or handle
bugs. The solution, though, would be more complex because I like
thinking that I have the flexibility to make changes to some of those
interfaces/classes in the "advanced" API. I think the first step might
be coming up with a list of objects that we consider the "basic" API.
Then, coming up with an "advanced" or "internal" API and deciding on a
support level for those objects. The current state of things, I think
is the fault of too much "good design." I know that whenever I've made
changes, I've tried to come up with an interface to describe the
intended functionality and provided an implementation that provided
the functionality (typical service/implementation separation). The
problem is that we've done that *everywhere*!! So, people working on
advanced products like you have at Atlassian have the ability to
override/reimplement even obscure parts of Struts.

I could be wrong on all counts and even looking at it incorrectly, so
if you have a better description or perspective on this, feel free to
slam me :)

-Wes

-- 
Wes Wannemacher

Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org