users, please give us your opinion: what is your take on generics with Wicket

[John Patterson]

Eelco Hillenius wrote:

et an idea of what you think.

1) Generifying* Wicket
   [ x] Can best be done like currently in the 1.4 branch, where models
and components are both generified. I care most about the improved
static type checking generified models and components give Wicket.

But turned off where not appropriate.

Eelco Hillenius wrote:

2) How strongly do you feel about your choice above?
   [ ]

[x] It would make me sad to lose generic components : (

[igor.vaynberg]

you still have ondetach()...but for convinience we can automatically
detach any imodel fields, i actually wanted to do this for a while...

-igor

On Wed, Jun 4, 2008 at 8:43 AM, Johan Compagner <jcompagner@...> wrote:

> and if i store it in metadata ;)
>
>
> On Wed, Jun 4, 2008 at 5:16 PM, Igor Vaynberg <igor.vaynberg@...>
> wrote:
>
>> why even have an interface? just detach all imodel fields via reflection!
>>
>> -igor
>>
>>
>> On Wed, Jun 4, 2008 at 3:37 AM, James Carman <james@...>
>> wrote:
>> > On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
>> > <eelco.hillenius@...> wrote:
>> >>> it all depends, on how and what you're developing.
>> >>
>> >> Yeah. I actually use less and less models in the regular way nowadays.
>> >> I use plenty of panels (the app I work on hardly uses separate pages)
>> >> that nest other panels in them (typically detail views or dialogs)
>> >> that reuse models of the parent. But indeed YMMV.
>> >>
>> >> Personally, I think the whole generics business exposes that the
>> >> one-one relation between components and models is flawed. Without
>> >> generics this isn't much of a problem, just the odd unused member and
>> >> constructor, but as generics aren't as 'optional' it is all very in
>> >> your face suddenly.
>> >>
>> >> I think on the longer term (post 1.4) we should re-think how models
>> >> work in Wicket. See if we can find an elegant way to make this more
>> >> flexible (I'm not in favor of the id based thing someone posted
>> >> earlier btw) without breaking the whole world.
>> >>
>> >
>> > We discussed this on ##wicket yesterday.  I asked why we have models
>> > on all components and someone pointed out that the main reason was
>> > about the detach stuff I believe.  But, couldn't that be solved by
>> > having some components that implement something like IModelDriven (or
>> > IModelBacked or whatever) and the detach logic could apply to only
>> > those components?  Also, someone has pointed out that when they create
>> > their own components, they sometimes (such as in Palette) have
>> > multiple "models" that they deal with.  Allowing components to name
>> > their models what they want would be nice, too.
>> >
>> >> FWIW, I'm still on the fence when it comes to whether we should go for
>> >> a full or partial (models only) implementation of generics, though I'm
>> >> leaning towards partial.
>> >>
>> >> Eelco
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@...
>> >> For additional commands, e-mail: users-help@...
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@...
>> > For additional commands, e-mail: users-help@...
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Eelco Hillenius]

> Having multiple models is rare, however, having one model that can
> (but doesn't have to) be used is more common imho.

Not that rare if I look at my code, especially if you take panels and
fragments into account. I have plenty of places where I use two or
three models.

> Wicket is kinda optimized for the later, so if you don't use the model there is no
> runtime cost associated. If we didn't have "default" model slot this
> would be more difficult to achieve.

The problem with generics now is that the model isn't as optional
anymore. So you'd have to use void or whatever.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Matej Knopp]

I was talking about the model slot. If you don't have a model in
component it doesn't cost you anything.

-Matej

On Wed, Jun 4, 2008 at 6:49 PM, Eelco Hillenius
<eelco.hillenius@...> wrote:

>> Having multiple models is rare, however, having one model that can
>> (but doesn't have to) be used is more common imho.
>
> Not that rare if I look at my code, especially if you take panels and
> fragments into account. I have plenty of places where I use two or
> three models.
>
>> Wicket is kinda optimized for the later, so if you don't use the model there is no
>> runtime cost associated. If we didn't have "default" model slot this
>> would be more difficult to achieve.
>
> The problem with generics now is that the model isn't as optional
> anymore. So you'd have to use void or whatever.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Eelco Hillenius]

On Wed, Jun 4, 2008 at 9:43 AM, Igor Vaynberg <igor.vaynberg@...> wrote:
> you still have ondetach()...but for convinience we can automatically
> detach any imodel fields, i actually wanted to do this for a while...

I tried to write this two days ago, but wasn't able to pull it off...
I wrote an instantiation listener that introspected on the fields of
components and replaced IModel members with a proxy. These proxies
would register themselves with the request cycle for cleaning up
whenever the getObject was called, and the request cycle then would go
through the list of registered models and detach them at the end of
the request. The problem I ran into however is that these members can
be final, assigned at a later stage (typically are actually) and such.

But if there is some way to automatically detach model members, we
could get rid of the model member in component and instead just let
components have models by default where it actually always makes
sense, such as form components.

Anyway, that's something for 1.5. If it is fixable, I think that would
be the way out of the generics controversy :-)

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Eelco Hillenius]

