I'm intersted in design
Hello all wicket users! Does anybody know why id is added to component, not to list of children, like: add("someId", childComponent); Thank you very much. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: I'm intersted in design
Because it is imperative in many ways that the component knows it's own ID. Look through the code to see how many times it uses it's ID. Hope this helps. -- Jeremy Thomerson http://www.wickettraining.com On Thu, Jan 15, 2009 at 9:40 PM, Anton Veretennikov < anton.veretenni...@gmail.com> wrote: > Hello all wicket users! > > Does anybody know why id is added to component, not to list of children, > like: > > add("someId", childComponent); > > Thank you very much. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: I'm intersted in design
> Because it is imperative in many ways that the component knows it's own ID. > Look through the code to see how many times it uses it's ID. Do you mean that instance needs to know ID BEFORE it was added? If not, add() can internally set ID of component sent as parameter. If one child can't have other ID it can be checked in setId(). - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: I'm intersted in design
add(Component) has at least these advantages over add(String, Component): - most efficiently expresses the semantics of the operation (simplicity) - makes the id effectively immutable (reliability) - since you can't construct a component without an id, you know by definition that any Component will have a valid id (consistency, reliability) - other methods that take Component won't need an id parameter (simplicity) a good rule of thumb: the ideal interface has one method. the ideal method takes no parameters and returns nothing. the more methods you add to an interface, the more parameters you add to a method and the more state you mutate on each method call, the more you are creating both complexity and specificity which will drag your design down by limiting its ability to be generalized (extended and reused) while creating weight, bugs, encapsulation leaks and hard-wired coupling in the process. less is more. Anton Veretennikov wrote: > >> Because it is imperative in many ways that the component knows it's own >> ID. >> Look through the code to see how many times it uses it's ID. > > Do you mean that instance needs to know ID BEFORE it was added? > If not, add() can internally set ID of component sent as parameter. > If one child can't have other ID it can be checked in setId(). > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > -- View this message in context: http://www.nabble.com/I%27m-intersted-in-design-tp21492078p21493324.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: I'm intersted in design
Can i then do this? Component x = new Component() parent.add('first', x) parent.add('second',x) Or should it then throw an exception at runtime (it wil in develop mode) And if there are situations that the component wants to know its name before its added to the parent (in its constructor for example). What then? On 16/01/2009, Anton Veretennikov wrote: >> Because it is imperative in many ways that the component knows it's own >> ID. >> Look through the code to see how many times it uses it's ID. > > Do you mean that instance needs to know ID BEFORE it was added? > If not, add() can internally set ID of component sent as parameter. > If one child can't have other ID it can be checked in setId(). > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org