struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <mr...@twdata.org>
Subject Re: [ti] Struts Action 1.x migration tools
Date Mon, 05 Dec 2005 05:44:12 GMT
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: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
> 


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


Mime
View raw message