Regarding the constructor change in 2.0,
in some of my components (in wicket 1.2) I used wicket 2.0 type constructor
where i could pass null as the parent.
In such a scenario I would have to add the child components explicitly.
When i passed a non-null value to the constructor the component
On Mar 6, 2007, at 2:12 PM, Eelco Hillenius wrote:
1) Who uses 2.0 for serious projects?
We're using 1.2.x for now.
2) What do you think of the constructor change? Do you prefer 1.3's
add style or 2.0's style of passing in the parent construction time.
Absolutely prefer the 1.3/1.2 style.
On Mar 7, 2007, at 7:31 AM, Ryan Sonnek wrote:
Just my 2 cents, but considering the *massive* API changes in other
opensource projects when releasing a major version, i don't think
providing users with an easy upgrade path is that important.
Look at struts for example. version 2.0 is a
the advantage is that the error points you to the place in java code where
the problem is instead of a place in markup.
-igor
On 3/8/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
I have been using 1.2.4 for some days. I think the current construct
works
well. If there is no overwhelming
We've gathered a lot of opinions by now (more are still welcome
though!) and I think we should let this sink in for a bit.
There are a couple of projects being built on 2.0 (see the replies in
this thread, but also
http://www.mail-archive.com/general@lists.ops4j.org/msg00240.html),
but so far,
Who will build the first vote engine using wicket so we will not have to
vote in the mailling list directly? :)
On 3/8/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
We've gathered a lot of opinions by now (more are still welcome
though!) and I think we should let this sink in for a bit.
There
All things equal I prefer the 1.x add() syntax, however I don't have a
good feel for the advantages/disadvantages that add() vs. new provide.
What I really want is generics/models.
Scott
-
Take Surveys. Earn Cash. Influence
It looks like quite a few people, more than I expected in fact,
weren't that crazy about the constructor refactor in the first place,
though some people like it better in general (me being one of them
though I see disadvantages as well, but also
-- before voting we should compare them by given usecases and construct it
with 1.x and 2.x constructors.
I prefer
1 rich internet application
2 highly personalized user interfaces for portal
3 CMS
to be our usecases.
Eelco Hillenius wrote:
We've gathered a lot of opinions by now (more are
feel free to go ahead and do that. looking forward to your analysis.
-igor
On 3/8/07, aozster [EMAIL PROTECTED] wrote:
-- before voting we should compare them by given usecases and construct
it
with 1.x and 2.x constructors.
I prefer
1 rich internet application
2 highly personalized user
I know how to do it with 1.x (actually already done some of them in previous
project) , but I don't know how to do it with 2.x constructors, can you give
me a clue if I want to create something like that?.
igor.vaynberg wrote:
feel free to go ahead and do that. looking forward to your
Hi Eelco,
On 3/6/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
1) Who uses 2.0 for serious projects?
Not right now. I use only official released versions, so now I'm
developing with 1.2.5 and planning to migrate to 1.3 as soon as it is
available.
2) What do you think of the constructor
It's not just about markup attributes in constructor. It's about knowing
the markup hierarchy in constructor. So the component can e.g. find out
in which form it is (needed for AjaxSubmitLink for example). Without
this you have to pass the form instance as constructor parameters, which
is
Hi,
I'm still a wicket newbie, so I can't comment much on the technical benefits
of one or the other way. From my experience on widget toolkits, I prefer to
use Swing (no need for the parent in the constructor) than SWT (requires the
parent in the constructor), mainly because I think it's easier
On 3/7/07, Matej Knopp [EMAIL PROTECTED] wrote:
I've been using trunk for some time and I really like the constructor
change.
Can't we fix somehow the problems we have with it rather than dropping
the entire effort? Can we make it possible to create component with null
parent and reparent it
We don't use 2.0 at my company, and I don't use it myself for
personal projects, so I'm not too worried
I'm not particularly interested in the constructor change, even if
the comparison to SWT being better than Swing was appealing at
first glance. Didn't you happen to say: « SWT has a
Hi there,
we just have decided to make a PaxWicket2 effort in OPS4J and have
invested some days into this. We are using Wicket2 for some projects,
and I think it is quite nice to work with. I have no opinion on what
is better, but whatever you do, please bite the bullet and be clear
about it.
We use Wicket 1.2.5 for development now and i think we will go into
production with 1.3. In additions to the ones that have already been
mentioned, I liked the Wicket 2.0 Converter design. The last time I looked
at it was while I writing the last chapter of the book and i had a smile
while
I am using 2.0 for development right now, with the intentions that by
the time I roll into production (3-6 months), 2.0 will be close to a
release version. If 2.0 should get scrapped, it would take me probably
a week or less to port back to 1.3, so I'm not too concerned about
that. What's
I don't think you'll find that discussion thread because that
decision was something I made before there was much if any
discussion. The reason it's the way it currently is has to do with
two things: (1) in the code you suggested, the parent has to
maintain a map from component name to
Here, we are using 1.2.x in production. Thinking of passing to 1.3, but the
rewrite would take way too much time to go with 2.0.
For us, it was a no brainer decision, why would we want to upgrade with that
much effort for peanuts (Not T-Bones). I don't think big production
environment will
is there a deadline for making the decision whether to keep 2.0 as it is
or go back to 1.3?
i am working on two projects which will go into production in the next
few weeks. guess the major work downgrading to 1.x is the lack of
generics, which i found out to be very useful.
cheers,
h.
Hello,
We are currently evaluating whether to use 1.2, 1.3 or 2.0 for a new
project. Given that 1.3 will have a RC very soon, and that the question
on W2.0 is even out there, we will go for 1.3 for sure.
If this is a more common sentiment, I would say: drop further
development for 2.0 as soon
Just my 2 cents, but considering the *massive* API changes in other
opensource projects when releasing a major version, i don't think
providing users with an easy upgrade path is that important.
Look at struts for example. version 2.0 is a *complete* rewrite and
requires users to do a lot of
On Wednesday, 07 March 2007 04:50 am, karthik Guru escreveu:
We use Wicket 1.2.5 for development now and i think we will go into
production with 1.3. In additions to the ones that have already been
mentioned, I liked the Wicket 2.0 Converter design. The last time I looked
at it was while I
In additions to the ones that have already been
mentioned, I liked the Wicket 2.0 Converter design. The last time I looked
at it was while I writing the last chapter of the book and i had a smile
while writing about the improved and better looking Converter (it had a typo
in the way the
I've been using 2.0 since wicket first branched, and remember being really
excited about some of the things the constructor change would allow me to
do, such as perform all kinds of ajax magic. It turns out that wicket ajax
support has become so sophisticated I haven't had to do any of those
Reverting the
constructor change will probably cost me a few days, but the end it will
probably be worth it. I have noticed recently a somewhat troubling trend.
You guys used to be very disciplined about adding features to 2.0 and then
backporting them to the other branches. Now it seems like
ummm.hell no. the big point of this is to get rid of having multiple
branches!
so what we will most likely do is drop 2.0
backport everything new and useful into 1.4 (or seems like even 1.3 since
you guys got such itchy fingers). at that point we will decide whether or
not we will make 1.3
backport everything new and useful into 1.4 (or seems like even 1.3 since
you guys got such itchy fingers).
Those itchy fingers are easily explained: we'd like to get in those
'missing' features in asap so that we don't have to worry about
backporting them in the future! Furthermore, don't play
yes i have been while there were legal issues unresolved (we were waiting on
other people for their iclas). now they all are afaik and we can do a
release. so lets concentrate on that.
if we do provide a new generified version, then lets make that 1.4 and make
1.3 the last jdk1.4 and put that
if we do provide a new generified version, then lets make that 1.4 and make
1.3 the last jdk1.4 and put that into maintenance. we dont have the
resources to fix bugs twice everywhere.
Even thought this is not a vote, I'd be +1 on that.
Eelco
I haven't looked into great detail about the constructor changes in 2.0
but if 2.0 is more elegant or has a better architecture I'm all for the
way it does things. I fancy better engineering and can usually get
over inconveniences caused by API incompatibilities but then again I
had Borland C++
Also, I think if we get rid of 2.0, we should never reuse that
version number to avoid any confusion.
hmm don't know about that.
That would be a bit strange
But if we now do simple revolution that 2.0 will be not there for a long
time
(1.3 -1.4 )
And maybe what was 3.0 would be now 2.0
If we all really believed the constructor change was for the better,
we wouldn't have had this discussion. So it is not just the fact that
we have to maintain two branches, but also that we (or at least a
sizable part of the team) don't believe the constructor change was for
the better. With such
2.0 could be the package rename for instance. It's just a number, no
big deal to me.
Eelco
On 3/7/07, Johan Compagner [EMAIL PROTECTED] wrote:
Also, I think if we get rid of 2.0, we should never reuse that
version number to avoid any confusion.
hmm don't know about that.
That would
I agree with Jonathan Locke 100%. The use of .add seems better and
cleaner to me, but I can live with the constructor change if it means
that other things work better.
On Tue, 2007-03-06 at 14:27 -0800, Jonathan Locke wrote:
i would like to see a list of what we'd lose by not supporting the
On Wed, 2007-03-07 at 00:52 +0100, Martijn Dashorst wrote:
The biggest problem I see is a matter of economics. Current
applications can't be upgraded to the constructor change economically.
Too much has to change to move in that direction.
I am one of the early adopters that will have to
Eelco Hillenius wrote:
Hi,
We (Wicket's developers) are having some discussion over 1.3 vs 2.0
and how difficult it is as a nun-funded project to spend so much time
synchronizing the branches.
A major issue in the discussion is that not everyone is convinced
anymore that the
On 3/7/07, aozster [EMAIL PROTECTED] wrote:
Eelco Hillenius wrote:
2) What do you think of the constructor change? Do you prefer 1.3's
add style or 2.0's style of passing in the parent construction time.
After I've read wiki about the constructor change I suddenly
oppose
this idea.
Hi,
We (Wicket's developers) are having some discussion over 1.3 vs 2.0
and how difficult it is as a nun-funded project to spend so much time
synchronizing the branches.
A major issue in the discussion is that not everyone is convinced
anymore that the constructor change in 2.0 is for the
What's the advantage of the new code (no, I'm not currently using
Wicket 2.0)? Is it processing performance? Memory usage? Is the
framework code a lot less complex? A little less complex?
[]s Gus
On 3/6/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
Hi,
We (Wicket's developers) are
On 3/6/07, Gustavo Hexsel [EMAIL PROTECTED] wrote:
What's the advantage of the new code (no, I'm not currently using
Wicket 2.0)? Is it processing performance? Memory usage? Is the
framework code a lot less complex? A little less complex?
Please see:
i would like to see a list of what we'd lose by not supporting the
constructor change. i actually prefer the add() usage and always
have. i just don't want us to forget why we originally wanted to
make the constructor change. the only two things i can recall are:
- better diagnostics, but i
pros:
* free to call any method in the constructor like getpage(), urlfor(), etc.
* access to markup attributes in constructor as opposed to render time
* fail at component instantiation time rather then render time if there is a
hierarchy-java mismatch - so you get a java line-precise error
Why does code explosion happen as a consequence of the constructor
change?
Gili
Igor Vaynberg wrote:
pros:
* free to call any method in the constructor like getpage(), urlfor(), etc.
* access to markup attributes in constructor as opposed to render time
* fail at component
just thinking out loud, there is no workaround for the constructor pros.
are there any important things people really /need/ to get done that we're
making impossible without the constructor change? i don't care to much
about accessing markup attributes in the constructor because i don't care
because the parent must be known at construction time and by YOU since YOU
are the one calling new. so if there is an indirection somewhere like there
is with the toolbars you have to use a factory in order to get the correct
parent passed to you by the component at a later time.
-igor
On
well it is useful when constructing javascript behaviors because they can
create urls to pass to javascript at construction time instead of doing it
at a later point (onattach?). but it is mere convinience.
-igor
On 3/6/07, Jonathan Locke [EMAIL PROTECTED] wrote:
just thinking out loud,
i don't care to much
about accessing markup attributes in the constructor because i don't care
much about driving code from markup.
If you create components that are based on or work together with
Javascript components, this is a nice feature to have. Driving code
from markup sounds more
yeah, with our new headercontributor stuff some of these problems no longer
matter
-igor
On 3/6/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
i don't care to much
about accessing markup attributes in the constructor because i don't
care
much about driving code from markup.
If you create
The biggest problem I see is a matter of economics. Current
applications can't be upgraded to the constructor change economically.
Too much has to change to move in that direction.
I do like the programming model, although I haven't used it in a
production system (as I am doing with 1.x).
Having
On Mar 6, 2007, at 2:12 PM, Eelco Hillenius wrote:
1) Who uses 2.0 for serious projects?
I'm hoping to roll my project out over the next few weeks, it uses
2.0. I don't have a lot of pages though, so porting wouldn't be a
problem.
2) What do you think of the constructor change? Do you
Eelco Hillenius wrote:
A major issue in the discussion is that not everyone is convinced
anymore that the constructor change in 2.0 is for the better. There
are pros and cons for sure, but we want to get your opinion on this.
I'm a committer, but I'm also a user, and I feel pretty strongly
3) If we would ever backtrack on the constructor change (*if*, don't panic
for now) how much trouble would that give you?
I don't believe that this would be a real problem. The task consists for
changig changing
new Component(this
into
this.add(new Component
in most cases.
code explosion?
i count 5 chars less for every component create! ;)
1.3: container.add(new Child(id));
2.0: new Child(container,id);
johan
:)
On 3/6/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
pros:
* free to call any method in the constructor like getpage(), urlfor(),
etc.
* access to
well as long as there are workarounds, i'm fine with dropping the
constructor change if everyone else seems to feel this way and there aren't
any better arguments for it.
Eelco Hillenius wrote:
i don't care to much
about accessing markup attributes in the constructor because i don't care
Well, I'm not a core committer , so dont have enough vision to talk about
the internal effects of the change, but as a user from the pre-1 versions
of wicket till now(1.2.5), here are some humble opinions:
pros:
* free to call any method in the constructor like getpage(), urlfor(),
etc.
*
As a user I'm very happy with the current features and possibilities in
wicket, and am only waiting for the changes(stateless forms,
Stateless pages, forms and links are already backported to 1.3!
page cache, ...
The SecondLevelCacheSessionStore? Already in 1.3 :)
) in 1.3. My main
On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote:
As a user I'm very happy with the current features and possibilities in
wicket, and am only waiting for the changes(stateless forms,
Stateless pages, forms and links are already backported to 1.3!
page cache, ...
The
60 matches
Mail list logo
