Let me outline what I believe the benefits are. For example:
add(new Label<String>("tournamentName", tournament.getName()));
add(new Label<String>("hostName", game.getHostPlayer()));
row.add(new AttributeModifier("class", true, new
Model<String>(row.getIndex() % 2 == 0 ? "odd" : "even")));
add(new StringLabel("tournamentName", tournament.getName()));
add(new StringLabel("hostName", game.getHostPlayer()));
row.add(new AttributeModifier("class", true, new StringModel(row.getIndex()
% 2 == 0 ? "odd" : "even")));
Sure, it seems like a small difference and a saving of two characters, but
here is what I believe are the benefits of doing this:
1) I can more easily use the features of my IDE such as auto-completion
2) Find Usages is more accurate (at least in IntelliJ, where I'm not aware
of a find-usages that scopes to a particular generic type)
3) Let's face it, Generics clutters up your code and makes it harder to
read. This simplifies things a bit.
In answer to Martijn's assumption (in a separate post) that I was going to
iterate over all java types and all wicket types: that is an incorrect
assumption. Obviously, I would want to pick the most common use cases and
seek feedback from the community. Let us not dismiss it outright. I
believe this is a valid topic of conversation. Generics are new to Wicket
and still unused by many Java APIs and likely new to many programmers. I
can tell you that using classes such as this made it much quicker and easier
to remove all the warnings that showed up in my code when I migrated to 1.4.
It seems easier to replace common usage from before (new Label(...)) with
new StringLabel(...) rather than new Label<String> (even typing that now
was more difficult). In any case, there may be some complaining about the
extensive use of Generics in 1.4 once it is released. This may make it
easier to transition. Maybe not. At least let's be open to discussing it.
Finally, in answer to the point about "negating the point of generics", I
respectfully disagree. One major point of generics is to avoid code
duplication of boilerplate code. It it weren't for the need to create
constructors, there wouldn't be any duplicated code. I agree that it is a
fine balance to strike, but there are competing needs of readability and
maintainability.
-Doug
Hoover, William wrote:
>
> imho, that seems like that adds a lot of unnecessary code. One of the
> nice things about Wicket is that it keeps the bloat to a minimum.
>
> -----Original Message-----
> From: Doug Donohoe [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 14, 2008 8:21 AM
> To: [email protected]
> Subject: Re: Using generics with some non-generic classes in Wicket
>
>
> Somewhat related to this thread, when I moved to generics win Wicket
> 1.4, I created some utility classes such as:
>
> public class VoidContainer extends WebMarkupContainer<Void> public
> class VoidPanel extends Panel<Void> public class StringLabel extends
> Label<String>
>
> public class IntegerModel extends Model<Integer> public class
> StringModel extends Model<String> public class DateModel extends
> Model<Date> public class DoubleModel extends Model<Double>
>
> And so on. This made my wicket code cleaner and easier to use. I think
> the Wicket 1.4 generics implementation is headed in the right direction.
> It was a pain at first because I had to parameterize everything, but
> creating convenience classes like this made it easier.
>
> I'm thinking about creating a patch with a suite of these types of
> classes because I think users will want something like this.
>
> -Doug
>
>
> Johan Compagner wrote:
>>
>> The problem is that wicket needs an annotation
>>
>> <genericsOptional>
>>
>> so that all the warnings about raw types are gone.
>>
>> A component only has to be generic if you use the IModel constructor
>> or call getModel(), getModelObject() methods..
>> for the rest it is not really needed
>>
>> johan
>>
>> On Wed, May 14, 2008 at 9:28 AM, Sebastiaan van Erk
>> <[EMAIL PROTECTED]>
>> wrote:
>>
>>> My post kind of missed the point, I shouldn't post when I'm already
>>> half asleep. :-)
>>>
>>> Obviously MarkupContainer satisfies the MarkupContainer<?> in a
>>> method argument, so it accepts the raw type. However, it generates a
>>> warning because the method says it's generified, so you should be
>>> using the generic type.
>>>
>>> Johan Compagner wrote:
>>>
>>> > I dont care, because i cant do any thing with the ? The only thing
>>> > it enforces is that it must now be a generic class which is
>>> > annoying. Not to mention that in that area eclipse and javac accept
>
>>> > different things....
>>> >
>>>
>>> The reason it warns you to use generics when generics are wanted is
>>> because Sun wants to be able to make it *required* (in a future
>>> release) to use generics where generics are wanted; at least, so I
>>> read... I think in the real world they wouldn't dare to do this
>>> because it would piss off so many users and break so much stuff. :-)
>>>
>>> But the idea is that if something is generified you should be using a
>
>>> type parameter, and using a raw type is *purely* for backwards
>>> compatibility with legacy code.
>>>
>>> Regards,
>>> Sebastiaan
>>>
>>> So or we in wicket dont use <?> any where and have supress warning
>>> > everywhere for that or we do use it and then suddenly it is in my
>>> > eyes restricted to much.
>>> >
>>>
>>> I don't understand
>>>
>>>
>>> > On 5/14/08, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
>>> >
>>> > > Johan Compagner wrote:
>>> > >
>>> > > > yes thats the reason
>>> > > >
>>> > > > you are calling the method add with a generified component but
>>> > > > that container itself is not generified
>>> > > >
>>> > > > i dont like this about generics expecially the onces like this:
>>> > > >
>>> > > > add(MarkupContainer<?> container)
>>> > > >
>>> > > > then suddenly a none generified component cant be added...
>>> > > > thats really stupid <?> should mean anything.. including none
>>> > > > generics
>>> > > >
>>> > > No, that's not correct. For example, List<?> is much more
>>> > > restrictive than a raw List (which is a List). To a raw list you
>>> > > can add an instance of any type whatever, i.e., list.add(new
>>> > > Object()). But in List<?> the ? is a wildcard which says it could
>
>>> > > be any type there, i.e., it could be a List<Integer>. But you
>>> > > can't add a new Object() to a List<Integer>!
>>> > >
>>> > > Thus MarkupContainer<?> means "MarkupContainer parameterized by
>>> > > some unknown type", and *not* MarkupContainer parameterized by
>>> > > Object, which is what the raw type means.
>>> > >
>>> > > Regards,
>>> > > Sebastiaan
>>> > >
>>> > > johan
>>> > > >
>>> > > >
>>> > > > On Tue, May 13, 2008 at 5:55 PM, Stefan Simik <
>>> > > > [EMAIL PROTECTED]>
>>> > > > wrote:
>>> > > >
>>> > > > I have one idea,
>>> > > > >
>>> > > > > the reason of the warnigs is, that parent of
>>> > > > > AjaxPagingNavigator is PagingNavigator, which has parent
>>> > > > > Panel ---> that is not parameterized.
>>> > > > >
>>> > > > > The same problem is with LoopItem, which extends the
>>> > > > > WebMarkupContainer ---> that is not parameterized.
>>> > > > >
>>> > > > > ? could this be the reason ?
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > Stefan Simik wrote:
>>> > > > >
>>> > > > > > Mhmm, it is meaningful ;) I will know in future, thx
>>> > > > > >
>>> > > > > > One of the last occuring warning is, when working with
>>> > > > > > MarkupContainer#add(...) or #addOrReplace(...) method.
>>> > > > > >
>>> > > > > > Example: I have a simple AjaxPagingNavigator, to which I
>>> > > > > > add a simple ListView
>>> > > > > >
>>> > > > > >
>>> ---------------------------------------------------------------------
>>> --
>>> > > > > > ListView<Integer> menu = new ListView<Integer>("id",
> numbers){
>>> > > > > > //....populate metods
>>> > > > > > }
>>> > > > > > add(menu); //warning here
>>> > > > > >
>>> > > > > > The warning says:
>>> > > > > > "Type safety: The method add(Component...) belongs to the
>>> > > > > > raw type MarkupContainer.
>>> > > > > > References to generic type MarkupContainer<T> should be
>>> > > > > > parameterized"
>>> > > > > >
>>> > > > > > I cannot find out, what's the warning reason, because
>>> > > > > > ListView self is parameterized.
>>> > > > > >
>>> > > > > >
>>> > > > > > --
>>> > > > > View this message in context:
>>> > > > >
>>> > > > >
>>> > >
>>> http://www.nabble.com/Using-generics-with-some-non-generic-classes-in
>>> -Wicket-tp17208928p17212015.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]
>>> >
>>> >
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wi
> cket-1.4M1-tp17208928p17229755.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]
>
>
>
--
View this message in context:
http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17231467.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]
