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

[Gabor Szokoli]

Hi,

We haven't worked with 1.4 enough to form an opinion, but we'll
definitely upgrade to it for the next project.

On 6/3/08, Johan Compagner <jcompagner@...> wrote:
> If only... if only
>  we had this construct:
>
>  class Component<T default Void>

If only we had type inference :-)
Is this any nicer in scala?


Gabor Szokoli

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

[Johan Compagner]

really?
i still cant find information what will really be 1.7..

On Tue, Jun 3, 2008 at 1:29 PM, Hoover, William <whoover@...> wrote:

> In java 1.7 it will allow: TextField<Stirng> tf = new TextField("id");
> So, at least one of your wishes will come true ;o)
>
> I like the default idea.
>
> -----Original Message-----
> From: Johan Compagner [mailto:jcompagner@...]
> Sent: Tuesday, June 03, 2008 4:15 AM
> To: users@...
> Subject: Re: users, please give us your opinion: what is your take on
> generics with Wicket
>
> If only... if only
> we had this construct:
>
> class Component<T default Void>
> {
> }
>
> then all our problems with verbosity would be gone..
>
> TextField tf = new TextField("id") // just default Void
>
> Also only declare it once:
>
> TextField<Stirng> tf = new TextField("id");
>
>
> And both ways type guessing, so
>
> TextField<String> tf = new TextField("id", new Model()); //textfield and
> model are both just <String> or TextField tf = new TextField("id", new
> Model<String>()); // text field gets the type of its given model..
>
> I guess we should make a feature request for sun and then Vote on it
> with all of us!
> (and make noise on the internet...)
>
> johan
>
>
>
> On Tue, Jun 3, 2008 at 8:58 AM, Marcus Mattila
> <marcus.mattila@...>
> wrote:
>
> > > 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)
> >
> > Agreed.
> >
> > +1 for NOT generifying everything, because most components are "set it
> > and forget it" => generifying everything is unnecessary clutter.
> >
> > I will continue to use Wicket whatever is decided, though :)
> >
> > -Marcus
> >
> > ---------------------------------------------------------------------
> > 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]

Type inference alone will not really help us
To kill the verbosity on components that are not used with models we need
something like <T default Void>

johan


On Tue, Jun 3, 2008 at 1:34 PM, Gabor Szokoli <szocske@...> wrote:

> Hi,
>
> We haven't worked with 1.4 enough to form an opinion, but we'll
> definitely upgrade to it for the next project.
>
> On 6/3/08, Johan Compagner <jcompagner@...> wrote:
> > If only... if only
> >  we had this construct:
> >
> >  class Component<T default Void>
>
> If only we had type inference :-)
> Is this any nicer in scala?
>
>
> Gabor Szokoli
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Jan Kriesten]

> If only we had type inference :-)
> Is this any nicer in scala?

in scala you wouldn't have to have the getModel/getModelObject within Component
in the first place (you could use mixins for this purpose).

--- Jan.


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

[Edmund Urbani]

Gabor Szokoli wrote:

> Hi,
>
> We haven't worked with 1.4 enough to form an opinion, but we'll
> definitely upgrade to it for the next project.
>
> On 6/3/08, Johan Compagner <jcompagner@...> wrote:
>> If only... if only
>>  we had this construct:
>>
>>  class Component<T default Void>
>
> If only we had type inference :-)
> Is this any nicer in scala?
>
>
> Gabor Szokoli
>

I haven't used 1.4 either, but I've been following the discussion and from my
experience with 1.3 I'd say that generifying models is definately a good idea.
+1 for that

I'm not so sure about generifying the components though. I think the benefit
would not be that great and it may very well be more trouble than it's worth -
especially when writing/extending components for your own needs.

  Edmund

--
Liland ...does IT better

Liland IT GmbH
Software Architekt
email: Edmund.Urbani@...

office: [phone]  | fax: [phone]
http://www.Liland.at

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

[Gabor Szokoli]

On 6/3/08, Jan Kriesten <jan.kriesten@...> wrote:
>
>
> > If only we had type inference :-)
> > Is this any nicer in scala?
> >
>
>  in scala you wouldn't have to have the getModel/getModelObject within
> Component in the first place (you could use mixins for this purpose).

