Re: [Vote] remove add() and pass parent in constructor?

[aozster <ao...@gmail.com>]

igor.vaynberg 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.
> 
> ------> attribute modifier is more flexible and reusable
> 
> * 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.
> 
> * 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 ).
> 
> 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.
> 
> -> 2.0 It means I have to recreate it, specifying new parent in
> constructor , copy all state from the old panel to the new one and place
> in new placeholder. 
> 
> 
> please provide us with feedback/concerns so we have a better feel for
> requirements out there.
> 
> thanks,
> -Igor
> 
> 

-- 
View this message in context: http://www.nabble.com/remove-add%28%29-and-pass-parent-in-constructor--tf929620.html#a9369154
Sent from the Wicket - Dev mailing list archive at Nabble.com.

Re: [Vote] remove add() and pass parent in constructor?

[Igor Vaynberg <ig...@gmail.com>]

On 3/7/07, aozster <ao...@gmail.com> 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

Re: [Vote] remove add() and pass parent in constructor?

[Igor Vaynberg <ig...@gmail.com>]

a year too late? :)

-igor


On 3/7/07, aozster <ao...@gmail.com> wrote:
>
>
>
>
> igor.vaynberg 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.
> >
> > ------> attribute modifier is more flexible and reusable
> >
> > * 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.
> >
> > * 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 ).
> >
> > 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.
> >
> > -> 2.0 It means I have to recreate it, specifying new parent in
> > constructor , copy all state from the old panel to the new one and place
> > in new placeholder.
> >
> >
> > please provide us with feedback/concerns so we have a better feel for
> > requirements out there.
> >
> > thanks,
> > -Igor
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/remove-add%28%29-and-pass-parent-in-constructor--tf929620.html#a9369154
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>