Goes to show you that people have a tendency to reject things that they do not understand rather than put in the effort :o)
-----Original Message----- From: richardwilko [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 10:21 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket ok maybe i misread this : 'Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking.' but those 2 sentences seem to contradict each other, the first says only generify IModel which I assumed ti mean that when you put a String into a model you would get a String out of it, the second seems to says generifiying components to make them only accept some model types. So just to clarify my position generic models which would do away with this type of casting: protected void onSubmit(AjaxRequestTarget target, Form form) { EmailFormModel emailFormModel = (EmailFormModel) form.getModelObject(); .... is what I would like to see. generic components im not bothered about. if using generics wont do away with the casting then I dont see any point to using them at all. Johan Compagner wrote: > > why are you contradicting yourself? > > "To be honest I don't see the advantage of generic components, all I > want is to not have to do casting when I'm using models, > .getModelObject() should return the type that I put in, in a list > view, if I give it a list of strings I dont want to cast the listItem > model object to a string." > > if you have just IModel then you will have to cast.. getModelObject > will always return just Object then. > > > ok maybe i misread > > about: > > "new TextArea(...).add(some behavior).setRequired(true) " > > this can be done but then we have to override some methods of > component and then return another type The problem is that this could > result in us lifting a final where we dont want to.. > But this is outside the scope of generics > > johan > > On Mon, Jun 2, 2008 at 3:26 PM, richardwilko > <[EMAIL PROTECTED]> > wrote: > >> >> >> [ x ] Can best be done in a limited fashion, where we only generify >> IModel but not components. I care more about what generifying can do >> for API clarity (declaring a component to only accept certain models >> for instance) than static type checking. >> >> [ x ] Whatever choice ultimately made, I'll happily convert/ start >> using 1.4 and up. >> >> To be honest I don't see the advantage of generic components, all I >> want is to not have to do casting when I'm using models, >> .getModelObject() should return the type that I put in, in a list >> view, if I give it a list of strings I dont want to cast the listItem >> model object to a string. It would also be nice if the .add() and >> others methods on components could return the type of component it is >> rather than just a Component object. eg you cant do 'new >> TextArea(...).add(some behavior).setRequired(true) because the add >> behaviour method returns a Component not a TextArea and setRequired >> is not available on Components. >> >> Thanks >> -- >> View this message in context: >> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is >> -your-take-on-generics-with-Wicket-tp17589984p17601296.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/users%2C-please-give-us-your-opinion%3A-what-is-yo ur-take-on-generics-with-Wicket-tp17589984p17602507.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]
