On 3/7/07, aozster <[EMAIL PROTECTED]> wrote:
> * 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. > > ------> attribute modifier is more flexible and reusable
for simple usecases where you just want to set a class from java code it is not. it has an overhead of an entire class instance where a simple string would do just as well. the overhead is with respect to storage in session.
* 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. > > ------> The trade off is too high, It can be archive with more explicit > mechanism, not by forcing static structure and let compiler checking help > detect this.
yes but it took practical experience to figure it out. nothing more explicit then what we have in 1.3 is possible really. the advantage of this is that you get a stactrace that points to the offending instantiation in java rather then a pointer to the markup.
* getPage() and getPath() will work in the component's constructor. this > is > really nice for ajax stuff. > > -------> It should be available in other component lifcycle method, or use > publish subscribe mechanism , shouldn't rely on constructor ( which means > vm object creation ).
there is nothing "vm object creation" about this. constructors in java have the same properties as constructors in c++ or any other language afaik. they are atomic, if they do not succeed the instance is not created. wicket components rely on these to properly initialize themselves. wicket components are not beans, they are full blown objects.
> 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? > > -----------> component can not switch parent. > Usecases: > CMS -> layout designer provide template and look and feel and let's > content author to place component in placeholder and may be switch between > placeholder, component may appear across pages (state is ratained across > page) > Rich Internet Application UI -> multitab pane , doggable pane which user > can move pane around. > Portal -> wicket component can be views as portlet and viewlet which use > can customized to suit their needs.
we actually have a rough reparenting support in trunk, but it isnt very nice. im sure it could be made better with more work, but probably not worth it. -igor
