i can understand this predicament and this was my first suggestion:
that we release 1.2 as-is and then quickly release a 2.0 with these
constructor changes before focusing on a longer-term 2.1... i think
your request is a reasonable one and since you object, i'd like to
change my vote to match yours.
-1 for 1.2
+1 for 2.0 (on a very quick release cycle after 1.2)
Ari Suutari wrote:
-1 for 1.2
+1 for 2.0
I understand that not having parent information available is painful
(I have hit it sometimes myself) but:
We have already an application which has more than 300 wicket pages.
This would force us to re-visit all that code again. Not very nice,
since:
- we need 1.2 features for some ajax-thingies
- part of application is supposed to go production in next months.
I think it would be acceptable to provide a new constructor with parent
but keep the old approach around, but deprecate it (it could be
removed in
2.0).
I have also used reparenting (which now would be impossible). An example
of this is a shared "property panel", which is attached to different
rows of listview
depenending on user's actions. I could work around this (and it might
be a good idea
to change it) but I mention it here as an example use case.
Too much refactoring is will hurt wicket. I would consider good API
policy
(at least sometime in the future when wicket is more mature) to keep API
as unchanged as possible between minor releases.
Ari S.
----- Original Message ----- From: "Eelco Hillenius"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, January 16, 2006 8:39 PM
Subject: Re: [Wicket-develop] remove add() and pass parent in
constructor?
Furthermore, we have been discussing on, if we are implementing this
change, /when/ we are going to do it.
Basically the options are between 2.0 in a few months or 1.2 now. I
would be for doing it right away. It might hurt a bit for people
working on HEAD now, but compared to 1.1 there already have been a
couple of API breaks. Furthermore, you'll reap the benefits earlier,
we have less trouble supporting versions and we can write Wicket In
Action using this.
Eelco
On 1/16/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
hello all,
we, the core devel group, have been discussing and evaluating a
possible
change we would like to make for the next release and we would like
your
input.
the idea is to remove the Component.add(Component child) method and
link
components via a constructor instead: Component(Component parent,
String id)
this has a couple of advantages:
* have access to markup the component is attached to in the
constructor.
that means you can read attributes and initialize your component
appropriately. it also means we can eliminate the use of attribute
modifiers
for non-dynamic attribute replacement.
* we can fail super-early if there is a mismatch between component and
markup hierachies. currently we dont fail until render time, with this
change we can fail in the Component constructor - so before the
component is
actually created. this will give you a line precise error in markup
AND java
code.
* getPage() and getPath() will work in the component's constructor.
this is
really nice for ajax stuff.
the big disadvantage of course is that we will break ALL existing
code. it
is a simple change to fix though. a hybrid of this and add() will
not work
because all links in the chain need to use the new constructor for
it to
work.
we would also provide Component.remove() and Component.readd() which
remove/readd component to its parent. so the link between parent and
child
is now managed on the child's side instead of the parent's side.
this, of
course, makes it impossible to move components between parents - is
there a
usecase for this?
please provide us with feedback/concerns so we have a better feel for
requirements out there.
thanks,
-Igor
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through
log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&opÌk
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Wicket-develop mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-develop