On Wed, Jun 4, 2008 at 9:52 AM, Matej Knopp <matej.knopp@...> wrote:
> I was talking about the model slot. If you don't have a model in
> component it doesn't cost you anything.

The cost in this case is the fact that having the model slot, even
when not used, results in the assumption that a component is typed.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Martijn Dashorst]

but IModel implementations can have Imodels inside too

And the LDM doesn't play wel  with detach unfortunately as it keeps an
attached boolean that prevents the detach from entering the nested
IModel

Martijn

On Wed, Jun 4, 2008 at 6:43 PM, Igor Vaynberg <igor.vaynberg@...> wrote:

> you still have ondetach()...but for convinience we can automatically
> detach any imodel fields, i actually wanted to do this for a while...
>
> -igor
>
> On Wed, Jun 4, 2008 at 8:43 AM, Johan Compagner <jcompagner@...> wrote:
>> and if i store it in metadata ;)
>>
>>
>> On Wed, Jun 4, 2008 at 5:16 PM, Igor Vaynberg <igor.vaynberg@...>
>> wrote:
>>
>>> why even have an interface? just detach all imodel fields via reflection!
>>>
>>> -igor
>>>
>>>
>>> On Wed, Jun 4, 2008 at 3:37 AM, James Carman <james@...>
>>> wrote:
>>> > On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
>>> > <eelco.hillenius@...> wrote:
>>> >>> it all depends, on how and what you're developing.
>>> >>
>>> >> Yeah. I actually use less and less models in the regular way nowadays.
>>> >> I use plenty of panels (the app I work on hardly uses separate pages)
>>> >> that nest other panels in them (typically detail views or dialogs)
>>> >> that reuse models of the parent. But indeed YMMV.
>>> >>
>>> >> Personally, I think the whole generics business exposes that the
>>> >> one-one relation between components and models is flawed. Without
>>> >> generics this isn't much of a problem, just the odd unused member and
>>> >> constructor, but as generics aren't as 'optional' it is all very in
>>> >> your face suddenly.
>>> >>
>>> >> I think on the longer term (post 1.4) we should re-think how models
>>> >> work in Wicket. See if we can find an elegant way to make this more
>>> >> flexible (I'm not in favor of the id based thing someone posted
>>> >> earlier btw) without breaking the whole world.
>>> >>
>>> >
>>> > We discussed this on ##wicket yesterday.  I asked why we have models
>>> > on all components and someone pointed out that the main reason was
>>> > about the detach stuff I believe.  But, couldn't that be solved by
>>> > having some components that implement something like IModelDriven (or
>>> > IModelBacked or whatever) and the detach logic could apply to only
>>> > those components?  Also, someone has pointed out that when they create
>>> > their own components, they sometimes (such as in Palette) have
>>> > multiple "models" that they deal with.  Allowing components to name
>>> > their models what they want would be nice, too.
>>> >
>>> >> FWIW, I'm still on the fence when it comes to whether we should go for
>>> >> a full or partial (models only) implementation of generics, though I'm
>>> >> leaning towards partial.
>>> >>
>>> >> Eelco
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: users-unsubscribe@...
>>> >> For additional commands, e-mail: users-help@...
>>> >>
>>> >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@...
>>> > For additional commands, e-mail: users-help@...
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.3 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Eelco Hillenius]

