Patrick Lightbody wrote:
Don,
I think you're right: option #2 sounds the most appealing.
Though, I think we won't know for sure until we get our hands on things
and try it out :) I believe with Ted working on the MailReader
application, we might have a chance to put this hypothesis to the test,
right?
Absolutely, and I have been working towards those ends the last few
days. Taking a pause, I thought I'd gather some intel on what other
folks think when we say "migration" and what types of support would be
valuable. I'm hoping to get something going by ApacheCon so we can
better discuss a timetable to our first release (hopefully soon).
Don
Patrick
On Dec 4, 2005, at 6:29 PM, 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
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
