That would cost more memory then it would gain....
Now it is just 1 int field.. And do know that model isnt a field any
more by itself on component. Ok it is still a reference but that is
shared by behaviours and metadata.
So if we set it in a model, we would have created the model object
with a reference to a created Integer object that has the int value...
And that is stored in component, now if there is no metadata or
behavior then that cost nothing but if there was then everything cost
more..
On 5/14/08, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> so why dont we store the integer in the model then? save an extra
> memory slot, because if you make it Void then no one can set the
> modelobject anyways.
>
> -igor
>
> On Wed, May 14, 2008 at 8:28 AM, Johan Compagner <[EMAIL PROTECTED]>
> wrote:
>> hmm i will make it <Void>
>> because the LoopItem doesnt really have a model with an Integer in the
>> model..
>> it has an primitive int itself stored in it self.
>>
>> johan
>>
>>
>> On Wed, May 14, 2008 at 4:52 PM, Stefan Simik <[EMAIL PROTECTED]>
>> wrote:
>>
>>>
>>> Great, it work without warnings now ;)
>>>
>>> Joham, could you please change the following class too ?
>>>
>>> file: Loop.java
>>> line: 53
>>> from: LoopItem extends WebMarkupContainer
>>> to: LoopItem extends WebMarkupContainer<Integer>
>>>
>>> thx ;)
>>> Stefan
>>>
>>>
>>>
>>>
>>> Johan Compagner wrote:
>>> >
>>> > i already did the commit just yet..
>>> >
>>> > i did make them all because i think people generally dont want to
>>> > generify them anyway (use the model object)
>>> >
>>> >
>>> >
>>> > On Tue, May 13, 2008 at 9:48 PM, Stefan Simik <[EMAIL PROTECTED]>
>>> > wrote:
>>> >
>>> >>
>>> >> please, and will be these classes later generified ?
>>> >> Or should I make a RFE, or can I help anyway-for example attach a
>>> >> patch
>>> ?
>>> >>
>>> >> I love your work and Wicket, so I do my best, to make it better ;)
>>> >>
>>> >> Stefan Simik
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> 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
>>> >> >
>>> >> > 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]
>>> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >>
>>> >> --
>>> >> View this message in context:
>>> >>
>>> http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17216869.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]
>>> >>
>>> >>
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Using-generics-with-some-non-generic-classes-in-Wicket-1.4M1-tp17208928p17233011.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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