On Wed, Jun 4, 2008 at 10:05 AM, Martijn Dashorst
<martijn.dashorst@...> wrote:
> but IModel implementations can have Imodels inside too

Whether done automatically or by components as we do now, ultimately
the calls to detach will be the same, right?

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[igor.vaynberg]

sounds way too complicated to me dude...

component.detach() {
  for (field:fields) {
    if (imodel.class.isassignablefrom(field.gettype)) {
        ((imodel)field.get(this)).detach();
    }
  }
  onDetach();
}

with proper caching of the actual fields lookup this should be pretty performant

-igor

On Wed, Jun 4, 2008 at 10:03 AM, Eelco Hillenius
<eelco.hillenius@...> wrote:

> On Wed, Jun 4, 2008 at 9:43 AM, Igor Vaynberg <igor.vaynberg@...> wrote:
>> you still have ondetach()...but for convinience we can automatically
>> detach any imodel fields, i actually wanted to do this for a while...
>
> I tried to write this two days ago, but wasn't able to pull it off...
> I wrote an instantiation listener that introspected on the fields of
> components and replaced IModel members with a proxy. These proxies
> would register themselves with the request cycle for cleaning up
> whenever the getObject was called, and the request cycle then would go
> through the list of registered models and detach them at the end of
> the request. The problem I ran into however is that these members can
> be final, assigned at a later stage (typically are actually) and such.
>
> But if there is some way to automatically detach model members, we
> could get rid of the model member in component and instead just let
> components have models by default where it actually always makes
> sense, such as form components.
>
> Anyway, that's something for 1.5. If it is fixable, I think that would
> be the way out of the generics controversy :-)
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Johan Compagner]

If besides formcomponent you get links/buttons and so on, then i still
think the example i see of verbosity is still there, like
dropdownchoice is then generified??

On 6/4/08, Eelco Hillenius <eelco.hillenius@...> wrote:

> On Wed, Jun 4, 2008 at 9:43 AM, Igor Vaynberg <igor.vaynberg@...>
> wrote:
>> you still have ondetach()...but for convinience we can automatically
>> detach any imodel fields, i actually wanted to do this for a while...
>
> I tried to write this two days ago, but wasn't able to pull it off...
> I wrote an instantiation listener that introspected on the fields of
> components and replaced IModel members with a proxy. These proxies
> would register themselves with the request cycle for cleaning up
> whenever the getObject was called, and the request cycle then would go
> through the list of registered models and detach them at the end of
> the request. The problem I ran into however is that these members can
> be final, assigned at a later stage (typically are actually) and such.
>
> But if there is some way to automatically detach model members, we
> could get rid of the model member in component and instead just let
> components have models by default where it actually always makes
> sense, such as form components.
>
> Anyway, that's something for 1.5. If it is fixable, I think that would
> be the way out of the generics controversy :-)
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Eelco Hillenius]

On Wed, Jun 4, 2008 at 10:10 AM, Igor Vaynberg <igor.vaynberg@...> wrote:

> sounds way too complicated to me dude...
>
> component.detach() {
>  for (field:fields) {
>    if (imodel.class.isassignablefrom(field.gettype)) {
>        ((imodel)field.get(this)).detach();
>    }
>  }
>  onDetach();
> }
>
> with proper caching of the actual fields lookup this should be pretty performant

Maybe. I was trying to avoid having to introspect on every single detachment.

Eelco

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[igor.vaynberg]

On Wed, Jun 4, 2008 at 10:23 AM, Eelco Hillenius
<eelco.hillenius@...> wrote:

