Chan, Jim wrote the following on 1/10/2006 5:35 PM:
I am refactoring my company's JSP website because the code uses only JSP to
control navigation. You can imagine its pretty ugly. Anyway, I decided to
use JSF and possibly move to Shale once I've gained a handle on the
framework. I successfully deployed some of the pages using MyFaces because
it has a simple integration with Tiles.
Anyone who tried to refactor JSP to JSF will know that it takes some work to
adapt the existing html/JSP code to utilize the JSF tags. Because I'm under
time constraints, I've really only used JSF tags for controls that need to
be bound the backing beans. All other html/JSP code was wrapped with
everybody's favorite tag - <f:verbatim>. There are verbatim tags everywhere
- yikes. I am hoping I can refactor them out at some later time, but my
biggest dream is to have the JSF specification at the container level so
non-JSF text do not have to be buffered at all.
Anyway, I wanted to know if:
- I am taking a good approach to refactoring the existing webapp?
- Will JSF evolve to a point where <f:verbatim> tag is not needed?
Actually you bring up one of the reasons I'm not in love JSF at the
moment. I know most people like the idea of using pre-built or custom
renderers and get all googly eyed over the nice things you can get
out-of-the-box from MyFaces or Oracle ADF, but I guess I'm still
old-school and like the control of building the front end how I want
with simple JSTL and html. From my brief time with JSF I felt sort of
constrained having to use the DataTable (I think that's what it was
called:) to iterate over stuff for display purposes etc. Not saying the
concept of renderers is bad at all and I guess a set of common controls
is pretty cool. I just know from experience that pre-built stuff always
ends up having to be tweaked to meet some crazy business requirement I
end up having to deal with. At least when I'm working with straight html
(and the annoying dhtml stuff) I can create everything how I want.
By the way, when you say the site 'only uses JSP' do you mean no Struts
or other framework is involved? In other words just JSP submitting to a
servlet and then redirecting/forwarding to another JSP?
I'm more comfortable with Struts so of course I'd feel better taking
that approach. You could even clean up all your navigation issues using
Struts and reuse a lot of your old code - including the front end stuff.
This way you can start small and then implement more and more struts
pieces as you see fit. For example I'm assuming you are just doing
typical request.getParameter stuff in your Servlets. Well you could
still use Struts to go to an Action(a Servlet) and basically put your
same exact old Servlet code in there. You could in theory clean up all
your navigation woes without having to change that much of your existing
code. This actually goes again to something that I do like about Struts
- it is not too far removed from the ServletAPI. You can still mess
around with typical Request and Session stuff in your Action classes
just like you could in any other Servlet (others of course would see
this as a weakness - ie difficult to unit test Actions etc and they have
valid points there). JSF, at least from what I've seen, is much further
removed from the basic ServletAPI so in your case under time constraints
I'm thinking you'd have more work to do migrating it to JSF. I guess a
lot also depends on how much existing code you want to reuse and your
existing architecture. If you plan to rewrite a lot of stuff anyway, and
you are comfortable with JSF, then go for it.
If you do go the JSF route, I'd appreciate knowing how your experience
migrating the app went.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
