subject:"\[Wicket\-user\] IMPORTANT\: your opinion on the constructor"


How about a hybrid system?

Is there a clear-cut way to know up-front which components have an
immutable parent versus others that might require it to change during
rendering time? If so, couldn't you require the use of constructors that
take a parent for components whose parents are immutable and then for
all other components use the add() paradigm?

It seems to me that any component that knows up-front that its parent
is supposed to change between renderings will not run any operations
that depend on that parent until render time -- hence no need to add a
isInitialized() sanity check from all your methods. All methods that
depend on the parent should only be invoked at render time and if the
component has no parent it will never be rendered in the first place
hence there is no reason to check isInitialized() again.

On the other hand, other components that require an immutable parent
can then require it in their constructor and their methods can
implicitly assume it exists without that isInitialized() check.

Gili



signature.asc
Description: OpenPGP digital signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in2.0

2007-03-08 Thread Eelco Hillenius

 How about a hybrid system?

 Is there a clear-cut way to know up-front which components have an
 immutable parent versus others that might require it to change during
 rendering time? If so, couldn't you require the use of constructors that
 take a parent for components whose parents are immutable and then for
 all other components use the add() paradigm?

The largest problem with that would be that it would be inconsistent
for users. So apart from whether this is achievable, I wouldn't like
it as it would be too confusing.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor

2007-03-08 Thread Eelco Hillenius

   going the other way 2.0-1.x should be trivial
 
  This is true. At least it should be a lot easier.

 I wouldn't be so confident.  In  1.x very often we need to refrain
 doing things in  the constructor, and have  to override onAttach()
 to  access the  parent.   So  it's not  just  about reverting  the
 constructor change,  it's also dealing with  the delayed hierarchy
 setup that 1.x forces you to cope with.

True. But the funny thing is it turns out we don't need to as often.
Especially not since the HeaderContributer was refined.

But indeed, YMMV.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in2.0


Alternatively:

1) Components are POJOs. Users can define whatever constructor they want.

2) Users always use add() to associate a parent with a component but you
move the component wiring out of the constructor and into a onWire()
method. Now, whenever the hierarchy/parent changes onWire() gets
invoked. So components with dynamic hierarchies get onWire() once per
rendering whereas components with static hierarchies only have this
method invoked once. Users can then remove isInitialized() so long as
they invoke their methods from inside onWire().

Gili

Eelco Hillenius wrote:
 How about a hybrid system?

 Is there a clear-cut way to know up-front which components have an
 immutable parent versus others that might require it to change during
 rendering time? If so, couldn't you require the use of constructors that
 take a parent for components whose parents are immutable and then for
 all other components use the add() paradigm?
 
 The largest problem with that would be that it would be inconsistent
 for users. So apart from whether this is achievable, I wouldn't like
 it as it would be too confusing.
 
 Eelco
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



signature.asc
Description: OpenPGP digital signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in2.0


this wont work.

-igor


On 3/8/07, cowwoc [EMAIL PROTECTED] wrote:



How about a hybrid system?

Is there a clear-cut way to know up-front which components have an
immutable parent versus others that might require it to change during
rendering time? If so, couldn't you require the use of constructors that
take a parent for components whose parents are immutable and then for
all other components use the add() paradigm?

It seems to me that any component that knows up-front that its
parent
is supposed to change between renderings will not run any operations
that depend on that parent until render time -- hence no need to add a
isInitialized() sanity check from all your methods. All methods that
depend on the parent should only be invoked at render time and if the
component has no parent it will never be rendered in the first place
hence there is no reason to check isInitialized() again.

On the other hand, other components that require an immutable
parent
can then require it in their constructor and their methods can
implicitly assume it exists without that isInitialized() check.

Gili


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0


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 reason, I prefer preserve the old
style.
 Why wicket team choose SWT style construct for 2.0? To prevent mistakes
like
 forgetting to add component to component tree?

The reasons are outlined here

http://cwiki.apache.org/WICKET/migrate-20.html#Migrate-2.0-Constructorchange
.

Mainly line precise early error reporting when the component hierarchy
mismatches with the hierarchy in the markup, and to enable users to do
a couple of things at construction time they now have to do
workarounds for (like doing getForm() or getMarkupId in the
constructor).

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-08 Thread Eelco Hillenius

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, people who reacted seem to be understanding and flexible
to go with us if we would decide to revert the constructor change.

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
http://www.mail-archive.com/general@lists.ops4j.org/msg00402.html).
Based on the replies in this thread, it seems that people find add
more intuitive and like the flexibility that gives you over the
tighter model of 2.0

I propose to start a real vote on what to do with the constructor
change somewhere next week. Until then, please feel free to keep
venting your opinions on this thread.

Regards,

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-08 Thread Marc-Andre Houle


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 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, people who reacted seem to be understanding and flexible
to go with us if we would decide to revert the constructor change.

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
http://www.mail-archive.com/general@lists.ops4j.org/msg00402.html).
Based on the replies in this thread, it seems that people find add
more intuitive and like the flexibility that gives you over the
tighter model of 2.0

I propose to start a real vote on what to do with the constructor
change somewhere next week. Until then, please feel free to keep
venting your opinions on this thread.

Regards,

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-08 Thread Scott Swank

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 the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in2.0


That's why I used the terminology onWire() as opposed to onAdd(). My
point was that you should shift the burden of isInitialized() away from
the end-user over to Wicket. When a component's ancestors (all the way
up to the top-most component) are connected the first time or changed at
some later time Wicket invokes onWire(), at which point the component
modifies its state accordingly. This behavior differs from onAttach() in
that the latter assumes that wiring will always take place at render
time. onWire() allows you to do the wiring either shortly after
construction time or at render-time depending on whether all ancestors
have been defined or not.

It guarantees that errors will be thrown as soon as technically 
possible.

Gili

Eelco Hillenius wrote:
 The problem with that is that the 2.0 constructor actually forced the
 whole parent hierarchy to be in place, while add in 1.x just means it
 is added to the parent without any guarantee the parent is added to
 the parent yet. So even if we would provide onWire (though onAdd would
 be better then) it wouldn't be safe to do things like getMarkupId.
 onAttach is safe for that, as by then the rendering phase is reached.
 
 Eelco
 
 
 On 3/8/07, cowwoc [EMAIL PROTECTED] wrote:
 Alternatively:

 1) Components are POJOs. Users can define whatever constructor they want.

 2) Users always use add() to associate a parent with a component but you
 move the component wiring out of the constructor and into a onWire()
 method. Now, whenever the hierarchy/parent changes onWire() gets
 invoked. So components with dynamic hierarchies get onWire() once per
 rendering whereas components with static hierarchies only have this
 method invoked once. Users can then remove isInitialized() so long as
 they invoke their methods from inside onWire().

 Gili

 Eelco Hillenius wrote:
 How about a hybrid system?

 Is there a clear-cut way to know up-front which components have an
 immutable parent versus others that might require it to change during
 rendering time? If so, couldn't you require the use of constructors that
 take a parent for components whose parents are immutable and then for
 all other components use the add() paradigm?
 The largest problem with that would be that it would be inconsistent
 for users. So apart from whether this is achievable, I wouldn't like
 it as it would be too confusing.

 Eelco

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



signature.asc
Description: OpenPGP digital signature
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in2.0


what happens when you move the component to another parent? will onWire be
called again? and if not can we have a method that will please? and then
another method if the component's hierarchy changes - a components ancestor
is moved.

point being only a small percentage of wicket components care about this,
and we provide a general solution which is onattach and ondetach, and will
not provide ten thousand other solutions that cover ten thousand esoteric
usecases users can come up with.

just my 2c.

-igor


On 3/8/07, cowwoc [EMAIL PROTECTED] wrote:



That's why I used the terminology onWire() as opposed to onAdd().
My
point was that you should shift the burden of isInitialized() away from
the end-user over to Wicket. When a component's ancestors (all the way
up to the top-most component) are connected the first time or changed at
some later time Wicket invokes onWire(), at which point the component
modifies its state accordingly. This behavior differs from onAttach() in
that the latter assumes that wiring will always take place at render
time. onWire() allows you to do the wiring either shortly after
construction time or at render-time depending on whether all ancestors
have been defined or not.

It guarantees that errors will be thrown as soon as technically
possible.

Gili

Eelco Hillenius wrote:
 The problem with that is that the 2.0 constructor actually forced the
 whole parent hierarchy to be in place, while add in 1.x just means it
 is added to the parent without any guarantee the parent is added to
 the parent yet. So even if we would provide onWire (though onAdd would
 be better then) it wouldn't be safe to do things like getMarkupId.
 onAttach is safe for that, as by then the rendering phase is reached.

 Eelco


 On 3/8/07, cowwoc [EMAIL PROTECTED] wrote:
 Alternatively:

 1) Components are POJOs. Users can define whatever constructor they
