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 [EMAIL PROTECTED] wrote:
You will wait a long time for an example generated from the API
Well, in our case it would almost never be:
MyComponentMyModel mycom = new MyComponentMyModel();
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
On Tue, Jun 3, 2008 at 8:54 PM, Mike Comb [EMAIL PROTECTED] wrote:
Well, in our case it would almost never be:
MyComponentMyModel mycom = new MyComponentMyModel();
We don't have many of our own models, we use CompoundPropertyModel pretty
much exclusively (wrapping DAOs or javabeans). So the
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.
-igor
On Tue, Jun 3, 2008 at 10:31 PM, Eelco Hillenius
[EMAIL PROTECTED]
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.
2) How strongly do you feel about your choice above?
[ ] Whatever
Didnt you encounter the big thread (at least 100 messages) where we
discussed/voted going to 1.4? (and cool down dev on 1.3)
On 6/1/08, Ayodeji Aladejebi [EMAIL PROTECTED] wrote:
scan this user forum, you will realize that there is no high demand for
generics in wicket from users. I am yet to
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
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.
[X2] Can best be done in a limited fashion, where we only
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
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
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.
I had a production quality project with the old 2.0 branch
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.
This is the only solution that makes sense, the other options are
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.
2) How strongly do you feel about your choice above?
[x]
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.
Verbose VS Clarity, Clarity wins hands down.
2) How strongly
I agree with Antoine.
Guðmundur Bjarni
Antoine van Wel wrote:
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.
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
[ 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,
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.
Component generification
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
1) Generifying* Wicket
[X] Should be avoided, definitly. All this generics stuff is ruining my
wicket experience.
2) How strongly do you feel about your choice above?
[X] I might rethink upgrading if my choice doesn't win.
--
View this message in context:
1) Generifying* Wicket
[X] Should be avoided, definitly. All this generics stuff is ruining my
wicket experience.
2) How strongly do you feel about your choice above?
[X] I might rethink upgrading if my choice doesn't win.
--
View this message in context:
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
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.
2) How strongly do you feel about your choice above?
[x] I
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
On Mon, Jun 2, 2008 at 10:21 AM, richardwilko
[EMAIL PROTECTED] wrote:
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
Ok you example doesnt work..
You will need to cast there
Then IModel only only helps describing the constructor. After that you loose
the generics or you have to ofcourse keep the models and dont work anymore
directly with the components
So if we only do IModel and not component
then this will
yes thats why i am against Referendums (politically) :)
On Mon, Jun 2, 2008 at 4:27 PM, Hoover, William [EMAIL PROTECTED] wrote:
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:
I think its not quite that simple.
Certainly both sets of components should use generics (silly to have a
partial solution) but how its done is vital so that it doesn't become a huge
mess.
I'm one of the adopters of the M1 release and I've found it quite difficult
to keep things straight
I'd really like to know how it's ruining my wicket experience?
Can you please elaborate?
I agree that the M1 release of 1.4 was less than optimum, but not having
generics is annoying to people who have gotten used to using them.
- Brill Pappin
-Original Message-
From: mozvip
Clearly :)
However I think the wicket developers have to be careful here as doing wrong
will make a big mess :)
- Brill
-Original Message-
From: Hoover, William [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 10:27 AM
To: users@wicket.apache.org
Subject: RE: users, please give
On Mon, Jun 2, 2008 at 10:45 AM, Matej Knopp [EMAIL PROTECTED] wrote:
I'm not sure I like where this discussion is going. I don't see anyone
having any particular objections against current state. I think before
we even think of (partially) reverting generics we have to discuss
what's wrong
+1
-Original Message-
From: Brill Pappin [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 10:49 AM
To: users@wicket.apache.org
Subject: RE: users, please give us your opinion: what is your take on
generics with Wicket
I don't know, I think the discussion is going *toward*
+1
I would like to see what the major issues are as to why people are
rejecting model/component generics. None that I have seen so far are
that convincing- especially the complaints of verbosity.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of James
Why don't we use the Wiki page to list our *specific* gotchas we
encounter and try to come up with a solution for them. My guess is
that we can do so.
On Mon, Jun 2, 2008 at 11:03 AM, Hoover, William [EMAIL PROTECTED] wrote:
+1
I would like to see what the major issues are as to why people are
Hi Elco, hi Users,
first of all thanks a lot for trying generics in wicket in the first case.
I haven't really cared about em so far, too much. So thanks a lot for
the learning experience I'm going through right now.
[x] Can best be done in a limited fashion, where we only generify
IModel
I'm not sure I like where this discussion is going. I don't see anyone
having any particular objections against current state. I think before
we even think of (partially) reverting generics we have to discuss
what's wrong (except the verbosity of course, but that's not something
we can really do
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
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
I see your point... a referendum will only be as good as the current
state of the product that is being evaluated, and the expertise of those
doing the evaluation. It seems as though in this case that some of those
doing the evaluation have limited knowledge of what benefits generics
has to offer
Hi Elco, hi Users,
first of all thanks a lot for trying generics in wicket in the first case.
I haven't really cared about em so far, too much. So thanks a lot for
the learning experience I'm going through right now.
[x] Can best be done in a limited fashion, where we only generify
IModel
Hi,
I'm not sure I like where this discussion is going. I don't see anyone
having any particular objections against current state.
@matej_k:
ugh - you should count again... if I counted right, most of the responses yet
prefer 'Component' /not/ being touched by generics.
+1, I agree. I
On Mon, Jun 2, 2008 at 11:22 AM, Jan Kriesten [EMAIL PROTECTED] wrote:
@jwcarman:
There is an issue with generics on components which is leading into a big
mess - and as far as I can see, many objections are especially on that
topic! It might not be Wicket's fault, though, it might be a
Ahhh... there's a good starting point for the gotchas...
I agree. It is not a big issue to use Void when needed.
I doubt anyone would be using something like Class? extends Page?
extends IModelT unless they themselves are attempting to extend a
generic component that they want to extend its
Sounds like a good idea... Are you going to create it?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of James Carman
Sent: Monday, June 02, 2008 11:06 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
Hi,
But IMHO putting generics on Component is a bad design, since it per se
touches all of Wicket's Components without urgent need.
I *really* would like to see a clarification of this statement. In
Wicket the component and model are very tightly coupled. What is a *good
design*
On Mon, Jun 2, 2008 at 5:22 PM, Jan Kriesten [EMAIL PROTECTED] wrote:
Hi,
I'm not sure I like where this discussion is going. I don't see anyone
having any particular objections against current state.
@matej_k:
ugh - you should count again... if I counted right, most of the responses
yet
I'm adding a Gotchas section now.
On Mon, Jun 2, 2008 at 11:13 AM, Hoover, William [EMAIL PROTECTED] wrote:
Sounds like a good idea... Are you going to create it?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of James Carman
Sent: Monday, June 02,
Hi Matej,
Question is, how many of those users actually use generified wicket on
day-to-day basis.
well, I did, and it really doesn't looked nice (and it doesn't work as it should
in the end, but that's another story).
The main point is (repeatedly) ignored by the people who are 'pro'
Agreed. I don't see a problem with having to type LinkVoid or
PageVoid instead of Link/Page. That's simply the way that generics
are implemented in Java. Are there places in the API where an end
user would have to type something like Class? extends Page? extends
IModelT? That way madness lies,
Good question... I would add to that and say:
how many of those users actually use generified wicket on day-to-day
basis?
how many of those users actually implement generics on day-to-day basis
(not just using them- like ListMyClass)?
-Original Message-
From: Matej Knopp [mailto:[EMAIL
Hi Sebastiaan,
I *really* would like to see a clarification of this statement. In
Wicket the component and model are very tightly coupled.
that's part of the problem, agreed.
What is a *good
design* alternative, where only IModel is generified? getModelObject()
returns Object? getModel
Can you elaborate?
What (anti)pattern(s) make you think that generics in the components are bad
design?
Besides the effort involved for the wicket developers, as a user I was
leaning the opposite way... But maybe I missed something (not unusual).
- Brill Pappin
-Original Message-
From:
If you use more than one type of model for a given component I would
hardly say that it is only a fraction of the time. Do you use only one
type of model on all your components? :o)
The use of Void is not an obscure workaround. Why do you think they have
it? I think it's intent is very clear if
James Carman wrote:
I'm adding a Gotchas section now.
Your pallete gotcha seems more like a JIRA to me. :-) It's not really
about generics in general, but about a specific choice in 1 component
(which really seems incorrect to me, i.e., PECS).
One of the gotcha's I think is the
A raw type is a parameterized type in which the type parameters are not
filled in, i.e., new HashMap() (instead of new HashMapString, Integer()).
Just try to return one of your old (non-generified) HomePage.class
classes (i.e., HomePage extends WebPage instead of HomePage extends
WebPageVoid)
Yes, the trick here is to not muddy up Wicket for the newcomers.
Wicket needs to be easy to learn and understand in order for it to be
adopted by the masses!
On Mon, Jun 2, 2008 at 11:46 AM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
Question is, how many of those users are core committers. Not
Hi Sebastian,
What about getModel()? If componennt is not generified I'm really
wondering if the there is any benefit to generics at all... (I do really
think it will spawn lots of questions on the list as well).
what's the problem with getModel? If you specialize on a certain Component,
Why can't this be done the way the java API does it, and allow people to use
it or not as they want?
Wicket is pretty clean in terms of the API, and there are interfaces for
most things... So what's the problem with adding the generics to the
interfaces?
AFAIK this would allow them to be ignored
Hi William,
If you use more than one type of model for a given component I would
hardly say that it is only a fraction of the time. Do you use only one
type of model on all your components? :o)
read again - I said 70% of my components don't have a Model...
The use of Void is not an obscure
Brill Pappin wrote:
Why can't this be done the way the java API does it, and allow people to use
it or not as they want?
Wicket is pretty clean in terms of the API, and there are interfaces for
most things... So what's the problem with adding the generics to the
interfaces?
AFAIK this would
I'm likely missing something here, but why would you want to return
something other than a *Page object? Wouldn't that cause some issues with
the application?
Maybe I don't understand what you mean by raw type.
- Brill Pappin
-Original Message-
From: Sebastiaan van Erk [mailto:[EMAIL
Lets not forget the stats we're all aware of (or should be) that 80% of
resources in software development are in maintenance... If I'm looking at my
ROI, then my developers can type a few extra words in order to reduce that
resource load.
And lets face it; it *all* comes down to maintenance (and
On Mon, Jun 2, 2008 at 11:52 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
James Carman wrote:
I'm adding a Gotchas section now.
Your pallete gotcha seems more like a JIRA to me. :-) It's not really about
generics in general, but about a specific choice in 1 component (which
really seems
I read it, but I think most people will be using models more frequently
than 30% of the time. Personally, I use them 99% of the time.
-Original Message-
From: Jan Kriesten [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 11:54 AM
To: users@wicket.apache.org
Subject: Re: users,
+1
Even if its one of the built in composite models, you still kind of need
them for most things you do.
- Brill
-Original Message-
From: Hoover, William [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 11:59 AM
To: users@wicket.apache.org
Subject: RE: users, please give us your
On Sun, Jun 1, 2008 at 9:44 PM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
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
On Mon, Jun 2, 2008 at 3:54 PM, Martin Funk [EMAIL PROTECTED]
wrote:
There are quite some methods that don't return the component,
but its class. Maybe most prominently 'getHomePage()' in Application.
This used to have the signature:
public abstract Class getHomePage();
And a popular
Yes, property model (and compound friends) don't mix well with generics.
With generics a type safe alternative is wanted (and a very good start
is Matej and Johan's type-safe model implementation).
Regards,
Sebastiaan
Jan Kriesten wrote:
hi al,
The second is almost certainly worth doing.
hi william,
Wouldn't that infer that the component has to have generics, or am I
missing something here?
you miss something...
getModel/getModelObject would have to be non-final and overriden by the
specialized component (return types are covariant, so you can override object
with
Enlighten me with an example
-Original Message-
From: Jan Kriesten [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 12:23 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
hi william,
Wouldn't that infer
You really have to use it to appreciate the benefits. Quick glance
will just be scary :)
-Matej
On Mon, Jun 2, 2008 at 6:45 PM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
Question is, how many of those users actually use generified wicket on
day-to-day basis.
Common, a quick glance and
Then we are on the same page with one thing... some level in the
component hierarchy would have to be generic.
Your original example specified T getModel() - you must have meant T
getModelObject() ;o)
-Original Message-
From: Jan Kriesten [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02,
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 agree.
Eelco
-
To unsubscribe, e-mail:
hi william,
Enlighten me with an example
just like that:
Component { public object getModelObject(){ ... } }
FormComponentT extends Component { public T getModelObject() { ... } }
regards, --- jan.
-
To unsubscribe,
On Mon, Jun 2, 2008 at 12:11 PM, Sebastiaan van Erk [EMAIL PROTECTED] wrote:
A raw type is a parameterized type in which the type parameters are not
filled in, i.e., new HashMap() (instead of new HashMapString, Integer()).
Just try to return one of your old (non-generified) HomePage.class
You could use Java's covariant return types to override getModel() to
return a specific type. Which would mean that you would need to subclass
to simulate generics (with a new subclass for each type). Also, when
using anonymous subclasses it becomes rather pointless and you'd be back
to
On Mon, Jun 2, 2008 at 7:45 AM, Matej Knopp [EMAIL PROTECTED] wrote:
I'm not sure I like where this discussion is going. I don't see anyone
having any particular objections against current state. I think before
we even think of (partially) reverting generics we have to discuss
what's wrong
hi sebastiaan,
You could use Java's covariant return types to override getModel() to
return a specific type. Which would mean that you would need to subclass
to simulate generics (with a new subclass for each type).
not really, you can do generify your components from a certain level and
Eelco Hillenius [EMAIL PROTECTED] wrote:1) Generifying* Wicket
[X] They, the core developers, knows better then me
(everyday users doesn't have in-depth and extensive view on
generification pro and cons. As usual, to find a good compromise
may be _very_ tricky business).
2) How strongly do you
Wouldn't that infer that the component has to have generics, or am I
missing something here?
Something like...
public abstract class ComponentM extends IModelT, T implements
IClusterable, IConverterLocator {
...
public final M getModel(){
...
}
...
Question is, how many of those users actually use generified wicket on
day-to-day basis.
Common, a quick glance and comparing some of the code/ examples you
see with the code you write now (with 1.2/ 1.3) is enough to get a
good - and as far as I am concerned informed well enough - idea.
Eelco
hi al,
The second is almost certainly worth doing. That said, I use PropertyModel
more often than anything else, and that doesn't allow you to make any
guarantees anyway. :-/
good point. :-)
regards, --- jan.
-
To
On Mon, Jun 02, 2008 at 11:59:09AM -0400, Hoover, William wrote:
I read it, but I think most people will be using models more frequently
than 30% of the time. Personally, I use them 99% of the time.
Really? Haven't you heard of CompoundPropertyModel?
jk
I am currently using 1.4 M1 and here are my choices:
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.
2) How strongly
Hi all,
[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] I might rethink upgrading if my
I think you miss John's point, which is that when you use a
CompoundPropertyModel for a component, all its children typically do not
reference models explicitly.
Thus you typically use an explicit model on 30% of your components if you
have a form-heavy web-app; the other components use the
Wow, last time I checked CompoundPropertyModel is a model ;o)
-Original Message-
From: John Krasnay [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 1:22 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
On
Hello everyone,
I feel bad that a vote thread has been converted to one of discussion...
At this moment wicket is *for *creating custom components. If these custom
component writing gets complicated we will not be able to appreciate wicket
as much(as much as we do now).Generics will complicate the
I got the point, but I take things as people state them. It was stated
that 70% of the time models are not being used (such is the case for
LinkVoid). As you stated, they are being used indirectly. That is
different. If that is the case then I agree that the percentage of
components using model
Hi Atul,
Please read again the initial post from Eelco. He explicitly wrote:
Note that it is not a vote; we only want to get an idea of what you
think. and further away: Thanks in advance for everyone participating,
and pls feel free to explain yourself further beyond just answering
these
On Mon, Jun 02, 2008 at 03:05:46PM -0400, Hoover, William wrote:
I got the point, but I take things as people state them. It was stated
that 70% of the time models are not being used (such is the case for
LinkVoid). As you stated, they are being used indirectly. That is
different. If that is
My vote:
X - Can best be done like currently in the 1.4 branch, where models and
components are both generified
X - Whatever choice ultimately made, I'll happily convert/ start using 1.4
and up.
I have to modify that last sentence, though - because I will continue using
Wicket, because it's the
Hi Sebastiann,
just for clarifying my understanding of the vocabulary:
A_HomePage extends WebPage
and
B_HomePage extends WebPageVoid
are both non-generified java classes.
It is just that
A_HomePage extends the raw type of the generic type WebPageT
whereas
B_HomePage extends the parameterized
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
IMHO we should try to keep the topic on your take on generics, not on
your take on others take on generics. But while we're at it:
I've read over 100 emails on this thread, and nearly all of the ones
against keeping generics like they are currently implemented are from
people who do not fully
On Mon, Jun 2, 2008 at 9:33 PM, Martin Funk [EMAIL PROTECTED]
wrote:
Hi Sebastiann,
just for clarifying my understanding of the vocabulary:
A_HomePage extends WebPage
and
B_HomePage extends WebPageVoid
are both non-generified java classes.
No the last one is generified..
The first one
I agree with the Class? extends Page with @SuppressWarnings in the
framework code. It makes it easier, and there's no drawback either way.
Jeremy
On Mon, Jun 2, 2008 at 4:54 PM, Johan Compagner [EMAIL PROTECTED]
wrote:
On Mon, Jun 2, 2008 at 9:33 PM, Martin Funk [EMAIL PROTECTED]
wrote:
1) Generifying* Wicket
[x] Should be avoided, I prefer the way 1.3 works. Because it works. Please improve the framework in functional details. Make it even easier to use. Make is less verbose. Keep the API stable.
2) How strongly do you feel about your choice above?
[x] I might
Point!--but i thought it is intended to extract a survey kind of info(with
explanation if one has one)
Just that the information here is overflowing with untraceable debates
On Tue, Jun 3, 2008 at 12:47 AM, Bernard Niset [EMAIL PROTECTED] wrote:
Hi Atul,
Please read again the initial post
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.
2) How strongly do you feel about your choice above?
[X*]
101 - 200 of 222 matches
Mail list logo