I was thinking about using the existing wicket 1.4 API from scala, if
that's any more comfortable.


Gabor Szokoli

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

[John Krasnay]

On Mon, Jun 02, 2008 at 11:36:33PM -0400, Brill Pappin wrote:

> Ahh... But there in lines the real point.
>
> What happens 2 years down the road when you need to modify that component?
> A) if its not typed then you hunt around and try and find out what it was...
> Maybe you do a println of the fqn...
> B) its typed... Your done.
>
> Even the time it takes to "discover" the model has direct bearing on ROI
> (although a lot of developers tend not to think on it much, we all depend on
> it) and the stats (and experience) say 80% of your work is maintenance.
>
> So, forget the 20%, lets chew away some of that 80%.
>
> - Brill Pappin
>

If I create a custom component that needs a particular type of model,
I would absolutely used a typed model. That's precisely where generics
are useful. What I'm talking about is not custom components but regular
everyday usage like this:

  WebMarkupContainer<Void> row = new WebMarkupContainer<Void>("row");
  row.add(new Label<String>("nameLabel", new ResourceModel<String>("name")));
  row.add(new TextField<String>("name"));

The type specifications on WebMarkupContainer, Label, and TextField buy
me nothing, because I never call getModel() or getModelObject() on them.

OTOH, suppose we don't genericize component. I can still realize the value
of typed models by simply storing my own model instead of using the
model property of Component:

public class MyPanel extends Panel {

  private IModel<Widget> model;

  public MyPanel(String id, IModel<Widget> model) {
    this.model = model;
  }

  public IModel<Widget> getWidgetModel() {
    return model;
  }

  public void someMethod() {
    // Look ma, no cast!
    getWidgetModel().getObject().frobnicate();
  }

  public void onDetach() {
    super.onDetach();
    model.detach();
  }
}

Remembering to override onDetach is a bit of a drag, but I think overall
I'm in for less work doing this where it's needed than the noise created
where it's not needed with a genericized Component.

jk

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

[Jan Kriesten]

Hi Gabor,

> I was thinking about using the existing wicket 1.4 API from scala, if
> that's any more comfortable.

I tried to migrate a bigger project from 1.3 to 1.4 api - and it isn't really
more comfortable. It's easier to do one or two casts than trying to conform the
generics Component structure. Especially since there are cases with 1.4 generics
(like StringResourceModel) which sometimes aren't recognized as IModel<String>
(which of course is more a Scala than a Wicket problem)...

Best regards, --- Jan.




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

[whoover]

Look in the section "Laguage Proposals" > "Shorter Instance Creations"
in:
http://blogs.sun.com/dannycoward/resource/Java7Overview_Prague_JUG.pdf

Other useful links:

http://blogs.sun.com/ahe/resource/java-se-7-EclipseCon-2007.pdf

http://puredanger.com/techfiles/java7.pdf 

-----Original Message-----
From: Johan Compagner [mailto:jcompagner@...]
Sent: Tuesday, June 03, 2008 7:47 AM
To: users@...
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket

really?
i still cant find information what will really be 1.7..

On Tue, Jun 3, 2008 at 1:29 PM, Hoover, William <whoover@...>
wrote:

> In java 1.7 it will allow: TextField<Stirng> tf = new TextField("id");

> So, at least one of your wishes will come true ;o)
>
> I like the default idea.
>
> -----Original Message-----
> From: Johan Compagner [mailto:jcompagner@...]
> Sent: Tuesday, June 03, 2008 4:15 AM
> To: users@...
> Subject: Re: users, please give us your opinion: what is your take on
> generics with Wicket
>
> If only... if only
> we had this construct:
>
> class Component<T default Void>
> {
> }
>
> then all our problems with verbosity would be gone..
>
> TextField tf = new TextField("id") // just default Void
>
> Also only declare it once:
>
> TextField<Stirng> tf = new TextField("id");
>
>
> And both ways type guessing, so
>
> TextField<String> tf = new TextField("id", new Model()); //textfield
> and model are both just <String> or TextField tf = new TextField("id",

> new Model<String>()); // text field gets the type of its given model..
>
> I guess we should make a feature request for sun and then Vote on it
> with all of us!
> (and make noise on the internet...)
>
> johan
>
>
>
> On Tue, Jun 3, 2008 at 8:58 AM, Marcus Mattila
> <marcus.mattila@...>
> wrote:
>
> > > 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)
> >
> > Agreed.
> >
> > +1 for NOT generifying everything, because most components are "set
> > +it
> > and forget it" => generifying everything is unnecessary clutter.
> >
> > I will continue to use Wicket whatever is decided, though :)
> >
> > -Marcus
> >
> > --------------------------------------------------------------------
> > - 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@...

