and that is the whole problem
who needs the Model itself as a string?
many are dynamic with getObject() impl.
then you shouldnt really do Model but IModel directly
johan
On Wed, May 14, 2008 at 4:29 PM, Doug Donohoe <[EMAIL PROTECTED]> wrote:
>
> From my original post on this topic:
>
> public class StringModel extends Model<String>
>
> -Doug
>
>
> Peter Ertl wrote:
> >
> > StringModel looks ambigious to me, will it extend
> >
> > - LoadableDetachableModel
> > - IModel
> > - Model
> > - AbstractReadOnlyModel
> > - ....
> >
> > ???
> >
> >
> >
> >
> > Am 14.05.2008 um 15:47 schrieb Doug Donohoe:
> >
> >>
> >> 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]
> >
> >
> > ---------------------------------------------------------------------
> > 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-tp17208928p17232467.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]
>
>
