Hi,
This helpful posting
http://herebebeasties.com/2007-03-01/jsp-and-wicket-sitting-in-a-tree
is often cited as a guide whenever anyone asks about migrating from a
JSP-based web application to an equivalent JSP-free Wicket application.
But...
the posting itself is >18 months old and describes work with a
pre-release version of 1.3. Wicket 1.3.5 is out as of Oct 2008, with
1.4-M4 just around the corner. I also see that the posting clearly
states that this is not a boxed solution, or particularly
well-supported, buyer beware and all that. Fair enough. So it is with
low expectations, but with hope for an answer nonetheless :-), that I
ask the question
"is there a newer/better solution available now for supporting JSPs in
Wicket 1.3 or the upcoming Wicket 1.4, one which is
cleaner/easier/addresses gotchas mentioned here. Or is the technique
referenced here still best practice?"
My guess is that Alistair's technique is still best practice, based on
newer postings I see on this list, but I'd like to ask the question
outright, just in case I've missed something.
************************************************
Some thoughts about migrating a JSP based application to Wicket:
I know that in the long run, one would choose Wicket so as to be JSP
free. And certainly there are issues with JSP development as we all
know. I would almost say that to some developers, JSPs are the high
fructose corn syrup of the web development world, very sweet (in some
ways), but bad for you in the long haul :-)
Thing is, going JSP free is a transition if you have a legacy app.
There's where you are now, there's where you want to be, and a migration
path which involves some period of time where one would need to support
both JSP and Wicket pages in the same app.
In the case of our current project, we have some large Struts 1.x based
applications with many JSPs (nearly 900._ Some JSPs are simple, just
divs filled in by Ajax components, but other JSPs are complex and use
scriptlets, inline javascript, 3rd party and custom tags. There's more
work in recoding these JSPS (extracting the HTML template skeleton from
the JSPs, recoding the core/3rd party/custom tags from taglibs in Java,
replacing our simple use of Tiles 1 for page composition again with
Java, refactoring those scriptlets, calling out to a custom 3rd party
Ajax toolkit...etc. etc.).
The point is, we cannot simply stop, migrate the whole app over to
Wicket and bring it back up - a gradual migration is necessary, doing
JSP migration in bitesize chunks.
My colleague Rich Allen has been posting various questions to the this
list as we evaluate our replacement for Struts, and after looking at
Wicket some, I understand why he likes Wicket a lot. It is a clean
division of application from presentation, and for a new development
effort, that would be really cool. But we have a large legacy
application to support - that's just the way it is. So a
straightforward and incremental migration path from existing JSPs to
Wicket is something that would be critical for our team.
Costs to consider: We have a lot of developers, some experience and some
newbies, and we have a large code base. Replacing JSPs is not an
inexpensive proposition, and we need to do it in small pieces, and
clearly spell out the approach for our team. Indeed one argument for
choosing something like Spring MVC to replace Struts is that Spring MVC
is another MVC framework that, for better or worse (and I know the
community on this list would say "for worse" :-) , preserve our
investment in JSPs.
Again, if this were a new development, starting with a clean slate, the
decision inputs are different. But when you have substantial investment
in JSPs, a valid question is "do we want to pay the cost of retooling
now vs. later or not at all? Can we simply be disciplined in our use of
JSPs, but continue to use them nonetheless, because the cost of
retooling is too high?"
By choosing Wicket, we would be saying "enough with JSPs", but we have
to have a cost effective way of incrementally achieving that goal, where
cost is measured in how easy it is to retrain our developers and to
migrate in small, manageable pieces.
Any advice/anecdotes are gratefully welcomed.
Thanks in advance.
Susan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