> On Wed, Jun 4, 2008 at 10:10 AM, Igor Vaynberg <igor.vaynberg@...> wrote:
>> sounds way too complicated to me dude...
>>
>> component.detach() {
>>  for (field:fields) {
>>    if (imodel.class.isassignablefrom(field.gettype)) {
>>        ((imodel)field.get(this)).detach();
>>    }
>>  }
>>  onDetach();
>> }
>>
>> with proper caching of the actual fields lookup this should be pretty performant
>
> Maybe. I was trying to avoid having to introspect on every single detachment.

well, like i said, just cache it in a global map.
ConcurrentHashMap<Class<Component>,Collection<Field>>. we do this all
over the place, eg propertyresolver. that way you can even only cache
IModel fields, so the loop becomes even tighter.

-igor

>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Patrick Angeles]

igor.vaynberg wrote:

component.detach() {
  for (field:fields) {
    if (imodel.class.isassignablefrom(field.gettype)) {
        ((imodel)field.get(this)).detach();
    }
  }
  onDetach();
}

+1

I'm also for moving getModel()/getModelObject() out of Component and only putting them in things that really use models, like Label and FormComponent...

I agree, though, that this should probably wait for 1.5...

[Matej Knopp]

We should definitely discuss this after 1.4.

-Matej

On Wed, Jun 4, 2008 at 7:30 PM, Patrick Angeles <patrick@...> wrote:

>
>
> igor.vaynberg wrote:
>>
>> component.detach() {
>>   for (field:fields) {
>>     if (imodel.class.isassignablefrom(field.gettype)) {
>>         ((imodel)field.get(this)).detach();
>>     }
>>   }
>>   onDetach();
>> }
>>
>
> +1
>
> I'm also for moving getModel()/getModelObject() out of Component and only
> putting them in things that really use models, like Label and
> FormComponent...
>
> I agree, though, that this should probably wait for 1.5...
>
> --
> 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-tp17589984p17652189.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Brill Pappin]

So it would be no generics or it would be:
MyComponent<CompoundPropertyModel> mycom = new
MyComponent<CompoundPropertyModel>();


and I was saying that the suppress *should not* be in the API because
people need the ability to control that sort of thing at their own
code level, which should address your issue.

- Brill Pappin

On Tue, Jun 3, 2008 at 11:54 PM, Mike Comb <mcomb@...> wrote:

> Well, in our case it would almost never be:
>
> MyComponent<MyModel> mycom = new MyComponent<MyModel>();
>
> We don't have many of our own models, we use CompoundPropertyModel pretty
> much exclusively (wrapping DAOs or javabeans).  So the verbosity doesn't
> benefit us much.  Also, the vast majority of our components don't have a
> model.  We generally have a page containing one or more forms with a
> CompoundPropModel on each form.  Having generics (particularly if they are
> just something like <Void>) on every other object in the page is messy and
> confusing in my mind.
>
> Telling people to use suppress annotations is not a good solution either, we
> want those warnings for other things in our code (Collections, etc).
>
> -Mike
>
> On Jun 3, 2008, at 8:11 PM, Brill Pappin wrote:
>
>> I guess I'm not understanding why people feel strongly against generics in
>> the components.
>>
>> The model is going to use them for the data they contain, but the
>> component
>> would use them for the model it uses:
>>
>> MyModel<String> mymodel = new MyModel<String>();
>>
>> MyComponent<MyModel> mycom = new MyComponent<MyModel>();
>>
>> And that's all you would ever see of the generics unless you actually
>> override one of the components methods (as in a button onclick).
>>
>> To top it off, I'm not even sure you would have to specify the generics
>> for
>> the component (not up on my generics coding)... But  if the warning was
>> bugging you, you could simply use a suppress annotation (suppress should
>> absolutely not be in the API).
>>
>> More verbose? Yes... Not by much, but it is... However the advantages
>> gained
>> in terms of readability and type safety are enormous.
>>
>> - Brill Pappin
>>
>>
>> -----Original Message-----
>> From: Mike Comb [mailto:mcomb@...]
>> Sent: Tuesday, June 03, 2008 4:39 PM
>> To: users@...
>> Subject: Re: users, please give us your opinion: what is your take on
>> generics with 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.
>>
>> I've spent a couple of afternoons trying to move our app to m1.  My
>> experience has been that generics on components are absolutely not worth
>> it
>> for our use cases.  I love generics on objects that directly hold data
>> (IModel), but they are too verbose and not very useful for objects that
>> are
>> a few levels removed from the actual data.
>>
>>>  [X ] Whatever choice ultimately made, I'll happily convert/ start
>>> using 1.4 and up.
>>
>> "Happily" probably isn't the word I'd chose, but we'll move to 1.4
>> eventually regardless of the decision made.
>>
>> -Mike
>>
>> --
>> Mike Comb
>> Director of Engineering
>> SoftCoin, Inc
>> mcomb@...
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
>
>
> --
> Mike Comb
> Director of Engineering
> SoftCoin, Inc
> mcomb@...
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Brill Pappin]

