Hi Susan, I'm in the same situation. With the only difference I have few months advance. And I'd say the project works very good for now. Currently some of the pages are backed by Wicket and the rest are still JSP ones and there is no difference from a customer point of view. None of the Wicket pages does include any JSP chunks. They are made entirely in the Wicket way. So we don't use AlMaw's solution at all. At the beginning it was slow but now we started to reuse more and more components and it's getting faster to migrate the next JSP page.
good luck martin-g On Mon, 2008-11-03 at 09:31 -0500, Susan Liebeskind wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