want.

 2) Users always use add() to associate a parent with a component but
you
 move the component wiring out of the constructor and into a onWire()
 method. Now, whenever the hierarchy/parent changes onWire() gets
 invoked. So components with dynamic hierarchies get onWire() once per
 rendering whereas components with static hierarchies only have this
 method invoked once. Users can then remove isInitialized() so long as
 they invoke their methods from inside onWire().

 Gili

 Eelco Hillenius wrote:
 How about a hybrid system?

 Is there a clear-cut way to know up-front which components
have an
 immutable parent versus others that might require it to change during
 rendering time? If so, couldn't you require the use of constructors
that
 take a parent for components whose parents are immutable and then for
 all other components use the add() paradigm?
 The largest problem with that would be that it would be inconsistent
 for users. So apart from whether this is achievable, I wouldn't like
 it as it would be too confusing.

 Eelco


-
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to
share your
 opinions on IT  business topics through brief surveys-and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user


-
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share
your
 opinions on IT  business topics through brief surveys-and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user





-
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share
your
 opinions on IT  business topics through brief surveys-and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-08 Thread Edward Yakop

 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
 http://www.mail-archive.com/general@lists.ops4j.org/msg00402.html).
 Based on the replies in this thread, it seems that people find add
 more intuitive and like the flexibility that gives you over the
 tighter model of 2.0
Personally I prefer the tighter model. What we did on pax-wicket 1.0
examples if I'm not mistaken will cause a higher penalty during
serialization/deserialization compared to pax-wicket 2.0.

However, If wicket-1.0 style .add() voted, please add generic support
to wicket 1.x.

Regards,
Edward Yakop

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in2.0


The point *was* that onWire should get called whenever the parent
changes (i.e. when moving a component to another parent). If one wishes
to listen for hierarchy changes one could implement some event listener
mechanism to that effect by overriding onWire() of the ancestor nodes
and have them fire an event down to interested descendants when onWire()
gets fired on them.

I don't claim to solve all theoretical use-cases that users might come
up with, I am simply commenting on the existing use-cases that have been
brought up.

Gili

Igor Vaynberg wrote:
 what happens when you move the component to another parent? will onWire
 be called again? and if not can we have a method that will please? and
 then another method if the component's hierarchy changes - a components
 ancestor is moved.
 
 point being only a small percentage of wicket components care about
 this, and we provide a general solution which is onattach and ondetach,
 and will not provide ten thousand other solutions that cover ten
 thousand esoteric usecases users can come up with.
 
 just my 2c.
 
 -igor
 
 
 On 3/8/07, *cowwoc* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:
 
 
 That's why I used the terminology onWire() as opposed to
 onAdd(). My
 point was that you should shift the burden of isInitialized() away from
 the end-user over to Wicket. When a component's ancestors (all the way
 up to the top-most component) are connected the first time or changed at
 some later time Wicket invokes onWire(), at which point the component
 modifies its state accordingly. This behavior differs from
 onAttach() in
 that the latter assumes that wiring will always take place at render
 time. onWire() allows you to do the wiring either shortly after
 construction time or at render-time depending on whether all ancestors
 have been defined or not.
 
 It guarantees that errors will be thrown as soon as
 technically possible.
 
 Gili
 
 Eelco Hillenius wrote:
  The problem with that is that the 2.0 constructor actually forced the
  whole parent hierarchy to be in place, while add in 1.x just means it
  is added to the parent without any guarantee the parent is added to
  the parent yet. So even if we would provide onWire (though onAdd would
  be better then) it wouldn't be safe to do things like getMarkupId.
  onAttach is safe for that, as by then the rendering phase is reached.
 
  Eelco
 
 
  On 3/8/07, cowwoc [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:
  Alternatively:
 
  1) Components are POJOs. Users can define whatever constructor
 they want.
 
  2) Users always use add() to associate a parent with a component
 but you
  move the component wiring out of the constructor and into a onWire()
  method. Now, whenever the hierarchy/parent changes onWire() gets
  invoked. So components with dynamic hierarchies get onWire() once
 per
  rendering whereas components with static hierarchies only have this
  method invoked once. Users can then remove isInitialized() so long as
  they invoke their methods from inside onWire().
 
  Gili
 
  Eelco Hillenius wrote:
  How about a hybrid system?
 
  Is there a clear-cut way to know up-front which
 components have an
  immutable parent versus others that might require it to change
 during
  rendering time? If so, couldn't you require the use of
 constructors that
  take a parent for components whose parents are immutable and
 then for
  all other components use the add() paradigm?
  The largest problem with that would be that it would be inconsistent
  for users. So apart from whether this is achievable, I wouldn't
 like
  it as it would be too confusing.
 
  Eelco
 
 
 -
  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance
 to share your
  opinions on IT  business topics through brief surveys-and earn cash
 
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 -
 
  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to
 share your
  opinions on IT  business topics through brief surveys-and earn cash

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in2.0


my point is that we are a framework and we already provide what is needed to
make this and the entire superset of these kinds of things possible. our job
is to provide functionality needed for 90% of usecases and leave the other
10% possible. this falls into the 10%.

-igor


On 3/8/07, cowwoc [EMAIL PROTECTED] wrote:



The point *was* that onWire should get called whenever the parent
changes (i.e. when moving a component to another parent). If one wishes
to listen for hierarchy changes one could implement some event listener
mechanism to that effect by overriding onWire() of the ancestor nodes
and have them fire an event down to interested descendants when onWire()
gets fired on them.

I don't claim to solve all theoretical use-cases that users might
come
up with, I am simply commenting on the existing use-cases that have been
brought up.

Gili

Igor Vaynberg wrote:
 what happens when you move the component to another parent? will onWire
 be called again? and if not can we have a method that will please? and
 then another method if the component's hierarchy changes - a components
 ancestor is moved.

 point being only a small percentage of wicket components care about
 this, and we provide a general solution which is onattach and ondetach,
 and will not provide ten thousand other solutions that cover ten
 thousand esoteric usecases users can come up with.

 just my 2c.

 -igor


 On 3/8/07, *cowwoc* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:


 That's why I used the terminology onWire() as opposed to
 onAdd(). My
 point was that you should shift the burden of isInitialized() away
from
 the end-user over to Wicket. When a component's ancestors (all the
way
 up to the top-most component) are connected the first time or
changed at
 some later time Wicket invokes onWire(), at which point the
component
 modifies its state accordingly. This behavior differs from
 onAttach() in
 that the latter assumes that wiring will always take place at render
 time. onWire() allows you to do the wiring either shortly after
 construction time or at render-time depending on whether all
ancestors
 have been defined or not.

 It guarantees that errors will be thrown as soon as
 technically possible.

 Gili

 Eelco Hillenius wrote:
  The problem with that is that the 2.0 constructor actually forced
the
  whole parent hierarchy to be in place, while add in 1.x just means
it
  is added to the parent without any guarantee the parent is added
to
  the parent yet. So even if we would provide onWire (though onAdd
would
  be better then) it wouldn't be safe to do things like getMarkupId.
  onAttach is safe for that, as by then the rendering phase is
reached.
 
  Eelco
 
 
  On 3/8/07, cowwoc [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:
  Alternatively:
 
  1) Components are POJOs. Users can define whatever constructor
 they want.
 
  2) Users always use add() to associate a parent with a component
 but you
  move the component wiring out of the constructor and into a
onWire()
  method. Now, whenever the hierarchy/parent changes onWire() gets
  invoked. So components with dynamic hierarchies get onWire() once
 per
  rendering whereas components with static hierarchies only have
this
  method invoked once. Users can then remove isInitialized() so
long as
  they invoke their methods from inside onWire().
 
  Gili
 
  Eelco Hillenius wrote:
  How about a hybrid system?
 
  Is there a clear-cut way to know up-front which
 components have an
  immutable parent versus others that might require it to change
 during
  rendering time? If so, couldn't you require the use of
 constructors that
  take a parent for components whose parents are immutable and
 then for
  all other components use the add() paradigm?
  The largest problem with that would be that it would be
inconsistent
  for users. So apart from whether this is achievable, I wouldn't
 like
  it as it would be too confusing.
 
  Eelco
 
 

-
  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance
 to share your
  opinions on IT  business topics through brief surveys-and earn
cash
 

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-08 Thread aozster

-- 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 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, people who reacted seem to be understanding and flexible
to go with us if we would decide to revert the constructor change.

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
http://www.mail-archive.com/general@lists.ops4j.org/msg00402.html).
Based on the replies in this thread, it seems that people find add
more intuitive and like the flexibility that gives you over the
tighter model of 2.0

