after using 1.4 full time i am more and more coming around to this
point of view also.
disclaimer: terms like "vast majority" are based on my own coding experience...
the fact is, it doesnt matter how often you use models in components,
its how often you actually have to cast the model object to a type, eg
when you call getmodelobject() or getmodel() on the component. a big
percentage of the time you bind the model to a property - like in form
components, or push in a model once and never access it again - like
in dropdownchoice choices model, generics offer you no benefit in
these two cases.
here are a couple of thoughts i have:
generics for formcomponents do not make sense, most of the time they
can figure out the type by inspecting their model. further, generics
did not get rid of the need to specify the type as a constructor
argument: new TextField<Integer>("num", Integer.class)
a lot of times there is no clear type, eg Label. should that be
Label<String>? why do i need to repeat the type twice? new
Label<String>("username", new PropertyModel<String>(this,
"username")); it is very redundant for some components. new
Label("username", new ProeprtyModel<String>(this, "usenrame")) is just
as self documenting.
a vast majority of components are "set it and forget it": add(new
TextField("foo", new PropertyModel<String>(this, "username"));
developer doesnt keep a reference to these components, so generics are
just noise, the type of the model is enough.
i think the fact remains that component's default model is just there
for user's convenience. it would really suck to have to write an
ondetach() handler every time, especially since a single model
instance per component covers 90% usecase. if java had something like
scala's traits, model would not be part of Component.
i am willing to drop component model support if the following can be met:
certain constructors stay generified to document certain aspects, eg
dropdownchoice constructor should be generified.
support generification of certain components, even if it means
removing final from certain methods. this code should still be
possible:
add(new ListView<Person>("people") { protected void
onPopulate(Item<Person> person) {.... where getModel() of that item
returns IModel<Person>
for me, the driving point is that i havent enjoyed writing wicket code
against 1.4 trunk as much.
-igor
On Mon, Jun 2, 2008 at 7:47 AM, John Krasnay <[EMAIL PROTECTED]> wrote:
> On Sun, Jun 01, 2008 at 01:44:59PM -0700, Eelco Hillenius wrote:
>>
>> 1) Generifying* Wicket
>> [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.
>>
>> 2) How strongly do you feel about your choice above?
>> [x] Whatever choice ultimately made, I'll happily convert/ start
>> using 1.4 and up.
>
> IMHO storing a model in a Component is more a convenience than a
> fundamental part of component-ness. This may be part of the reason that
> genericizing Component is so contentious.
>
> I have many components with no model and many others, such as a
> TextField that uses a parent's CompoundPropertyModel, the component has
> a model but I really don't care about the type, since I never call
> getModelObject(). In all these cases (which are easily the majority in
> my experience), genericized Components would force me to deal with the
> syntactic overhead of generics with absolutely zero value.
>
> I'm all for genericizing certain components for which the model is
> central (e.g. ListView and Item) but I think genericizing Component is
> overkill, since it's relatively rare that I care about the type of a
> component's model.
>
> jk
>
> ---------------------------------------------------------------------
> 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]
