I think you are *not* in the minority, but a lot of the dissenters
piped in last minute in a big flood so to some it might look that way.
However, It may actually be valuable the way they are doing it now, so
I'm reserving judgement until I can sit down and port my latest
project to it... and check out how well it works.
The moment I have to do a cast, I'll consider it a sign that it needs
more work.
- Brill Pappin
On 14-Jul-08, at 10:17 AM, Craig McIlwee wrote:
personally i am still in favor of going with the m2 way of doing
things where
Component is generic, but from the looks of the discussion i think i
may be
in the minority here. this kinda surprises me though because as i
read the
original generic discussion it sounded like most people supported
Component<T>.
igor.vaynberg wrote:
basically we feel this is a much cleaner way then what is 1.4m2. this
is a call for confirmation/discussion from our user base.
1) i'm not sure i agree with this. i don't feel that just adding
<Void> to
components that don't need their models makes things messy. i'd
much rather
have the option to use generics whenever i need than to create extra
classes
such as the 'GenericPanel', etc that have been mentioned. in fact i
think
its alot messier to create more classes and to start changing method
names
(getDefaultModel, etc) and then adding getModel to the classes that
do use
generics.
2) the wicket web site now suggests the following code for generic
components:
@SuppressWarnings("unchecked")
public final T getModelObject()
{
return (T)getDefaultModelObject();
}
... but isn't the purpose of adding generic support to wicket to
prevent the
need for unchecked casts? if we now have to place unchecked casts
into our
code then we lose out on the strong type checking that generics are
supposed
to provide. its not hard to imagine a case where one part of
someone's code
calls setDefaultModelObject with the wrong type, and then later
another part
of the code calls getModelObject and hits a class cast exception.
3) the Component class has several methods that return 'this' to
allow for
method chaining. the problem here is that the generic components
don't
override these methods with covariant returns, so if i do something
like
formComponent
.setVersioned(false).moreMethodCalls().chainedTogether() then
those chained methods can't use models because we've upcast our
component to
something that doesn't have generic support. i guess the solution
would be
to put these calls on separate lines, but it seems like a bit of a
hassle
(i'm probably just being picky tho)
- craig
--
View this message in context:
http://www.nabble.com/generics-tp18083910p18444866.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
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]