I propose to start a real vote on what to do with the constructor
change somewhere next week. Until then, please feel free to keep
venting your opinions on this thread.

Regards,

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

--
View this message in context:
http://www.nabble.com/IMPORTANT%3A-your-opinion-on-the-constructor-change-in-2.0-tf3358738.html#a9388671
Sent from the Wicket - User mailing list archive at Nabble.com.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

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 interfaces for portal
3 CMS
to be our usecases.

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

I propose to start a real vote on what to do with the constructor
change somewhere next week. Until then, please feel free to keep
venting your opinions on this thread.

Regards,

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys-and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-08 Thread aozster

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 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 interfaces for portal
3 CMS
to be our usecases.

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

I propose to start a real vote on what to do with the constructor
change somewhere next week. Until then, please feel free to keep
venting your opinions on this thread.

Regards,

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys-and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

--
View this message in context:
http://www.nabble.com/IMPORTANT%3A-your-opinion-on-the-constructor-change-in-2.0-tf3358738.html#a9388757
Sent from the Wicket - User mailing list archive at Nabble.com.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-07 Thread Filippo Diotalevi

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 change? Do you prefer 1.3's
 add style or 2.0's style of passing in the parent construction time.

I like Wicket 2.0 constructors because they allow to access the
hierarchy of the component at construction time, and make it more
difficult (if not impossible) to forget to add an element to the
current component.
I haven't used it so much though.. and the examples Igor shows are
pretty scary.

 3) If we would ever backtrack on the constructor change (*if*, don't
 panic for now) how much trouble would that give you?

I'm not writing applications with W2, so it'd cause no troubles ;-)

-- 
Filippo Diotalevi
http://www.diotalevi.com
http://www.jugmilano.it

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-07 Thread Matej Knopp

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 rather ugly imho.

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 afterwards? (Just thinking loud)

I know the code is more verbose, but there are also benefits. I 
personally don't mind couple of factory methods.

What I'm not sure about are the generics. Compared to 1.x, it really 
gets in my way. And the benefits are not so great IMHO. It just makes 
things more complicated and longer.

-Matej

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 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.
 
 Please help us out giving your opinion. We want to know:
 
 1) Who uses 2.0 for serious projects?
 
 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.
 
 3) If we would ever backtrack on the constructor change (*if*, don't
 panic for now) how much trouble would that give you?
 
 Please don't be shy giving your opinion. This is an important issue in
 the future development of Wicket.
 
 Regards,
 
 Eelco
 
 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-07 Thread Xavier Hanin


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 to read when
you explicitly call the add method (I don't like calling new and doing
nothing with the instance I created, simply because the constructor is
enough). The example of DefaultDataTable show also the complexity of this
approach in some cases.

But the most important IMO is the developer time it requires to maintain the
two branches with these differences. The time spent on backporting and
forward porting is time which is not spent on testing, bug fixing and new
features. So I think this change isn't really worth its cost.

My 2 c.

- Xavier

On 3/6/07, Eelco Hillenius [EMAIL PROTECTED] 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 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.

Please help us out giving your opinion. We want to know:

1) Who uses 2.0 for serious projects?

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.

3) If we would ever backtrack on the constructor change (*if*, don't
panic for now) how much trouble would that give you?

Please don't be shy giving your opinion. This is an important issue in
the future development of Wicket.

Regards,

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0


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 afterwards? (Just thinking loud)



no we cant. like i have explained before we did this, it is either all or
nothing. suppose you create a component with a null parent, and in its
constructor it adds a ajaxsubmitlink to itself. what happens now? the
submitlink needs the hierarchy, but its not there.

you also dont need to pass the form into ajaxsubmitlink in 1.3. in onattach
it can search for the form and add the behavior to itself then. you just
need some flag so you dont do it twice.

-igor
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-07 Thread Jean-Baptiste Quenot

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 much better
design that Swing ».  And the  parallel to Wicket 1.x/2.0 was easy
to draw.

But as  a committer I  am very unhappy  with having to  maintain 2
branches; most of the classes I change are out of sync between 1.x
and trunk.  So  I'm +1 for having one development  branch, JDK 1.4
is  fine for  me, we'll  switch to  JDK 1.5  in a  few months  (or
years?).  But  beware that some  bugfixes and useful  new features
went in trunk only,  so we should list them and  port them to 1.x,
as I [1]already started to do.

Also, I  think if we  get rid of 2.0,  we should never  reuse that
version number to avoid any confusion.
-- 
 Jean-Baptiste Quenot
aka  John Banana   Qwerty
http://caraldi.com/jbq/

[1] http://cwiki.apache.org/confluence/display/WICKET/To+Sync+Between+Branches

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in2.0

2007-03-07 Thread Dipu


We are still using 1.2.1 and 1.2.5 for our production and near production 
projects.


Thanks
Dipu


- Original Message - 
From: Eelco Hillenius [EMAIL PROTECTED]
To: Wicket User List wicket-user@lists.sourceforge.net
Sent: Tuesday, March 06, 2007 10:12 PM
Subject: [Wicket-user] IMPORTANT: your opinion on the constructor change 
in2.0


 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 better. There
 are pros and cons for sure, but we want to get your opinion on this.

 Please help us out giving your opinion. We want to know:

 1) Who uses 2.0 for serious projects?

 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.

 3) If we would ever backtrack on the constructor change (*if*, don't
 panic for now) how much trouble would that give you?

 Please don't be shy giving your opinion. This is an important issue in
 the future development of Wicket.

 Regards,

 Eelco

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share 
 your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in2.0

2007-03-07 Thread Janos Cserep


Same here, 1.2.3 and 1.2.5 based projects in production, quite large
codebase, no intention to go to 2.0 until it finalizes.

--
János Cserép - [EMAIL PROTECTED]
Web: http://www.szeretgom.hu
Skype: cserepj
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in2.0

2007-03-07 Thread Korbinian Bachl

Hi,

im not yet using 2.0 for a serious project, but spent much time as it should
be a future technology here. What me worries is the inconsistence in the way
the dev now is handled... I mean, the 2.0 Style Constructor is not bad - it
needs rethinking and some time more code, but also makes (IMHO) the code
better understandable and avoids this ugly stupid chaining with .add() -
allows direct access of the markup etc.

I mainly focused on 2.0 as i wanted the JDK1.5 features - generics + easier
session by self referencing etc. - of course, you stumble into downsides as
well, like the unlogic (to me) way to now replace a component by another
one... 

Whatever you do with 2.0 (even if it means work for me) - if you do it, then
right and no way back: so please decide to keep or drop it ! - and then do
it within a deadline you publish out, so no users are confused and please
dont go the T* way where every new version is a completely new thing...
compability is important (some small api breaks are ok, but not too big ones
without providing alternatives - so think also for future needs in design
concerning the constructor).

Also please if you decide to not use the new constructor go on a JDK1.5 solo
dev path soon (do a 2.0 release -with or without constructor change - in
need for 1.5 and dont backport things to 1.X as this will lead that most
users will never look at the new version but stick to their path as they
still get some candy) - we already have JDK1.6 out and when jdk 1.7 is out
you should at least be at 1.5 level IMHO - if sb. is sitting on 1.4 he has a
problem (even some are still on 1.3 or 1.2!) but also can use the old wicket
versions;

these are my thoughts

Korbinian 
 

 -Ursprüngliche Nachricht-
 Von: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] Im Auftrag 
 von Eelco Hillenius
 Gesendet: Dienstag, 6. März 2007 23:13
 An: Wicket User List
 Betreff: [Wicket-user] IMPORTANT: your opinion on the 
 constructor change in2.0
 
 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 better. There are pros and cons for sure, but we want to 
 get your opinion on this.
 
 Please help us out giving your opinion. We want to know:
 
 1) Who uses 2.0 for serious projects?
 
 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.
 
 3) If we would ever backtrack on the constructor change 
 (*if*, don't panic for now) how much trouble would that give you?
 
 Please don't be shy giving your opinion. This is an important 
 issue in the future development of Wicket.
 
 Regards,
 
 Eelco
 
 --
 ---
 Take Surveys. Earn Cash. Influence the Future of IT Join 
 SourceForge.net's Techsay panel and you'll get the chance to 
 share your opinions on IT  business topics through brief 
 surveys-and earn cash 
 http://www.techsay.com/default.php?page=join.phpp=sourceforge
CID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-07 Thread Peter Neubauer

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. Maintaining two fully featured development branches is just
going to split the effort put into this great project. Either drop
Wicket2, and start over evaluating adding Generics to 1.x or, freeze
1.3 and push for W2.

Cheers

/oeter

On 3/6/07, Eelco Hillenius [EMAIL PROTECTED] 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 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.

 Please help us out giving your opinion. We want to know:

 1) Who uses 2.0 for serious projects?

 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.

 3) If we would ever backtrack on the constructor change (*if*, don't
 panic for now) how much trouble would that give you?

 Please don't be shy giving your opinion. This is an important issue in
 the future development of Wicket.

 Regards,

 Eelco

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-07 Thread karthik Guru


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 writing about the improved and better looking Converter (it had a typo
in the way the converter classes were named then though :)). Is it already
in 1.3?

