Well, I'm not a core committer , so dont have enough vision to talk about
the internal effects of the change, but as a user from the pre-1 versions
of wicket till now(1.2.5), here are some humble opinions:
pros:
* free to call any method in the constructor like getpage(), urlfor(),
etc.
* access to markup attributes in constructor as opposed to render time
I dont know why, but I've never felt any need for these two. Maybe I'm used
to passing dependencies to child components, instead of letting them access
the parent page. But these two have never been a problem for me .
* fail at component instantiation time rather then render time if there is a
hierarchy<->java mismatch - so you get a java line-precise error as opposed
to our error webpage
In 80% of my usecases, I use the component as soon as I instantiate it, so
this is really considered a minor improvement in my domain.
cons:
* code explosion
2.0: http://papernapkin.org/pastebin/view/4900
1.3: http://papernapkin.org/pastebin/view/4908
Now, I already preferred the add() method way over the new(parent,...)
way, just because of clarity and maybe because I'm used to it. But this
example is really frightening me. It's got way too complicated instead of
simpler, and clean readable code is really REALLY important. Consider a
newbie, looking for the first time at these two codes. Which one would be
easier for him to understand ?
* hacks necessary for nontrivial components
GridView.populate()
http://papernapkin.org/pastebin/view/4902
notice fake1,fake2 parents necessary for child item instantiation and
which are later
* more limited in how the hierarchy is created since it MUST be created
top-down
* replacing components is less explicit.
1.3: a.replaceWith(new B());
2.0: new B(a.getParent(), a.getId());
again, code is getting uglier :-(
Some other thoughts :
* Converting 1.x code to 2.x is really really hard this way. If it would've
been easier, I guess many users (including myself) would've started to use
2.x codebase right now. The amount of feedback and test you would get by
that is enormous. But, considering how much code I have working with 1.x and
how much pain it would have migrating to 2, I've left it out for my next
project.
* One of the best features I'm hoping for in 2.x is the Java 5 support, like
covariant return types, Generics and stuff. Surely they would make my page's
much cleaner and readable. But wicked is way too slow in adopting jdk5, and
I see the problem is the enormous constructor change getting in its way. I
cant estimate the amount of man-hour work needed to finish 2, but maybe a
good 6 months is needed. Now that everybody is talking about the new
features in Java 7, we still have to work with Java 1.4 style of code. Or
maybe when 7 is out, we could finally use 5 ? ;-)
As a user I'm very happy with the current features and possibilities in
wicket, and am only waiting for the changes(stateless forms, page cache, ...
) in 1.3. My main dissatisfaction is some ugly code I'm forced to write
which can be easily improved. Like I'm really sick of the casting and the
"always null" parameter in :
myObject = (MyObject) myModel.getObject(null);
Just my 2c !
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
