On Wed, Jun 4, 2008 at 10:10 AM, Igor Vaynberg <[EMAIL PROTECTED]> 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();
> }
onent 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
>
>
way, 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: [EMAIL PROTECTED]
> For additional command
On Wed, Jun 4, 2008 at 10:05 AM, Martijn Dashorst
<[EMAIL PROTECTED]> 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
--
gt;> >> 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
On Wed, Jun 4, 2008 at 9:52 AM, Matej Knopp <[EMAIL PROTECTED]> 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 com
onent 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
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 wh
icket 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
anymor
> 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 ge
e.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17651064.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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 t
e 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 g
hi johan,
and remove getModel/getModelObject methods from component itself?
But then everybody that does use models have to implement it..
that would be the consequence with it's tradeoff.
i wouldn't have a problem with that though:
val myLabel = new Label('id') with StringModel( ":-P" )
b
anels (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
>
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 i
rate 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
&
e 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
alogs)
> 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
> constru
ent. 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'
hi stefan,
Maybe the posts like "I do not use Models" or "Only 20% or our
components have Models" come from the same background as my early wicket
adoption.
i don't think you use compoundpropertymodels very often, so your mileage may be
very different how often you use component models.
an
Igor Vaynberg wrote
>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'm one of the "keep as is in trunk" users and I use 1.4 tru
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 s
On Tue, Jun 3, 2008 at 11:30 PM, Eelco Hillenius
<[EMAIL PROTECTED]> wrote:
> On Tue, Jun 3, 2008 at 10:37 PM, Igor Vaynberg <[EMAIL PROTECTED]> 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
>> a
On Tue, Jun 3, 2008 at 10:37 PM, Igor Vaynberg <[EMAIL PROTECTED]> 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 speculat
ty
>> 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. Havi
g 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 so
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 ) on
every other object in the page is messy and confusing in my mind.
Telling people to use suppr
nerated 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 opin
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 interest
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 mymodel = new MyModel();
MyComponent mycom = new MyComponent();
And that&
sorry, still waiting for an example here...
-igor
On Tue, Jun 3, 2008 at 7:53 PM, Brill Pappin <[EMAIL PROTECTED]> 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 thin
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 requir
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
ng 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
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.
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A
[ 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 cho
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'
- 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
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
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
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 (which of course
hings we did in wicket: a bookmarkable paging navigator
>> (which is used across the site), components to show negative
>> percent/dollars in red, and a highlighting widget used to show matching
>> search results.
>>
>> We are using Wicket 1.4-trunk (as of ye
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2008 7:47 AM
To: users@wicket.apache.org
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..
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
gen
intenance.
>
> 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 ab
On 6/3/08, Jan Kriesten <[EMAIL PROTECTED]> 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 u
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 <[EMAIL PROTECTED]> wrote:
If only... if only
we had this construct:
class Component
If only we had type inference :-)
Is this
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 unsub
Type inference alone will not really help us
To kill the verbosity on components that are not used with models we need
something like
johan
On Tue, Jun 3, 2008 at 1:34 PM, Gabor Szokoli <[EMAIL PROTECTED]> wrote:
> Hi,
>
> We haven't worked with 1.4 enough to form an opinion, but we'll
> defin
> I like the default idea.
>
> -Original Message-
> From: Johan Compagner [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, June 03, 2008 4:15 AM
> To: users@wicket.apache.org
> Subject: Re: users, please give us your opinion: what is your take on
> generics with Wicket
>
>
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 <[EMAIL PROTECTED]> wrote:
> If only... if only
> we had this construct:
>
> class Component
If only we had type inference :-)
Is this any nicer in scal
ubject: 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
{
}
then all our problems with verbosity would be gone..
TextField tf = new TextField("id") // just default Void
Also only declare it once:
1.4-trunk (as of yesterday due to a fix we submitted).
> We migrated from 1.3.x to 1.4 mid-project. Getting used to generics took
> about 1 1/2 days, but was well worth the effort. Consider this a
> two-thumbs-up success story for generics.
>
> Thanks to the people on this list
e noise on the internet...)
johan
On Tue, Jun 3, 2008 at 8:58 AM, Marcus Mattila <[EMAIL PROTECTED]>
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 r
Johan Compagner wrote:
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 WebPage
are both non-generified java classes.
No the last one is ge
http://www.agileskills2.org/EWDW
Axis2 tutorials freely available at http://www.agileskills2.org/DWSAA
--
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-tp17589984p17618364.html
Sent from the Wicket - User ma
o. Currently, I am always
passing models as parameter to the constructor of my custom components.
Those parameters are always named according to the expected type they
contain (e.g. fooModel if i expect an object of type Foo in there).
Therefore, generics could jump in quite easily and I am lo
> 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("num", Integer.class)
Agreed.
choice ultimately made, I'll happily convert/ start
using 1.4 and up.
--
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-tp17589984p17616380.html
Sent from the Wicket - User mailing list archive at Nabbl
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
;
> - Brill Pappin
>
> -Original Message-
> From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
> Sent: Monday, June 02, 2008 11:25 PM
> To: users@wicket.apache.org
> Subject: Re: AW: users, please give us your opinion: what is your take on
> generics with Wicket
>
>
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:[EMAIL PROTECTED]
Sent: Monday
page... Why would I even
bother to implement it at all?
- Brill Pappin
-Original Message-
From: Igor Vaynberg [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 11:25 PM
To: users@wicket.apache.org
Subject: Re: AW: users, please give us your opinion: what is your take on
generics wit
02, 2008 6:05 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
I agree with the Class with @SuppressWarnings in the
framework code. It makes it easier, and there's no drawback either way.
Jeremy
On Mon, Jun 2, 2008 at
opinion: what is your take on
generics with Wicket
[...]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
d.
>
> 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 importan
From: John Krasnay [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 3:28 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
On Mon, Jun 02, 2008 at 03:05:46PM -0400, Hoover, William wrote:
> I got the point, but I take thi
riginal Message-
From: atul singh [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 2:25 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
Hello everyone,
I feel bad that a vote thread has been converted to one of d
your opinion: what is your take on
generics with Wicket
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 HashMap()).
>
> Ju
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
On Mon, Jun 2, 2008 at 8:24 PM, Timo Rantalaiho <[EMAIL PROTECTED]> wrote:
> On Mon, 02 Jun 2008, Igor Vaynberg wrote:
>> i am willing to drop component model support if the following can be met:
>
> "component model support" -- ?
generifying component for the sake of having a generified model.
-
0% is complete noise...
verbousity might not be wicket's problem, but using a verbose api
sucks. generics fit for collections because there is never a case
where you would want a collection without putting/getting something
out of it.
-igor
On Mon, Jun 2, 2008 at 7:48 PM, James Carman <[EM
On Mon, 02 Jun 2008, Igor Vaynberg wrote:
> i am willing to drop component model support if the following can be met:
"component model support" -- ?
> certain constructors stay generified to document certain aspects, eg
> dropdownchoice constructor should be generified.
>
> support generificati
On Mon, Jun 2, 2008 at 10:30 PM, Jeremy Thomerson
<[EMAIL PROTECTED]> wrote:
> Basically, my feeling remains the same - generics are part of Java, so Java
> programmers are going to have to get use to them. They are very valuable
> when you need them. We just have to be
rting, etc. The use of generics has greatly
cleaned up and improved the code for all these components.
Basically, my feeling remains the same - generics are part of Java, so Java
programmers are going to have to get use to them. They are very valuable
when you need them. We just have to be caref
Also, since all my pages subclass my BasePage, all I had to do was change
*that* page to subclass Page and voila, all my pages were proper.
I also created the following models to simply my life: DateModel,
IntegerModel, DoubleModel, etc. I did some fancier stuff with Generics,
including a decent
*] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.
* Note that we just went live with http://online.ddpoker.com/ on 1.4 trunk
using generics. I'd prefer not to backtrack, but will if that's what the
developers decide.
Having gone through a conversion of a br
/dollars
in red, and a highlighting widget used to show matching search results.
We are using Wicket 1.4-trunk (as of yesterday due to a fix we submitted).
We migrated from 1.3.x to 1.4 mid-project. Getting used to generics took
about 1 1/2 days, but was well worth the effort. Consider this a
two
e will not be able to appreciate
>> wicket
>> as much(as much as we do now).Generics will complicate the *extend* at the
>> moment for new user...I feel(after reading through everything). In
>> core-java
>> , fewer classes aim for extension by user. They rather are end pr
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 reth
I agree with the Class 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:
>
> > Hi Seba
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 WebPage
> are both non-generified java classes.
No the last one is generified..
The first
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 implem
object to a type, eg
when you call getmodelobject() or getmodel() on the component. a big
percentage of the time you bind the model to a property - like in form
components, or push in a model once and never access it again - like
in dropdownchoice choices model, generics offer you no benefit in
#x27;s the best. But I have already upgraded all of my
applications to use 1.4, and there wouldn't be any "happily" about it to
back it out and stop using generics for me. They are too valuable to lose.
I have been using 1.4 with generics since before M1 was released, with
nea
pe".
>>
>> - Brill Pappin
>>
>> -Original Message-
>> From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED] Sent: Monday, June
>> 02, 2008 11:53 AM
>> To: users@wicket.apache.org
>> Subject: Re: users, please give us your opinion: what is y
e received no value for
typing the generic syntax. I would be surprised if I explicitly call one
of these methods on more than about 20% of my Wicket component
instances.
So for me, it's not the verbosity of generics that is the problem. When
the syntax is helping you avoid a cast somewhere
te wicket
as much(as much as we do now).Generics will complicate the *extend* at the
moment for new user...I feel(after reading through everything). In core-java
, fewer classes aim for extension by user. They rather are end product to be
used, to be composed of.
The best way still for wicket is *t
TECTED] On Behalf
Of Al Maw
Sent: Monday, June 02, 2008 2:09 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
I think you miss John's point, which is that when you use a
CompoundPropertyModel for a component, all its
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
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 Mon, Jun 02, 2008 at 11:59:09AM -0400, Hoover, William wrote:
> > I rea
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 Mon
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 choic
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
-
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 f
.
> [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill
> in your opinion here).
> [ ] (anything other than these choices?)
I see the stronger-typing made possible with Generics as a step
forward for Java and for Wicket. I believe that Generics will impro
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
> 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.
Eelc
301 - 400 of 678 matches
Mail list logo