Availability of the markup attributes at the time of construction was also
good.
But on the whole, I think 1.x is fine.

-- karthik --
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-07 Thread Aaron HIniker

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 important is that for us 2.0 users that we know sooner
than later if that is going to happen :)

My main reason for choosing 2.0 was jdk 1.5 support, and the long-term
picture that 2.0 would become the primarily used and supported branch by
the time I went into production (or at least getting very close).

The constructor change I like for the most part -- it seems to have
simplified my development a bit.  Not having to worry about calling
#add() is nice, and I haven't really run into any issues with code
explosion mentioned earlier in this thread.  I don't use markup to drive
components, so construction-time markup doesn't help me much.  A little
off-topic, but when I first started using wicket, I always thought it
would be more intuitive to do something like: 

panel.add( myComponent, myComponent );  

Which leaves the constructors clean, and makes it very easy to
choose/pass around components, because the markup id doesn't need to be
known except by the parent thats actually attaching the component.  I
can't remember why things never ended up that way... I'll have to search
for that discussion thread. 

In any case, whether 2.0 is scrapped or not won't affect me all that
much... luckily most of my development thus far hasn't been on the web
tier so I'm only a few thousand lines of code with 2.0 and could revert
back to 1.3 relatively easy.

Aaron


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-07 Thread Jonathan Locke



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 component rather 
than just a list or array of components, and maps are less space 
efficient (which matters to scalability) and (2) without passing 
the id into the component constructor, components have no 
name of their own, which is at the very least some small violation 
of OO principles which suggest that data be as local and hidden 
as possible.  It would have been possible in the past to still keep 
a list or array of children and only assign a name to a component 
when it's added, but that would have (1) broken a lot of code for 
not much reason and (2) had a certain magical non-intuitiveness 
to a user (since they would never have explicitly named the 
component they constructed, only added it to the parent container
with the name...) leaving them to not look for getName() or to
expect that might be null unless they set it.  It could be that I
made the wrong decision here, but it's a bridge we crossed
years ago.

jon


Aaron Hiniker-2 wrote:
 
 A little off-topic, but when I first started using wicket, I always
 thought it
 would be more intuitive to do something like: 
 
 panel.add( myComponent, myComponent );  
 
 Which leaves the constructors clean, and makes it very easy to
 choose/pass around components, because the markup id doesn't need to be
 known except by the parent thats actually attaching the component.  I
 can't remember why things never ended up that way... I'll have to search
 for that discussion thread. 
 

-- 
View this message in context: 
http://www.nabble.com/IMPORTANT%3A-your-opinion-on-the-constructor-change-in-2.0-tf3358738.html#a9352056
Sent from the Wicket - User mailing list archive at Nabble.com.


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-07 Thread Marc-Andre Houle

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 stop using 1.x anytime soon and the port to 2.0 will be too
complicated for many software.

My 2 cents as a user.

Marc

On 3/7/07, Jonathan Locke [EMAIL PROTECTED] wrote:

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 component rather
than just a list or array of components, and maps are less space
efficient (which matters to scalability) and (2) without passing
the id into the component constructor, components have no
name of their own, which is at the very least some small violation
of OO principles which suggest that data be as local and hidden
as possible. It would have been possible in the past to still keep
a list or array of children and only assign a name to a component
when it's added, but that would have (1) broken a lot of code for
not much reason and (2) had a certain magical non-intuitiveness
to a user (since they would never have explicitly named the
component they constructed, only added it to the parent container
with the name...) leaving them to not look for getName() or to
expect that might be null unless they set it. It could be that I
made the wrong decision here, but it's a bridge we crossed
years ago.

jon

Aaron Hiniker-2 wrote:

A little off-topic, but when I first started using wicket, I always
thought it
would be more intuitive to do something like:

panel.add( myComponent, myComponent );

Which leaves the constructors clean, and makes it very easy to
choose/pass around components, because the markup id doesn't need to be
known except by the parent thats actually attaching the component. I
can't remember why things never ended up that way... I'll have to search
for that discussion thread.

--
View this message in context:
http://www.nabble.com/IMPORTANT%3A-your-opinion-on-the-constructor-change-in-2.0-tf3358738.html#a9352056
Sent from the Wicket - User mailing list archive at Nabble.com.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-07 Thread Harald Gruber


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.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-07 Thread Erik van Oosten

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 as possible. In the arts world there is an 
expression: 'Kill your darlings'. I am afraid this is appropriate here 
as well.

I am sorry if Eelco en Martijn have to rewrite their book ;(

Regards,
Erik.


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

 Please help us out giving your opinion. We want to know:

 1) Who uses 2.0 for serious projects?

 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.

 3) If we would ever backtrack on the constructor change (*if*, don't
 panic for now) how much trouble would that give you?

 Please don't be shy giving your opinion. This is an important issue in
 the future development of Wicket.

 Regards,

 Eelco

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user
   

-- 
Erik van Oosten
http://www.day-to-day-stuff.blogspot.com/


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-07 Thread Ryan Sonnek

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 work to change.

I would rather have the wicket developers make these decisions based
on what's best for the Wicket API rather than what's best for users.
Just a thought...

On 3/7/07, Erik van Oosten [EMAIL PROTECTED] wrote:
 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 as possible. In the arts world there is an
 expression: 'Kill your darlings'. I am afraid this is appropriate here
 as well.

 I am sorry if Eelco en Martijn have to rewrite their book ;(

 Regards,
 Erik.


 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 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.
 
  Please help us out giving your opinion. We want to know:
 
  1) Who uses 2.0 for serious projects?
 
  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.
 
  3) If we would ever backtrack on the constructor change (*if*, don't
  panic for now) how much trouble would that give you?
 
  Please don't be shy giving your opinion. This is an important issue in
  the future development of Wicket.
 
  Regards,
 
  Eelco
 
  -
  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to share your
  opinions on IT  business topics through brief surveys-and earn cash
  http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 

 --
 Erik van Oosten
 http://www.day-to-day-stuff.blogspot.com/


 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-07 Thread Thomas R. Corbin

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 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 converter classes were named then though :)). Is it
 already in 1.3?

I agree about the nicer converter.


 Availability of the markup attributes at the time of construction was also
 good.
 But on the whole, I think 1.x is fine.

 -- karthik --

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

 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 converter classes were named then though :)). Is it already
 in 1.3?

Yep, since yesterday! :)

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in2.0

2007-03-07 Thread Gabor Szokoli

On 3/7/07, Korbinian Bachl [EMAIL PROTECTED] wrote:
 Also please if you decide to not use the new constructor go on a JDK1.5 solo
 dev path soon

+1 for this if I understand it right :-)
We are not committed to either version yet, do basic prototypes in
1.2, but untyped getModel()  is getting on my nerves already. (How did
we ever use java without generics?)
I am on principle against severe API changes unless they bring
significant benefits, but do not feel myself competent to judge the
current situation.


Gabor Szokoli

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-07 Thread James McLaughlin


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 things,
so downgrading shouldn't cause me any loss of features. 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 new features are
developed in any branch and then maybe or maybe not ported to the others.
That's definitely a train wreck waiting to happen, and it is understandably
a source of misery for all of you. Dump it if you need to, your collective
happiness is more important to me :).

It would be great to have a definitive list of 2.0 features that will be
lost, so I can plan ahead for any redesign if necessary. For example, I've
used generics (with mixed feelings) and covariance extensively, so these
will probably be more painful to lose than the constructor change. Will
these be jettisoned as well?

thx,
jim

On 3/6/07, Eelco Hillenius [EMAIL PROTECTED] 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 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.

Please help us out giving your opinion. We want to know:

1) Who uses 2.0 for serious projects?

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.

3) If we would ever backtrack on the constructor change (*if*, don't
panic for now) how much trouble would that give you?

Please don't be shy giving your opinion. This is an important issue in
the future development of Wicket.

Regards,

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

 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 new features are
 developed in any branch and then maybe or maybe not ported to the others.
 That's definitely a train wreck waiting to happen, and it is understandably
 a source of misery for all of you. Dump it if you need to, your collective
 happiness is more important to me :).

