this question is posed here because we want feedback from non-committers
who are interested in how wicket grows.
-Igor
On 1/16/06, *Ingram Chen*
<[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
I'm not committer but
+1 for change now !
We just take one or two hours for refactoring now
but the return is huge because we no longer need to suffer time on
tweak/debug/code ugly....
This saves much more time !
And the most important thing is Wicket in Action, this is the key
for our team to
adopt Wicket. I cound not promote Wicket to our whole team because
there is no book...
Personally, I hope when Wicket in Action out, our old-struts-team
can grab Wicket quickly because it is written for latest version.
On 1/17/06, *Eelco Hillenius* <
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
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]
<mailto:[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&opclick
<http://ads.osdn.com/?ad_idv37&alloc_id%16865&opclick>
_______________________________________________
Wicket-develop mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/wicket-develop
--
Ingram Chen
Java [EMAIL PROTECTED]
Institue of BioMedical Sciences Academia Sinica Taiwan
blog: http://www.javaworld.com.tw/roller/page/ingramchen
