My project team has decided we will go with Wicket to replace our aging
Struts 1.x infrastructure, so we're starting to learn to use Wicket in
earnest. The next question we face is whether to use Wicket 1.3 or
Wicket 1.4.
Since Wicket 1.4 is at RC1, and there is substantial use of generics in
Wicket 1.4, our belief is that it makes sense for use to start out using
Wicket 1.4RC1. The logic is that since the 1.4 release is at RC1,
things are pretty stable and methods/interfaces are not going to change
in any significant way.
Is that a fair assumption to make? For those experienced Wicket
developers on the list, would you recommend starting brand new
development now with Wicket 1.4RC1 or fall back to Wicket 1.3.5?
----
My problem is that I'm trying to work through the examples for Wicket in
Action (version 0.9, available from
http://code.google.com/p/wicketinaction/downloads/list) with my trusty
hardcopy of the book in hand, and translate from what I am reading about
in Wicket 1.3.x to the new genericized approach built into Wicket 1.4.
I was hoping that the migration guide at the URL
http://cwiki.apache.org/WICKET/migrate-14.html but unfortunately, the
information I need to get the Wicket in Action 0.9 example code up and
running is not in that guide.
Alas, a March posting on the user list regarding Wicket in Action's
support for 1.4 which suggested that one should be able to ignore the
compiler warnings about generics didn't play out -- I'm getting errors,
not warnings I can ignore.
The change log for 1.4RC1 consists of a links to JIRA tickets, which
requires some slogging through many detailed bug reports. When one is is
new to a software technology, it's hard to see the forest for the trees
sometimes, and I don't think I have enough experience in Wicket to be
able to make much sense of a trudge through those bug reports...just yet.
I did locate an old news posting here
(http://wicket.apache.org/wicket-14-m3-news.html) which covered the
switchover to a non-genericized Component class. This news item told me
how to solve the errors I was seeing with Component.[get|set]Model et.
al, in the Wicket in Action example code, by replacing these calls with
Component.[get|set]DefaultModel. That's getting me further (and I'm
also happy to contribute my diffs back to the authors if they are
interested). Perhaps that snippet can be added to the migration guide now?
But the overall sparseness of the 1.3-1.4 migration guide as of this
writing, makes me suspicious that there are perhaps some subtleties in
the migration process that I, as a newbie, will miss. Perhaps there are
changes I should be making to this example code, even though things are
nearly compiling, but those changes/best practices are simply are not
yet documented. These are the kinds of issues that can come back to
haunt you if you start development with a less-than final release :-(
So perhaps we should be sticking with Wicket 1.3 because the examples
and documentation is more readily available for a pre-genericized
Wicket? And also, because there is no date for when the 1.4 final
release will be available, and things still could change?
Or use Wicket 1.4RC1 and be optimistic that we're close enough to the
final product, even though the documentation isn't out there yet to
support this release, and it will be slower going at first?
Any advice for people just starting out?
Thanks.
Susan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
