We only recently started getting to the limits we can do with our current component model: essentially _javascript_/css id's, component rendering and so forth are quite troublesome when using the 'old' approach. This is probably not something that can be discovered up front. For most web applications that don't do component rendering, attaching oodles of _javascript_ where two components need to work together on the client side, the current approach suffices.

I've created several applications using the old approach and yes, you can create quite astonishing things using it, but those _javascript_ components are not easy, nor elegant. We always intended Wicket to be a framework that works /with/ you instead of against you and this change moves us in the right direction again.

Martijn


On 1/19/06, Ari Suutari <[EMAIL PROTECTED]> wrote:
Hi,

Does anyone remember why the original design has been
not to pass parent to constructor and use add ? I'm a little worried
that there is some kind of idea behind the original approach and
after doing huge amount of work (in wicket and applications that use
it) we end up finding out that the original approach something good
that pass-parent-to-constructor doesn't.

This is such so fundamendal change, in simple applications
that have just forms with zillions of fields backed up by database
models it affects almost all user interface code.

    Ari S.

----- Original Message -----
From: "Igor Vaynberg" <[EMAIL PROTECTED]>
To: <wicket-develop@lists.sourceforge.net>
Sent: Monday, January 16, 2006 7:18 PM
Subject: [Wicket-develop] remove add() and pass parent in constructor?


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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop



--
Living a wicket life...

Martijn Dashorst - http://www.jroller.com/page/dashorst

Wicket 1.1 is out: http://wicket.sourceforge.net/wicket-1.1

Reply via email to