[jwcarman]

On Tue, Jun 3, 2008 at 8:46 AM, Jan Kriesten <jan.kriesten@...> wrote:

>
> Hi Gabor,
>
>> I was thinking about using the existing wicket 1.4 API from scala, if
>> that's any more comfortable.
>
> I tried to migrate a bigger project from 1.3 to 1.4 api - and it isn't
> really more comfortable. It's easier to do one or two casts than trying to
> conform the generics Component structure. Especially since there are cases
> with 1.4 generics (like StringResourceModel) which sometimes aren't
> recognized as IModel<String> (which of course is more a Scala than a Wicket
> problem)...
>

Remember that 1.4 isn't done yet either.  Perhaps these are just
growing pains that the wicket team is going through (or perhaps it's
not).  We should outline these pain points and let the team know about
them (and perhaps a proposed solution), so that they have an
opportunity to address them.

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

[Jan Kriesten]

Hi James,

> Remember that 1.4 isn't done yet either.  Perhaps these are just
> growing pains that the wicket team is going through (or perhaps it's
> not).

it's not... ;-)

No, really, I have invested quite some time to get comfortable with Components +
Generics. And I came to the conclusion: it's not worth it.

Regards, --- Jan.

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

[Jonas-21]

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 generifying component adds too much verbosity, considering
a lot of components don't even have a model.

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

[Anders Peterson-2]

Eelco Hillenius wrote:

> 1) Generifying* Wicket
>    [x] Can best be done like currently in the 1.4 branch, where models
>    [x] Can best be done in a limited fashion, where we only generify

Both are acceptable to me


> 2) How strongly do you feel about your choice above?
>    [x] I definitively won't be using 1.4. if Wicket doesn't go for my

Not sure about "definitely", but if IModel isn't generified I'll
evaluate other frameworks for my next project.


/Anders

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

[Stefan Simik]

I am one of adopters laterst release and I invested much time
for upgrading all our projects to 1.4M2 .

I think, that generification of Wicket has many positive impacts, but
also some negative impact on simplicity and ease of use.
I don't see too many advantages of fully typed components - the biggest win
for me, is that I directly see, what I have or what should be in the model.
I think, this is not worth the other problems.

Living with generics is a little bit harder, than living with no generics.
But I personally have no problem to live with it.

If I should say decision, based on my experience:
---------------------------------------------------------------
I think, that generification of Wicket involves a little bit more negative,
than positive effects, so - give it away. We loose som benefits, but
many other things, will be simpler.

Stefan Simik

[ryantxu]

>
>   [ 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.


ryan


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

[Patrick Angeles]

Eelco Hillenius 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.

We are on 1.4 trunk on a huge project (> 100k LOC) which we are still in the middle of converting as we started out on 1.3.x. I can say without a doubt that generic components do get in the way, and that there are only a few cases where we actually call getModelObject(), for which casting is an acceptable workaround.

I would go so far as saying, the concept of 1:1 Model:Component can be misleading. As a number of previous posters have indicated, and I can validate first-hand, most components are not model backed. In my case, and I even have a few components that are backed by more than one model. So another angle to consider is completely decoupling Model from Component. Instead you might have setModel(String id, IModel<?>) and getModel(String id)... The old getModel() would be the equivalent of calling getModel((String)null)... I understand that this is a huge API break, with marginal value, but it does express the Model:Component relationship a lot more clearly.

[mcomb]

>   [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@...

[Ned Collyer]

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.
   [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 find anon inner classes can benefit a lot from generics.  - This means  both imodel and component - but I think both are an improvement over not having generics.


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.

* Wicket is a breath of fresh air - with or without generics.  Just more fresh air with ;).


** It needs generics!

[Brill Pappin]

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@...

[igor.vaynberg]

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@...