Opinion, not statement :)
But i get where your coming from.

- Brill

On Tue, Jun 3, 2008 at 11:29 PM, Igor Vaynberg <igor.vaynberg@...> wrote:

> no worries, i wasnt holding my breath. its just that when i make
> sweeping statements i tend to have something to back them up that
> other people can see...
>
> -igor
>
> On Tue, Jun 3, 2008 at 8:19 PM, Brill Pappin <brill@...> wrote:
>>
>> You will wait a long time for an example generated from "the API would be
>> different" in such and such a case, based on an opinion.
>>
>> If your really all that interested you could start from scratch using
>> generics and see what came out.
>> Let me know if you do, because I'd be interested to see if my opinion held
>> any merit.
>>
>> However, if your interested in why I said that in the first place, then I
>> can explain that.
>>
>> I don't know if you have every done true TDD (most people can't or think
>> they can), but it actually changes your code and the way you write it.
>> Starting with 2 users of your code makes a significant impact on what it
>> looks like in the end.
>> I applied the same thoughts to using generics from the start, and realized
>> the API would likely be a bit different. Exactly how much, I wouldn't
>> presume to guess.
>>
>> - Brill Pappin
>>
>> -----Original Message-----
>> From: Igor Vaynberg [mailto:igor.vaynberg@...]
>> Sent: Tuesday, June 03, 2008 11:03 PM
>> To: users@...
>> Subject: Re: users, please give us your opinion: what is your take on
>> generics with Wicket
>>
>> sorry, still waiting for an example here...
>>
>> -igor
>>
>> On Tue, Jun 3, 2008 at 7:53 PM, Brill Pappin <brill@...> wrote:
>>> Actually, i did not say "... say that wicket api needs a radical
>>> refactoring in order to support generics" what I actually said was "I
>>> think that if Wicket had been written with generics from the
>>> beginning, the API would be different".
>>>
>>> No "radical refactoring required" was mentioned :)
>>>
>>> Big difference... It would be WAY too much work to rewrite it now, and
>>> I think your right that it can be implemented fairly well without too
>>> much impact on the users.
>>>
>>> - Brill Pappin
>>>
>>> -----Original Message-----
>>> From: Igor Vaynberg [mailto:igor.vaynberg@...]
>>> Sent: Tuesday, June 03, 2008 12:21 AM
>>> To: users@...
>>> Subject: Re: users, please give us your opinion: what is your take on
>>> generics with Wicket
>>>
>>> you made a radical statement, just wandering if there is anything
>>> concrete you can back it up with. in my head the generics have very
>>> little effect on the actual api design so i am wandering what prompted
>>> you to say that wicket api needs a radical refactoring in order to
>>> support generics - which essentially are little more then metadata.
>>>
>>> -igor
>>>
>>> On Mon, Jun 2, 2008 at 8:50 PM, Brill Pappin <brill@...> wrote:
>>>> So am I :)
>>>>
>>>> I think that just like TDD generates a whole new structure to your
>>>> code (IMO a better one) that implementing generics at the start would
>>>> have produced something a bit different.
>>>>
>>>> - Brill Pappin
>>>>
>>>> -----Original Message-----
>>>> From: Igor Vaynberg [mailto:igor.vaynberg@...]
>>>> Sent: Monday, June 02, 2008 11:42 PM
>>>> To: users@...
>>>> Subject: Re: users, please give us your opinion: what is your take on
>>>> generics with Wicket
>>>>
>>>> im really curious to hear what these changes would be...
>>>>
>>>> -igor
>>>>
>>>> On Mon, Jun 2, 2008 at 8:25 PM, Brill Pappin <brill@...> wrote:
>>>>>
>>>>> I think...
>>>>>
>>>>> We should be able to use the untyped variants, but the explanations
>>>>> for why that won't work directly was valid.
>>>>>
>>>>> So on to you're A/B question. I don't think it matters much... The
>>>>> people doing things "inline" are going to use that method anyway and
>>>>> generics won't hurt them, but the usefulness to people who write
>>>>> more extensive application is likely more important (if its that
>>>>> simple it doesn't matter much, if its complicated then it is and can be
>> used).
>>>>>
>>>>>
>>>>> Allow me to digress.
>>>>> I think that if Wicket had been written with generics from the
>>>>> beginning, the API would be different... And that is the root of the
>>>> problem.
>>>>> I think that maybe a concerted refactoring effort *must* allow the
>>>>> API to change (call it wicket 2.0 for all of us old struts users) in
>>>>> order for things to work out properly.
>>>>> I don't actually think that heavy a refactoring would be such a bad
>>>>> thing. I love what Wicket has done, but I think it could be less
>>>>> "black-boxy" as well.
>>>>>
>>>>> - Brill
>>>>>
>>>>> -----Original Message-----
>>>>> From: Stefan Lindner [mailto:lindner@...]
>>>>> Sent: Monday, June 02, 2008 12:13 PM
>>>>> To: users@...
>>>>> Subject: AW: users, please give us your opinion: what is your take
>>>>> on generics with Wicket
>>>>>
>>>>> Brill Pappin wrote
>>>>>>I don't know, I think the discussion is going *toward* generics.
>>>>>>Frankly I can't even see why its an issue at all, the language has
>>>>> evolved and uses them... Why would Wicket not also use them its
>>>>> inline with
>>>>>>the current state of the language?
>>>>>>
>>>>>>There is no reason that people who can't get their heads around
>>>>> Generics can't use the older releases that don't include it, but IMO
>>>>> any java >developer who doesn't get generics yet better make some
>>>>> time to learn, because like it or not, they *will* be dealing with them.
>>>>>
>>>>> I agree totally with you. My expericence with Generics over the last
>>>>> two years was that any project that was adopted to generics had much
>>>>> less errors afterwards.
>>>>>
>>>>> But the main problem in this discussion seems to be that there are
>>>>> two very different sorts of Web Applications that are developed with
>>>>> wicket and both may have predecessors that are non generic.
>>>>>
>>>>> Type A: A Web applicatons that make heavy use of Models, like
>>>>> classic desktop allications that are ported to the web. I think the
>>>>> programmers of such applications like Generics becaus they help them
>>>>> to avoid erros and the current wicket generic implementation leads
>>>>> to a strong typed application that needs a good object model (and a
>>>>> good
>>>> database design).
>>>>> If you port an exisitng wicket application with no generic to wicket
>>>>> 1.4 you might discover some unclear object model problems in your
>>>>> exisitng code. And it's always easier to point to wicket's generics
>>>>> than to blame your own code
>>>>> :-)
>>>>>
>>>>> Type B: A Web Application with more static content, only some date
>>>>> (like user logins, user profile data). In this case it's clear that
>>>>> some people say "why should I always tyle 'Link<Void>', none of my
>>>>> links has a Model, just about 10% of my Components have a Model".
>>>>> But why dont't they write their own wrapper e.g. MyVoidLink extends
>>>>> Link<Void>? I remember a dicsusson about such Components some weeks ago.
>>>>>
>>>>>
>>>>> What do you think about it? Would it help users of Type B to have
>>>>> VoidComponents?
>>>>>
>>>>> Stefan
>>>>>
>>>>> --------------------------------------------------------------------
>>>>> - To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>> --------------------------------------------------------------------
>>>>> - To unsubscribe, e-mail: users-unsubscribe@...
>>>>> For additional commands, e-mail: users-help@...
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Brill Pappin]

