On 1/16/06, Jason Long <[EMAIL PROTECTED]> wrote:
>
> I would like to migrate my application to JSF.  I am using Struts 1.2.7,
> Tiles, and XML Syntax JSPs.  There are 150+ pages that use struts tags.  I
> am using a custom request processor that extends TilesRequestProcessor and
> is modification of com.sourcebeat.strutslive.common.PojoRequestProcessor.
>
> Ultimately I would like to replace Struts completely in favor of JSF.
>
> 1.  Can I just write and XSLT transform and run it on all of my pages to
> switch to Struts-Faces and JSF?
> 2.  Is there a tool for this already?
> 3.  Will this work with the custom request processor I have?
>
> I would like to do the upgrade in steps.
>         1.  XSLT to upgrade pages
>         2.  Test to make sure this is done properly.
>         3.  Convert Action one by one.
>         4.  Test action replacements.
>         5.  Convert from Tiles and use Facelets and JBoss Seam.
>
> I would like to know how smoothly step 1 & 2 should go so I can determine
> if
> this is the proper time to begin this.


Although an XSLT transformation sounds like an easy way to do this, it's not
quite that simple ... some of the semantic meaning of a page with Struts
HTML tags is buried in the corresponding struts-config.xml file.

Consider, for example, how you'd need to map an <html:text> tag into a
corresponding <h:inputText> component.  Presumably, what you would want to
do is emit a value binding expression for the "value" property, which would
map to the corresponding backing bean.  But how do you know what the bean
name is?  You could infer it by going up to the <html:form> tag, looking up
the action it points at, and get the form bean name from there (and, along
the way, make sure that you create a managed bean definition for all the
form beans) ... but it doesn't seem feasible to do all of this with XSLT.
It seems more like a task for a tool.  Even there, this only gets you as far
as binding to the string-valued properties of your form beans.  An ideal
tool would also migrate those properties to the correct native data types --
but that might be a later step in the conversion process.

I don't know of any such tools at the moment, but it would be an interesting
project to attempt to create one.

Thank you for your time,
>
> Jason Long


Craig

Reply via email to