Thanks for supporting us.

 It would be great to have a definitive list of 2.0 features that will be
 lost, so I can plan ahead for any redesign if necessary. For example, I've
 used generics (with mixed feelings) and covariance extensively, so these
 will probably be more painful to lose than the constructor change. Will
 these be jettisoned as well?

It's really only about the constructor change. The constructor change
is probably the primary reason why it is tough to maintain the
separate branches, as they are so different.

I started a discussion about generics, but unfortunately, I didn't
check that what I was proposing was actually possible. Turns out it
isn't, so it looks like the generics will stay in there as is.

So, if we would go on ditching 2.0, we would still have two separate
branches (and maybe we just still keep calling it 2.0, no preferences
at this time) where - ideally - the only difference is that one is
based on 1.4 and the other on 1.5.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0


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 or 1.4 the last java1.4 version, and from then on move
on to java5 with the older version being in _maintenance_ mode.

at least that is what i think we should do.

-igor


On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote:


 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 new features
are
 developed in any branch and then maybe or maybe not ported to the
others.
 That's definitely a train wreck waiting to happen, and it is
understandably
 a source of misery for all of you. Dump it if you need to, your
collective
 happiness is more important to me :).

Thanks for supporting us.

 It would be great to have a definitive list of 2.0 features that will be
 lost, so I can plan ahead for any redesign if necessary. For example,
I've
 used generics (with mixed feelings) and covariance extensively, so these
 will probably be more painful to lose than the constructor change. Will
 these be jettisoned as well?

It's really only about the constructor change. The constructor change
is probably the primary reason why it is tough to maintain the
separate branches, as they are so different.

I started a discussion about generics, but unfortunately, I didn't
check that what I was proposing was actually possible. Turns out it
isn't, so it looks like the generics will stay in there as is.

So, if we would go on ditching 2.0, we would still have two separate
branches (and maybe we just still keep calling it 2.0, no preferences
at this time) where - ideally - the only difference is that one is
based on 1.4 and the other on 1.5.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

 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 such an
innocent kid, because you've been guilty of applying or at least
encouraging quite a few ajax and header contribution backports
yourself!

 at that point we will decide whether or
 not we will make 1.3 or 1.4 the last java1.4 version, and from then on move
 on to java5 with the older version being in _maintenance_ mode.

We have to take some responsibility here don't we? If we decide to
reverse the constructor change, that doesn't mean we just drop the
whole thing right away. As you have read in the thread so far, people
/are/ using those generics, so we /should/ provide a proper upgrade
path. And I mean very soon, not just in some distant future. So, yes,
we have to either keep 2.0 alive for bug fixes and stuff, or we have
to provide a version that is as close to 1.3 as possible, but with
generics/ java 5 support.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0


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 into maintenance. we dont have the
resources to fix bugs twice everywhere.

-igor


On 3/7/07, Eelco Hillenius [EMAIL PROTECTED] wrote:


 backport everything new and useful into 1.4 (or seems like even 1.3since
 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 such an
innocent kid, because you've been guilty of applying or at least
encouraging quite a few ajax and header contribution backports
yourself!

 at that point we will decide whether or
 not we will make 1.3 or 1.4 the last java1.4 version, and from then on
move
 on to java5 with the older version being in _maintenance_ mode.

We have to take some responsibility here don't we? If we decide to
reverse the constructor change, that doesn't mean we just drop the
whole thing right away. As you have read in the thread so far, people
/are/ using those generics, so we /should/ provide a proper upgrade
path. And I mean very soon, not just in some distant future. So, yes,
we have to either keep 2.0 alive for bug fixes and stuff, or we have
to provide a version that is as close to 1.3 as possible, but with
generics/ java 5 support.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

 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

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-07 Thread Chris Colman

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++ OWL 1.0 projects that had to get ported to OWL 2 when it
came out - coincidently the major changes in version 2.0 of that API
involved around the introduction of template (generics) based containers
instead of the Object based ones - 'de ja vu' with a 12 year delay!

Is there any possibility that 'backwards compatible' deprecated
constructors can be used to avoid breaking any existing code? Obviously
all new code should use the new constructors but the version 2.0 API
might be able to provide backwards compatible constructors also, a least
in the short term, to allow existing projects to integrate with the new
API 'right out of the box'.

Not sure if this is possible or already discussed but I thought I'd
throw this idea in the ring just in case no one had thought of it yet.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-07 Thread Johan Compagner


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

johan
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 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 controversy, it is probably better to stay on
the current course.

Don't worry, we're zealots and we'll go for what we believe is the
best solution at any time, even if that means more work :)

Eelco


On 3/7/07, Chris Colman [EMAIL PROTECTED] wrote:
 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++ OWL 1.0 projects that had to get ported to OWL 2 when it
 came out - coincidently the major changes in version 2.0 of that API
 involved around the introduction of template (generics) based containers
 instead of the Object based ones - 'de ja vu' with a 12 year delay!

 Is there any possibility that 'backwards compatible' deprecated
 constructors can be used to avoid breaking any existing code? Obviously
 all new code should use the new constructors but the version 2.0 API
 might be able to provide backwards compatible constructors also, a least
 in the short term, to allow existing projects to integrate with the new
 API 'right out of the box'.

 Not sure if this is possible or already discussed but I thought I'd
 throw this idea in the ring just in case no one had thought of it yet.

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

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

 johan



 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-07 Thread Philip A. Chapman

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
 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 can't recall exactly /what/ diagnostics we
 thought we'd get
 
  - ability to make component init dependent on parental context.  this might
 be either xml association or component data somehow.  i can't think of any
 times i've been screaming to do this, but can anyone give some of the best
 examples so we can evaluate what we'd be losing here?
 
 
 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 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.
  
  Please help us out giving your opinion. We want to know:
  
  1) Who uses 2.0 for serious projects?
  
  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.
  
  3) If we would ever backtrack on the constructor change (*if*, don't
  panic for now) how much trouble would that give you?
  
  Please don't be shy giving your opinion. This is an important issue in
  the future development of Wicket.
  
  Regards,
  
  Eelco
  
  -
  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to share
  your
  opinions on IT  business topics through brief surveys-and earn cash
  http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
  
  
 

-- 
Philip A. Chapman

Desktop and Web Application Development:
Java, .NET, PostgreSQL, MySQL, MSSQL
Linux, Windows 2000, Windows XP


signature.asc
Description: This is a digitally signed message part
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-07 Thread Philip A. Chapman

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 move in the reverse
direction should the Constructor change be taken out of 2.0.  Would it
be possible to depreciate the constructors that require the parent?

Other than that, I *love* generified components and models in wicket
2.0.  You'd have to pry those from my cold, dead fingers.


 I do like the programming model, although I haven't used it in a
 production system (as I am doing with 1.x).
 
 Having the model changes in 1.x will result in a lot of work, but not
 nearly as much as the c'tor change. The api changes will be less
 intrusive as you'll likely have less custom models than components.
 
 Wicket 2.0 is a beast and hard to support, especially since to support
 software in a good way, you need to eat your own dog food.
 
 One other thing: moving to Apache usually requires you to move the
 code base into the org.apache namespace. We opted to do that for 2.x
 only, as the API is already broken. In the remote possibility of
 freezing further development on 2.x, we should see what we need to do
 in the org.apache realm for 1.x
 
 If/when we need to make a decision between 1.x and 2.x, I'd rather
 drop 2.x and continue with 1.x then drop 1.x in favor of 2.x.
 
 Martijn
 
 On 3/6/07, Eelco Hillenius [EMAIL PROTECTED] 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 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.
 
  Please help us out giving your opinion. We want to know:
 
  1) Who uses 2.0 for serious projects?
 
  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.
 
  3) If we would ever backtrack on the constructor change (*if*, don't
  panic for now) how much trouble would that give you?
 
  Please don't be shy giving your opinion. This is an important issue in
  the future development of Wicket.
 
  Regards,
 
  Eelco
 
  -
  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to share your
  opinions on IT  business topics through brief surveys-and earn cash
  http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 
 

-- 
Philip A. Chapman

Desktop and Web Application Development:
Java, .NET, PostgreSQL, MySQL, MSSQL
Linux, Windows 2000, Windows XP


signature.asc
Description: This is a digitally signed message part
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-07 Thread aozster

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

Please help us out giving your opinion. We want to know:

1) Who uses 2.0 for serious projects?