I *have* used the m1 release and although its not yet an RC and there
are some issues to work out, it was a breath of fresh air.

The biggest problem I had was understanding <what> kind of type to set
things to, but once I sorted that out for a component, it made working
with it later much easier.

It not clean yet which made it a bit of a pain and I can understand
why some would balk, but I can *definitely* see the joy on the
horizon.

that's my "personal experience" rather that my "professional opinion".


- Brill Pappin

On Wed, Jun 4, 2008 at 2:40 AM, Igor Vaynberg <igor.vaynberg@...> wrote:

> On Tue, Jun 3, 2008 at 11:30 PM, Eelco Hillenius
> <eelco.hillenius@...> wrote:
>> On Tue, Jun 3, 2008 at 10:37 PM, Igor Vaynberg <igor.vaynberg@...> wrote:
>>> i think we should have qualified this rfi with a requirement that
>>> responders use 1.4 on a non-trivial project...these things only become
>>> apparent from real-world day-to-day usage. anything else is pretty
>>> much speculation.
>>
>> As for speculation... I don't agree. I haven't converted yet, but it
>> is easy enough to just look at any old piece of code I'm working on
>> now and imagine what it will look like after changing to 1.4.
>
> and there are also a lot of pain points that you will not imagine that
> do exist :) i am wondering how many of the "keep as is in trunk" votes
> came from people who only imagined what their code would look like and
> havent actually hit the numerous pain points those of us who did code
> gainst it hit.
>
> i was of the "generify component and model" mind while i was
> generifying the framework, but after coding against it i began to see
> some of the ugliness and now my mind is almost changed.
>
> -igor
>
>
>>
>> Eelco
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Brill Pappin]

