thanks On 1/17/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > actually thats only partially true. there is a small prototype of this in > wicket's cvs sandbox/ivaynberg/wicked but it is built in isolation from > wicket so it doesnt have the request processing, etc. just the parent/child > linking and a prototype render model. > > -Igor > > > > On 1/17/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > no, not yet. we dont have the resources to maintain two branches, > especially now when we are almost in bugfix mode and so any file can be > changed. > > > > > > -Igor > > > > > > > > On 1/17/06, Laurent PETIT <[EMAIL PROTECTED]> wrote: > > > Is there an implementation of this in some branch (or maybe head ?) of > the cvs ? > > > > > > I think (as Martijn also mentioned) that I just can't see what could > > > be all the issues without having a look at the code ... > > > > > > On 1/17/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > > > the parent container will still have a list of its children. the > > > > parent->child relationship is created for you deep in > Component(Component > > > > parent, String id) constructor which is called before your component's > > > > constructor is called. so by the time you are in your custom > constructor the > > > > relationship has already been created - thats the key. > > > > > > > > but now instead of calling parent.remove(Component child) you call > > > > child.remove() and then child.readd() if you want the component to be > > > > relinked. > > > > > > > > -Igor > > > > > > > > > > > > > > > > On 1/17/06, Laurent PETIT <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Hello, > > > > > > > > > > Maybe I'm not very "quick" today, but does that mean that a parent > > > > > component will not hold a list of child components anymore ? > > > > > > > > > > or just that it's the child component that will in charge of calling > > > > > the right method on the parent to register itself ? > > > > > > > > > > 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://sel.as-us.falkag.net/sel?cmdlnk&kid3432&bid#0486&dat1642 > > > > > _______________________________________________ > > > > > Wicket-develop mailing list > > > > > Wicket-develop@lists.sourceforge.net > > > > > > > > > > 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?cmdlnk&kid3432&bid#0486&dat1642 > > > _______________________________________________ > > > Wicket-develop mailing list > > > Wicket-develop@lists.sourceforge.net > > > > 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 Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
