> -----Original Message-----
> From: Don Brown [mailto:[EMAIL PROTECTED]
> Sent: 05 December 2005 05:39
> To: Struts Developers List
> Subject: Re: [ti] Struts Action 1.x migration tools
> 
> 
> I'd classify all those goals as those of approach 1, which is 
> building 
> 1.x support right in Ti.  What I'm coming to the conclusion 
> of is that 
> it would be a lot of work, be prone to surprise errors, and 
> ultimately 
> futile.  If my 1.x app is running fine, what would I gain by 
> trying to 
> run it on a platform (Ti) which is buggy and where my fancy Struts 
> extensions (custom RequestProcessor, tricks using internal 
> Struts APIs, 
> etc) won't work or only work sometimes.
> 
> My approach #2, to include 1.x jars and develop co-existing 
> tools, lets 
> someone run a 1.x app "on" Struts Ti completely unchanged and 
> with 100% 
> functionality, 1.x quirks and all.  I think a user would mainly be 
> interested in that, and perhaps building new segments with Ti as the 
> opportunity arose.
> 
> But perhaps that is a faulty assumption.  What do the rest of 
> you think?
> 
> Don

I see it falling in the second choice, approach #2. I think 
users may like this opinion, because

1) It allows them to "suck it and see" if Struts Ti works for them.
2) It would garner support from key decision makers.
3) There is some kind of transfer of application knowledge to the
next guy or doll who has to maintain /upgrade the Struts apps.


> 
> Laurie Harper wrote:
> <snip />
> > 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'.
> > 
==////==


--
Peter Pilgrim :: J2EE Software Development
Operations/IT - Credit Suisse First Boston, 
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497

==============================================================================
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.csfb.com/legal_terms/disclaimer_external_email.shtml

==============================================================================


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to