If the type of component is getting in the way doesn't that mean the
problem (non-trivial) component may need to be redesigned?

- Brill Pappin

On Wed, Jun 4, 2008 at 2:50 AM, Jan Kriesten <jan.kriesten@...> wrote:

>
>
>> i was of the "generify component and model" mind while i was
>> generifying the framework, but after coding against it i began to see
>> some of the ugliness and now my mind is almost changed.
>
> yep, day to day usage is the main point.
>
> i came to that conclusion as well when i was trying to migrate somewhat
> non-trivial use of wicket to 1.4 base. the standard components like link et
> al aren't the real problem (though it doesn't look pretty), it gets
> complicated when you're using "non-trivial" components (like datatable and
> their dependents) where the type on the component gets in your way.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Brill Pappin]

I agree with that and I think that is *the* key point.
If implementing regular language features exposes a flaw, fix the flaw.

I'm one of those that would rather have to refactor my code to
"upgrade" to a new major version than try and work around some "flaw"
just to maintain compatibility.

- Brill Pappin

On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
<eelco.hillenius@...> wrote:
[...]
> Personally, I think the whole generics business exposes that the
> one-one relation between components and models is flawed. Without
> generics this isn't much of a problem, just the odd unused member and
> constructor, but as generics aren't as 'optional' it is all very in
> your face suddenly.
[...]

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Brill Pappin]

Thats a pretty major api change (although it looks simple) maybe that
should be in the next major release?

- Brill

On Wed, Jun 4, 2008 at 1:30 PM, Patrick Angeles <patrick@...> wrote:

>
>
> igor.vaynberg wrote:
>>
>> component.detach() {
>>   for (field:fields) {
>>     if (imodel.class.isassignablefrom(field.gettype)) {
>>         ((imodel)field.get(this)).detach();
>>     }
>>   }
>>   onDetach();
>> }
>>
>
> +1
>
> I'm also for moving getModel()/getModelObject() out of Component and only
> putting them in things that really use models, like Label and
> FormComponent...
>
> I agree, though, that this should probably wait for 1.5...
>
> --
> 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-tp17589984p17652189.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...