just dont write those!

On Wed, Oct 29, 2008 at 5:18 PM, Igor Vaynberg <[EMAIL PROTECTED]>wrote:

> yes, the inherited will have to most likely go away - but that is
> there only for the CPM.
>
> the icomponentassignedmodel is already broken if a component has more
> then one model because you have to manually call wrap() on those
> anyways...lately ive been writing a lot of components that take more
> then one model so i noticed this :)
>
> -igor
>
> On Wed, Oct 29, 2008 at 8:59 AM, Johan Compagner <[EMAIL PROTECTED]>
> wrote:
> > its not just compound
> > we have 2 special cases for this:
> > IComponentAssignedModel and IComponentInheritedModel
> >
> > which will be both pretty tricky to do if the users must make a field for
> > the model them selfs.
> >
> > but we will see.
> >
> > johan
> >
> >
> > On Tue, Oct 28, 2008 at 5:22 PM, Igor Vaynberg <[EMAIL PROTECTED]
> >wrote:
> >
> >> yes it sucks. i agree. personally i prefer code written against wicket
> >> 1.3. even in 1.3 i hardly had to cast anything and even with those
> >> casts i do not remember getting any class cast exceptions.
> >>
> >> i do think imodel<t> makes a ton of sense, but the types on components
> >> are pretty bad.
> >>
> >> in 1.5 i have an idea to fix it, but i am not sure it is going to work
> >> without giving up compound property model. the idea is to remove the
> >> default model from component completely and have user keep the model
> >> as a field. in ondetach() we can then detach any fields that are
> >> imodel via reflection. this will neatly solve all generics problems
> >> but it has limitations.
> >>
> >> anyways, we will see how it goes. until 1.4 i think the generics will
> >> stay the way they are unless we hear a ton of users complaining.
> >>
> >> -igor
> >>
> >> On Tue, Oct 28, 2008 at 4:23 AM, Artur W. <[EMAIL PROTECTED]> wrote:
> >> >
> >> > Hi Guys,
> >> >
> >> > In the weekend I tried to migrate our application to wicket 1.4.
> >> > I was very happy to use generics with wicket but now I frustrated.
> >> >
> >> > I love Wicket and I know it is nobody fault (it java fault! :)) but
> the
> >> > generics sucks.
> >> >
> >> > Our application is quite big, more than one thousand classes and after
> >> > adding generics
> >> > the code looks awful and it is unreadable. I could live with that but
> >> > especially frustrating are
> >> > more than 4.000 warnings that I have now.
> >> >
> >> > Most of them I cannot fix. For example the warnings apply to the
> >> components
> >> > that don't have models but I have to add them a type. What type? Any?
> >> > Example:
> >> >
> >> > add(new Link("link") { //warning here
> >> > @Override
> >> > public void onClick() {
> >> > //do something here
> >> > }
> >> > });
> >> >
> >> > I have a warning here because I didn't set a type of Link. But it
> doesn't
> >> > have any model. I know I can add @SuppressWarnings("unchecked") but I
> >> don't
> >> > want to do
> >> > that in more than 4000 places in my code. If I do than I will loose
> all
> >> the
> >> > warnign event that I would to have or could save me in the future.
> >> >
> >> > So a question is there any way to workaround about this warnings
> problem?
> >> > I don't want to stay with wicket 1.3 because I realize that it will be
> >> > abandon in a year or something.
> >> >
> >> >
> >> > Thanks in advance,
> >> > Artur
> >> >
> >> > --
> >> > View this message in context:
> >>
> http://www.nabble.com/Migration-to-1.4---generic-headache-tp20205449p20205449.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]
>
>

Reply via email to