I use 1.3 on a project already on production.

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.
Why ?
- Component should not rely on language level constructor for domain
specific life cycle ( It actually defines life cycle for JVM/CLR level
object,or component ), It should rely on component container life cycle
service which specify the life cycle method and contract for component
developer, init beforeAttach afterAttach beforeRender afterRender etc.
- Component architecture for specific domain like GUI should define
life cycle method that ensure which resources are avaliable in that
method.
- By assuming that component should have knowledge about the
enclosing structure in constructor, It means
Sturcture of the enclosing component should avaiable before it can be
constructed or
every components should know about the structure they will live in before
they can be constructed which make component more dependent.

3) If we would ever backtrack on the constructor change (*if*, don't
panic for now) how much trouble would that give you?

Please don't be shy giving your opinion. This is an important issue in
the future development of Wicket.

Regards,

Eelco

--
View this message in context:
http://www.nabble.com/IMPORTANT%3A-your-opinion-on-the-constructor-change-in-2.0-tf3358738.html#a9368245
Sent from the Wicket - User mailing list archive at Nabble.com.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0


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.
 Why ?
   - Component should not rely on language level constructor for
domain
 specific life cycle ( It actually defines life cycle for JVM/CLR level
 object,or component ),



constructors have nothing to do with the vm

It should rely on component container life cycle

 service which specify the life cycle method and contract for component
 developer, init beforeAttach afterAttach beforeRender afterRender etc.



wicket is not a managed framework. you are in charge of instantiation the
components, thus constructors.


  - Component architecture for specific domain like GUI  should define
 life cycle method that ensure which resources are avaliable in that
 method.



we do, but like i said we let you be in control of instantiation because we
believe that delivers you the most flexibility


  - By assuming that component should have knowledge about the
 enclosing structure in constructor, It means
 Sturcture of the enclosing component should avaiable before it can be
 constructed or
 every components should know about the structure they will live in
before
 they can be constructed which make component more dependent.



yes but this is a gui framework with markup. you cant really compare it to
layout manager gui frameworks. this is also a framework where you have
separation of concerns, designers, etc. so we have a few special
requirements.

-igor
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

[Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

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 better. There
are pros and cons for sure, but we want to get your opinion on this.

Please help us out giving your opinion. We want to know:

1) Who uses 2.0 for serious projects?

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.

3) If we would ever backtrack on the constructor change (*if*, don't
panic for now) how much trouble would that give you?

Please don't be shy giving your opinion. This is an important issue in
the future development of Wicket.

Regards,

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-06 Thread Gustavo Hexsel

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 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 better. There
 are pros and cons for sure, but we want to get your opinion on this.

 Please help us out giving your opinion. We want to know:

 1) Who uses 2.0 for serious projects?

 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.

 3) If we would ever backtrack on the constructor change (*if*, don't
 panic for now) how much trouble would that give you?

 Please don't be shy giving your opinion. This is an important issue in
 the future development of Wicket.

 Regards,

 Eelco

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

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: 
http://cwiki.apache.org/WICKET/migrate-20.html#Migrate-2.0-Constructorchange

And maybe Igor (and others?) can explain a bit about the pros and cons
he experiences after developing two projects with it.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-06 Thread Jonathan Locke

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 can't recall exactly /what/ diagnostics we
thought we'd get

- ability to make component init dependent on parental context. this might
be either xml association or component data somehow. i can't think of any
times i've been screaming to do this, but can anyone give some of the best
examples so we can evaluate what we'd be losing here?

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.

Please help us out giving your opinion. We want to know:

1) Who uses 2.0 for serious projects?

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.

3) If we would ever backtrack on the constructor change (*if*, don't
panic for now) how much trouble would that give you?

Please don't be shy giving your opinion. This is an important issue in
the future development of Wicket.

Regards,

Eelco

--
View this message in context:
http://www.nabble.com/IMPORTANT%3A-your-opinion-on-the-constructor-change-in-2.0-tf3358738.html#a9342589
Sent from the Wicket - User mailing list archive at Nabble.com.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

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 as opposed
to our error webpage

cons:

* code explosion
2.0: http://papernapkin.org/pastebin/view/4900
1.3: http://papernapkin.org/pastebin/view/4908

* hacks necessary for nontrivial components
GridView.populate()
http://papernapkin.org/pastebin/view/4902
notice fake1,fake2 parents necessary for child item instantiation and which
are later removed

* more limited in how the hierarchy is created since it MUST be created
top-down

* replacing components is less explicit.
1.3: a.replaceWith(new B());
2.0: new B(a.getParent(), a.getId());

-igor

On 3/6/07, Jonathan Locke [EMAIL PROTECTED] wrote:

- better diagnostics, but i can't recall exactly /what/ diagnostics we
thought we'd get

- ability to make component init dependent on parental context. this
might
be either xml association or component data somehow. i can't think of any
times i've been screaming to do this, but can anyone give some of the best
examples so we can evaluate what we'd be losing here?

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.

Please help us out giving your opinion. We want to know:

1) Who uses 2.0 for serious projects?

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.

3) If we would ever backtrack on the constructor change (*if*, don't
panic for now) how much trouble would that give you?

Please don't be shy giving your opinion. This is an important issue in
the future development of Wicket.

Regards,

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys-and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-06 Thread cowwoc

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 instantiation time rather then render time if there
is a hierarchy-java mismatch - so you get a java line-precise error as
opposed to our error webpage

cons:

* code explosion
2.0: http://papernapkin.org/pastebin/view/4900
1.3: http://papernapkin.org/pastebin/view/4908
http://papernapkin.org/pastebin/view/4908

* hacks necessary for nontrivial components
GridView.populate()
http://papernapkin.org/pastebin/view/4902
notice fake1,fake2 parents necessary for child item instantiation and
which are later removed

* more limited in how the hierarchy is created since it MUST be created
top-down

* replacing components is less explicit.
1.3: a.replaceWith(new B());
2.0: new B(a.getParent(), a.getId());

-igor

On 3/6/07, *Jonathan Locke* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:

- better diagnostics, but i can't recall exactly /what/ diagnostics we
thought we'd get

- ability to make component init dependent on parental
context. this might
be either xml association or component data somehow. i can't think
of any
times i've been screaming to do this, but can anyone give some of
the best
examples so we can evaluate what we'd be losing here?

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.

Please help us out giving your opinion. We want to know:

1) Who uses 2.0 for serious projects?

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.

3) If we would ever backtrack on the constructor change (*if*, don't
panic for now) how much trouble would that give you?

Please don't be shy giving your opinion. This is an important issue in
the future development of Wicket.

Regards,

Eelco

Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share
your
opinions on IT business topics through brief surveys-and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
mailto:Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
https://lists.sourceforge.net/lists/listinfo/wicket-user

--
View this message in context:

http://www.nabble.com/IMPORTANT%3A-your-opinion-on-the-constructor-change-in-2.0-tf3358738.html#a9342589

http://www.nabble.com/IMPORTANT%3A-your-opinion-on-the-constructor-change-in-2.0-tf3358738.html#a9342589
Sent from the Wicket - User mailing list archive at Nabble.com
http://Nabble.com.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-06 Thread Jonathan Locke

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
much about driving code from markup. but what about the others? are there
any useful things we'd lose?

i think i can live without the perfect error reporting as wicket error
reporting seems good enough to me now. it's almost certainly not worth a
code explosion to get this alone.

jon

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 instantiation time rather then render time if there is
a
hierarchy-java mismatch - so you get a java line-precise error as
opposed
to our error webpage

cons:

* code explosion
2.0: http://papernapkin.org/pastebin/view/4900
1.3: http://papernapkin.org/pastebin/view/4908

* hacks necessary for nontrivial components
GridView.populate()
http://papernapkin.org/pastebin/view/4902
notice fake1,fake2 parents necessary for child item instantiation and
which
are later removed

* more limited in how the hierarchy is created since it MUST be created
top-down

* replacing components is less explicit.
1.3: a.replaceWith(new B());
2.0: new B(a.getParent(), a.getId());

-igor

On 3/6/07, Jonathan Locke [EMAIL PROTECTED] wrote:

- better diagnostics, but i can't recall exactly /what/ diagnostics we
thought we'd get

- ability to make component init dependent on parental context. this
might
be either xml association or component data somehow. i can't think of
any
times i've been screaming to do this, but can anyone give some of the
best
examples so we can evaluate what we'd be losing here?

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.

Please help us out giving your opinion. We want to know:

1) Who uses 2.0 for serious projects?

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.

3) If we would ever backtrack on the constructor change (*if*, don't
panic for now) how much trouble would that give you?

Please don't be shy giving your opinion. This is an important issue in
the future development of Wicket.

Regards,

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys-and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

