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?
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]
