Don Brown wrote:
I've gone back and forth how and to what level of detail Struts Ti
can/should support Struts Action 1.x applications. When I say Struts
Ti, at this point, I'm referring to WebWork 2.2 since we haven't
imported the code yet. Below is my thoughts that I invite comments on.
Basically, I see three ways to approach Struts Action 1.x (hereby
referred to simply as 1.x) support in Struts Ti: graph 1.x into Struts
Ti, develop tools/libraries to help the two frameworks co-exist, and
simply include the latest release of 1.x with Struts Ti as is.
1. Graph 1.x into Struts Ti - This approach tries to take 1.x code and
restructure it as Ti objects. For example, we'd
- Create a subclass of Configuration to which would expose 1.x
configuration files
- Recode the 1.x chain commands as interceptors or at least an
interceptor that calls a chain
- Develop a custom interceptor to plug in commons validator
- Write a custom ActionInterceptor and ActionProxy to call Struts Actions
- Add a custom ObjectFactory to create 1.x Actions correctly
- Rewrite the taglibs to pull data Ti-style
Advantages: From a users perspective, you'd be (hopefully) run your 1.x
application as is, yet gradually take advantage of Ti features on a per
Action basis.
Disadvantage: A ton of work, and more than likely, there would be gaps
in 1.x features or at a minimum, certain things wouldn't work quite
right, especially for more advanced 1.x applications.
2. Develop tools/libraries to help both frameworks to co-exist better -
First, we'd include the latest release of 1.x with Struts Ti. Then,
we'd create optional extensions to both frameworks that allows them to
share information. For example, we'd write:
- A Ti interceptor that would make available the Struts message
resource bundles to Ti Actions and pages
- A Commons Validator interceptor to allow Ti Actions to re-use
validation configuration files
- An Ant task that converts a Struts configuration file into a Ti
configuration file, logging where certain features don't quite match up
- A way to use Dynabeans with Ti ModelDriven Actions
- A tiles Result type to allow Ti apps to use Tiles
Advantages: We don't pretend to run 1.x apps directly on Ti, yet by
providing 1.x jars, we can provide 100% backwards compatibility with
1.x. Legacy 1.x apps can start to use Ti gradually, yet not be required
to duplicate information. Should take much less time the option #1.
Disadvantages: The collection of tools would require additional
configuration to use.
3. Only include the latest release of 1.x - In this case, Ti doesn't do
anything to help migration outside of documentation. We could still run
1.x apps, but assume apps using Ti will be rewritten anyways
Advantages: Can run 1.x apps. Easy. 1.x apps might not even be
planning to migrate in pieces anyways.
Disadvantages: No support for gradual 1.x migration.
---
Of the three, I'm in favor of the middle one. I've tried different
methods of graphing the code together, but while it would be possible to
run simple 1.x apps, any more complicated ones, the very ones that need
migration assistance, would find all sorts of hidden problems.
Furthermore, it still require devs to change their app to at least use
the new Servlet.
I think including 1.x with Ti is important because it shows we are
committed to 1.x support and Struts is still a one-stop-shop. This also
allows us to change things like customize the chain to aid the
co-existence support unseen to the user. 1.x is getting quite flexible
with commons chain so we could take advantage of that here.
Finally, I do think migration tools are important. The primary
migration use case I imagine is a user with a 1.x application that might
need a new module or section. Instead of writing it with 1.x, they
might want to try Ti, so they'd add the Ti filter and code up the
section as a Ti package with its own namespace. This user wouldn't want
to duplicate all their message bundles or perhaps even their validation
configuration.
One of the strongest features Ti has going for it is the possibility for
a smooth migration for 1.x applications. How can we best provide this
for the 1.x user?
Don
I have to ask if the goal behind 1 through 3 is the right goal... In
other words, should the goal be
1 - allow a Struts 1.x app to run unchanged on Ti
2 - allow a Struts 1.x app to run unchanged on Ti, w/ some caveats
3 - allow a Struts 1.x app to run on Ti, with only minor changes
4 - allow a Struts 1.x app to run on Ti, with a well defined set of
migration changes, possibly supported by automated tools
I thought there was a general leaning towards something more like 4,
with a corresponding minimization of code in Ti solely for the sake of
1.x compatibility. IMHO the right balance would be somewhere between 3
and 4; 1 and 2 impose a higher burden on Ti than should be expected or
required of a 'Struts 2.0'.
I know, that totally subverts the discussion, but I think deciding this
issue informs that discussion. Unless I missed something that answers
this issue already :-)
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