--
View this message in context:

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0


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 3/6/07, cowwoc [EMAIL PROTECTED] wrote:



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 instantiation time rather then render time if there
 is a hierarchy-java mismatch - so you get a java line-precise error as
 opposed to our error webpage

 cons:

 * code explosion
 2.0: http://papernapkin.org/pastebin/view/4900
 1.3: http://papernapkin.org/pastebin/view/4908
 http://papernapkin.org/pastebin/view/4908

 * hacks necessary for nontrivial components
 GridView.populate()
 http://papernapkin.org/pastebin/view/4902
 notice fake1,fake2 parents necessary for child item instantiation and
 which are later removed

 * more limited in how the hierarchy is created since it MUST be created
 top-down

 * replacing components is less explicit.
 1.3: a.replaceWith(new B());
 2.0: new B(a.getParent(), a.getId());

 -igor




 On 3/6/07, *Jonathan Locke* [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:



 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 can't recall exactly /what/ diagnostics
we
 thought we'd get

 - ability to make component init dependent on parental
 context.  this might
 be either xml association or component data somehow.  i can't think
 of any
 times i've been screaming to do this, but can anyone give some of
 the best
 examples so we can evaluate what we'd be losing here?


 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 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.
 
  Please help us out giving your opinion. We want to know:
 
  1) Who uses 2.0 for serious projects?
 
  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.
 
  3) If we would ever backtrack on the constructor change (*if*,
don't
  panic for now) how much trouble would that give you?
 
  Please don't be shy giving your opinion. This is an important
issue in
  the future development of Wicket.
 
  Regards,
 
  Eelco
 
 

-

  Take Surveys. Earn Cash. Influence the Future of IT
  Join SourceForge.net's Techsay panel and you'll get the chance to
 share
  your
  opinions on IT  business topics through brief surveys-and earn
cash
 

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
  ___
  Wicket-user mailing list
  Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/wicket-user
 https://lists.sourceforge.net/lists/listinfo/wicket-user
 
 

 --
 View this message in context:

http://www.nabble.com/IMPORTANT%3A-your-opinion-on-the-constructor-change-in-2.0-tf3358738.html#a9342589
 
http://www.nabble.com/IMPORTANT%3A-your-opinion-on-the-constructor-change-in-2.0-tf3358738.html#a9342589

 Sent from the Wicket - User mailing list archive at Nabble.com
 http://Nabble.com.



-
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to
 share your
 opinions on IT  business topics through brief surveys-and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 mailto:Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

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:

i think i can live without the perfect error reporting as wicket error
reporting seems good enough to me now. it's almost certainly not worth a
code explosion to get this alone.

jon

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 instantiation time rather then render time if there
is
a
hierarchy-java mismatch - so you get a java line-precise error as
opposed
to our error webpage

cons:

* code explosion
2.0: http://papernapkin.org/pastebin/view/4900
1.3: http://papernapkin.org/pastebin/view/4908

* hacks necessary for nontrivial components
GridView.populate()
http://papernapkin.org/pastebin/view/4902
notice fake1,fake2 parents necessary for child item instantiation and
which
are later removed

* more limited in how the hierarchy is created since it MUST be created
top-down

* replacing components is less explicit.
1.3: a.replaceWith(new B());
2.0: new B(a.getParent(), a.getId());

-igor

On 3/6/07, Jonathan Locke [EMAIL PROTECTED] wrote:

- better diagnostics, but i can't recall exactly /what/ diagnostics we
thought we'd get

- ability to make component init dependent on parental context. this
might
be either xml association or component data somehow. i can't think of
any
times i've been screaming to do this, but can anyone give some of the
best
examples so we can evaluate what we'd be losing here?

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.

Please help us out giving your opinion. We want to know:

1) Who uses 2.0 for serious projects?

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.

3) If we would ever backtrack on the constructor change (*if*, don't
panic for now) how much trouble would that give you?

Please don't be shy giving your opinion. This is an important issue
in
the future development of Wicket.

Regards,

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share
your
opinions on IT business topics through brief surveys-and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

--
View this message in context:

http://www.nabble.com/IMPORTANT%3A-your-opinion-on-the-constructor-change-in-2.0-tf3358738.html#a9342589
Sent from the Wicket - User mailing list archive at Nabble.com.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys-and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys-and earn cash

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

 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 negative than it is, as when working with ajax
and javascript, you *need* this, and the ability to do it at any time
is nice.

There are workarounds, and I found that in the end I'm often coupling
such components on render time anyway (e.g. using header contributors
with LoadableDetachableModels).

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0


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 components that are based on or work together with
Javascript components, this is a nice feature to have. Driving code
from markup sounds more negative than it is, as when working with ajax
and javascript, you *need* this, and the ability to do it at any time
is nice.

There are workarounds, and I found that in the end I'm often coupling
such components on render time anyway (e.g. using header contributors
with LoadableDetachableModels).

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-06 Thread Martijn Dashorst

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 the model changes in 1.x will result in a lot of work, but not
nearly as much as the c'tor change. The api changes will be less
intrusive as you'll likely have less custom models than components.

Wicket 2.0 is a beast and hard to support, especially since to support
software in a good way, you need to eat your own dog food.

One other thing: moving to Apache usually requires you to move the
code base into the org.apache namespace. We opted to do that for 2.x
only, as the API is already broken. In the remote possibility of
freezing further development on 2.x, we should see what we need to do
in the org.apache realm for 1.x

If/when we need to make a decision between 1.x and 2.x, I'd rather
drop 2.x and continue with 1.x then drop 1.x in favor of 2.x.

Martijn

On 3/6/07, Eelco Hillenius [EMAIL PROTECTED] 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 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.

 Please help us out giving your opinion. We want to know:

 1) Who uses 2.0 for serious projects?

 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.

 3) If we would ever backtrack on the constructor change (*if*, don't
 panic for now) how much trouble would that give you?

 Please don't be shy giving your opinion. This is an important issue in
 the future development of Wicket.

 Regards,

 Eelco

 -
 Take Surveys. Earn Cash. Influence the Future of IT
 Join SourceForge.net's Techsay panel and you'll get the chance to share your
 opinions on IT  business topics through brief surveys-and earn cash
 http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
 ___
 Wicket-user mailing list
 Wicket-user@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/wicket-user



-- 
Learn Wicket at ApacheCon Europe: http://apachecon.com
Join the wicket community at irc.freenode.net: ##wicket
Wicket 1.2.5 will keep your server alive. Download Wicket now!
http://wicketframework.org

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-06 Thread Brian Topping


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 prefer 1.3's
 add style or 2.0's style of passing in the parent construction time.

What about some hybrid of the two?  My use case for this came  
yesterday, when I was wanting to add functionality for disabled  
option items in a DropDown.  If I were to follow the pattern of  
creating all the constructor combinations for optional parameters, I  
would have had to add somewhere between 50-100% of the count of the  
constructors.

IMHO, stuff like 'disabled' is secondary, and the meat of the  
component is the DropDown itself.  This is to say I would not miss  
java line-precise errors for stuff that is considered secondary.   
(Ignore me if I am talking nonsense here...)

 3) If we would ever backtrack on the constructor change (*if*, don't
 panic for now) how much trouble would that give you?

It wouldn't be that big a deal for me.

-b

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor

2007-03-06 Thread Stefan Lindner

To speak as an end-user:
 
 1) Who uses 2.0 for serious projects?
We use 2.0 in a serious project for mobile patient data acquisition. We plan 
the rollout for about next week (despite wicket 2.0 is not even in beta status).

 2) What do you think of the constructor change? Do you prefer 1.3's
We prefer the 2.0 constructor. At the first sight it looked a little bit 
strange.  The 1.3 style felt much more java like, having an object and 
activationg a method of this object instead of just creating new objects with 
no anchor (no variable addressing the newly created object). But the discussion 
about the advantages was convincing and after using it for some months now, the 
top down style was very usefull.

 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. But I was convinced of the advantages that the new constructor 
has and the question is now
1. Are the proposed advantages no longer advantages
2. Does the new constructor make anything impossible that was possible with the 
old style contructor?
3. What does the wicket 1.x users prevent to switch to the 2.0 style that goes 
beyond a simple syntax change?
 
Stefan Lindner
 
 
winmail.dat-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-06 Thread Al Maw

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 about 
this on both fronts. Apologies that this is a bit long. I've tried to 
condense it a bit, but there are a lot of things to talk about. :-)

The constructor change effectively means that for a big project you'll 
need to almost completely rewrite it to go from 1.x to 2.0 - there will 
be lots of fundamental logic changes. This seems misguided at best, for 
the following reasons...

