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 got
Maybe I don't understand what you mean by "raw type".
- 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 your take on
gene
ommitters. Not
> everybody is a generics wizz you know, nor has the need to become one.
> Most users want to just build web apps in a clean, self-documenting
> API that doesn't put too much burden upon them - conceptually and
> number of characters to type, read and understand.
>
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
don't know if I agree that it's a problem (I haven't seen anything
better yet).
What is a *good design* alternative, where only IModel is generified?
getModelObject() returns Object? getModel returns IModel?
IMHO the practical solution would be to leave generics from components
Question is, how many of those users are core committers. Not
everybody is a generics wizz you know, nor has the need to become one.
Most users want to just build web apps in a clean, self-documenting
API that doesn't put too much burden upon them - conceptually and
number of characters to
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
>
> 1) Generifying* Wicket
> [x] Should be avoided, I prefer the way 1.3 works. Because... (fill
> in your opinion here).
>
After seeing the impact that generics had on the codebase, I'm begining to
feel that it's not worth the effort. Trying to *JUST* generify model
scure workaround. Why do you think they have
it? I think it's intent is very clear if you understand what void
represents. The key point is that Java generics are not runtime generics
;o)
See above, the point is having in there for especially nothing to gain -
Just make reading harde
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
ebastiaan 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 your take on
generics with Wicket
James Carman wrote:
> I'm adding a "Gotchas" section now.
Your pallete gotcha seems
nance (and the cost of),
despite effort on the initial development.
One thing that means for me, is generics... Just like TDD, it reduces the
issue count (among other things).
- Brill Pappin
-Original Message-
From: Martijn Dashorst [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 1
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,
, please give us your opinion: what is your take on
generics with Wicket
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 sa
opinion: what is your take on
generics with Wicket
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
.
> [ ] 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
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 popul
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 w
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
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 th
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
Sent: Monday, June 02, 2008 12:34 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
hi william,
> Enlighten me with an example
just like that:
Component { public object getModelObject(){ ... } } FormComponent
exten
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
> 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: [E
hi william,
Enlighten me with an example
just like that:
Component { public object getModelObject(){ ... } }
FormComponent extends Component { public T getModelObject() { ... } }
regards, --- jan.
-
To unsubscribe, e-mail
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()).
>
> Just try to return one of your old (non-generified) HomePage.class classes
> (i.e
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 yo
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
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 ce
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
Wouldn't that infer that the component has to have generics, or am I
missing something here?
Something like...
public abstract class Component, 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.
Eelc
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 unsubscri
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 choic
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
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
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
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
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
#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
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
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
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
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
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
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
*] 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
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.
-
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
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
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
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
opinion: what is your take on
generics with Wicket
[...]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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
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
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
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
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
> 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.
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
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
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:
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
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
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
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
> 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
>
>
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
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
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
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
-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 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
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
- 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
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'
[ 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
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
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
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
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
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
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&
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
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
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
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
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
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
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
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
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
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
501 - 600 of 678 matches
Mail list logo