1.x is not going to go away. With all the recent buzz, we now have an 
awful lot of 1.x users with growing code-bases (I'm one of them). Not 
providing all these users with a sensible upgrade path between versions 
is a big mistake, IMO. Users of Tapestry often complain that each big 
version is such a big API break that they effectively have to start from 
scratch each time. We surely don't want to make the same mistake?

Because 1.x isn't going to go away, people will want bugs fixing and new 
features adding on that branch. 1.x isn't going to go into maintenance 
mode any time soon - we'll have to continue to support two very active 
branches for months and quite possibly years to come.

Dividing effort and duplicating everything like this is a terrible waste 
of developer resources. I've no idea what quantitative impact it has/ 
will have, but I'd bet it's very large (25% or something).

We're also less likely to attract people who want to work on the project 
either as core committers or JIRA patch providers if they need to 
effectively do their work and testing twice. The fork already annoys me 
no end, and I'd definitely be inclined to fix more bugs if it wasn't 
like that.

If we have two active branches, they'll each be (on average) half as 
well tested in real world applications. This seems like a bad idea, for 
obvious reasons.

Most developers seem to have live or near-production systems running on 
1.3, so they are often scratching that itch first, and have limited time 
to forward port things to 2.0. This means that things lag a bit and make 
bug reporting and the like more of a hassle. I've lost track of the 
number of times someone has had to ask which branch are you using? in 
response to a bug report. I also sense that users are already getting 
frustrated with people saying things like ah, yes, that's fixed on the 
other branch.

So why did we do the constructor refactor? The argument for javascript 
IDs seems reasonable, but I'd counter it with two things:
  - You can use a unique ID instead to get around the problem (in fact,
maybe setOutputMarkupId() should use a globally unique ID by default
rather than a path, so you don't even need to worry about this?).
  - If you do use the ID from the constructor that 2.0 makes possible, it
will break if you do component replacement, because this will change.
So really, you should be using the current approach of pulling the ID
during the render or using a GUID anyway.

So we're left with marginally nicer error reporting. Is this much of an 
improvement? Is our current reporting that deficient? Might there be 
another way of improving this similarly, but without the constructor change?

Al

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor


On 3/6/07, Stefan Lindner [EMAIL PROTECTED] wrote:


To speak as an end-user:


 2) What do you think of the constructor change? Do you prefer 1.3's
We prefer the 2.0 constructor.



what about it do you prefer?




in most cases. But I was convinced of the advantages that the new
constructor has and the question is now
1. Are the proposed advantages no longer advantages



they still are, although less so with the new headercontributor stuff

2. Does the new constructor make anything impossible that was possible with

the old style contructor?



yes. it makes indirectly creating children more difficult. it also makes
moving components very difficult.

3. What does the wicket 1.x users prevent to switch to the 2.0 style that

goes beyond a simple syntax change?



because the constructor is more limiting in the way you create hierarchies
(see point 2) you need to rewrite parts of your code in a non-trivial manner

going the other way 2.0-1.x should be trivial

-igor


Stefan Lindner




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

  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. But I was convinced of the advantages that the new constructor 
 has and the question is now
 1. Are the proposed advantages no longer advantages

Yes, they still are, though improved header contributions make that
you don't often need the path at construction time, but instead can
use a model for that.

Also, I'd like to state again that for simple things, I like the more
compact style of 2.0. And I actually like the automatic re-parenting
that some others dislike. But a big problem is that some of the more
dynamic things got more work/ uglier to implement.

 2. Does the new constructor make anything impossible that was possible with 
 the old style contructor?

Some things. My biggest disappointment was that wizard steps can no
longer be panels as well, but have to work with a factory pattern. So
at least that component got uglier in 2.0.

 3. What does the wicket 1.x users prevent to switch to the 2.0 style that 
 goes beyond a simple syntax change?

I think the big dividing line is where you primarily used components
in a pretty straightforward manner, or whether you created lots of
advanced custom components. If the latter is the case, upgrading or
downgrading can be quite a bit of work. I think it goes too far to
state that it concerns a full rewrite, but for a large project this
certainly may make for a day or two excluding testing.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor

 going the other way 2.0-1.x should be trivial

This is true. At least it should be a lot easier.

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-06 Thread Johan Compagner

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 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 as
opposed to our error webpage

cons:

* code explosion
2.0: http://papernapkin.org/pastebin/view/4900
1.3: http://papernapkin.org/pastebin/view/4908

* hacks necessary for nontrivial components
GridView.populate()
http://papernapkin.org/pastebin/view/4902
notice fake1,fake2 parents necessary for child item instantiation and
which are later removed

* more limited in how the hierarchy is created since it MUST be created
top-down

* replacing components is less explicit.
1.3: a.replaceWith(new B());
2.0: new B(a.getParent(), a.getId());

-igor

On 3/6/07, Jonathan Locke [EMAIL PROTECTED] wrote:

- better diagnostics, but i can't recall exactly /what/ diagnostics we
thought we'd get

- ability to make component init dependent on parental context. this
might
be either xml association or component data somehow. i can't think of
any
times i've been screaming to do this, but can anyone give some of the
best
examples so we can evaluate what we'd be losing here?

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.

Please help us out giving your opinion. We want to know:

1) Who uses 2.0 for serious projects?

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.

3) If we would ever backtrack on the constructor change (*if*, don't
panic for now) how much trouble would that give you?

Please don't be shy giving your opinion. This is an important issue in
the future development of Wicket.

Regards,

Eelco

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share
your
opinions on IT business topics through brief surveys-and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

--
View this message in context:
http://www.nabble.com/IMPORTANT%3A-your-opinion-on-the-constructor-change-in-2.0-tf3358738.html#a9342589

Sent from the Wicket - User mailing list archive at Nabble.com.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT business topics through brief surveys-and earn cash

http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-06 Thread Jonathan Locke

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
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 negative than it is, as when working with ajax
and javascript, you *need* this, and the ability to do it at any time
is nice.

There are workarounds, and I found that in the end I'm often coupling
such components on render time anyway (e.g. using header contributors
with LoadableDetachableModels).

Eelco

--
View this message in context:
http://www.nabble.com/IMPORTANT%3A-your-opinion-on-the-constructor-change-in-2.0-tf3358738.html#a9346362
Sent from the Wicket - User mailing list archive at Nabble.com.

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0

2007-03-06 Thread Iman Rahmatizadeh


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.

* access to markup attributes in constructor as opposed to render time



I dont know why, but I've never felt any need for these two. Maybe I'm used
to passing dependencies to child components, instead of letting them access
the parent page. But these two have never been a problem for me .

* fail at component instantiation time rather then render time if there is a

hierarchy-java mismatch - so you get a java line-precise error as opposed
to our error webpage



In 80% of my usecases, I use the component as soon as I instantiate it, so
this is really considered a minor improvement in my domain.

cons:


* code explosion
2.0: http://papernapkin.org/pastebin/view/4900
1.3: http://papernapkin.org/pastebin/view/4908



Now, I already preferred the add()  method way over the  new(parent,...)
way, just because of clarity and maybe because I'm used to it. But this
example is really frightening me. It's got way too complicated instead of
simpler, and clean readable code is really REALLY important. Consider a
newbie, looking for the first time at these two codes. Which one would be
easier for him to understand ?

* hacks necessary for nontrivial components

GridView.populate()
http://papernapkin.org/pastebin/view/4902
notice fake1,fake2 parents necessary for child item instantiation and
which are later


* more limited in how the hierarchy is created since it MUST be created

top-down

* replacing components is less explicit.
1.3: a.replaceWith(new B());
2.0: new B(a.getParent(), a.getId());



again, code is getting uglier :-(

Some other thoughts :
* Converting 1.x code to 2.x is really really hard this way. If it would've
been easier, I guess many users (including myself) would've started to use
2.x codebase right now. The amount of feedback and test you would get by
that is enormous. But, considering how much code I have working with 1.x and
how much pain it would have migrating to 2, I've left it out for my next
project.


* One of the best features I'm hoping for in 2.x is the Java 5 support, like
covariant return types, Generics and stuff. Surely they would make my page's
much cleaner and readable. But wicked is way too slow in adopting jdk5, and
I see the problem is the enormous constructor change getting in its way. I
cant estimate the amount of man-hour work needed to finish 2, but maybe a
good 6 months is needed. Now that everybody is talking about the new
features in Java 7, we still have to work with Java 1.4 style of code. Or
maybe when 7 is out, we could finally use 5 ? ;-)


As a user I'm very happy with the current features and possibilities in
wicket, and am only waiting for the changes(stateless forms, page cache, ...
)  in 1.3. My main dissatisfaction is some ugly code I'm forced to write
which can be easily improved. Like I'm really sick of the casting and the
always null parameter in :
myObject = (MyObject) myModel.getObject(null);

Just my 2c !
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT  business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Re: [Wicket-user] IMPORTANT: your opinion on the constructor change in 2.0