Re: Component initModel() order (design issue?)
initmodel isnt called until the first getmodel/object call. why would that happen before the component is added to its parent? -igor On Thu, Oct 1, 2009 at 1:03 AM, Edmund Urbani wrote: > Can't be done, because the component does not yet know its parent during > object > initialization. initModel/getDefaultModel needs to be called later, when the > component knows its place in the hierarchy. by giving the child component a > model that obtains the model from its parent (MyTextfield) the call to > getDefaultModel is delayed and it works. > > Cheers > Edmund > > Igor Vaynberg wrote: >> why not >> >> class mytextefield extends panel { >> public mytextfield { >> add(new textfield() { initmodel() { return >> mytextfield.this.getdefaultmodel(); }}); >> } >> } >> >> since this is essentially what you want to do - have textfield use the >> same model as the panel. >> >> -igor >> >> On Wed, Sep 30, 2009 at 9:47 AM, Edmund Urbani wrote: >>> You're right, getDefaultModel ensures initialization. I should have >>> suggested >>> that instead of getModel (which is not available in the component class >>> anymore >>> in 1.4.x). >>> >>> However, I did not want to override the initModel() method (and copy most >>> of its >>> code) just for that. So now I solved it by creating a new wrap model, which >>> I >>> pass to the child component and which wraps around the >>> parent.getDefaultModel(). >>> >>> public class ComponentWrapModel implements IWrapModel { >>> private Component component; >>> public ComponentWrapModel(Component component) { // component = >>> parent >>> this.component=component; >>> } >>> >>> �...@override >>> public IModel getWrappedModel() { >>> return component.getDefaultModel(); >>> } >>> >>> } >>> >>> Here's some more background which should explain why I chose to do this: >>> I replace form components (eg. Textfield) with custom components (eg. >>> MyTextfield) to add a few things my application needs to them. The name >>> MyTextfield is a bit misleading here, because this is actually a subclass of >>> Panel, and it merely contains a Textfield as a child. Still I wanted to use >>> MyTextfield as a drop-in replacement, even when used in a form with a >>> CompoundPropertyModel. This is where things got a little tricky, because the >>> Textfield would end up trying to retrieve a property model matching its own >>> wicket:id, when the relevant wicket:id had now become that of MyTextfield. >>> >>> Anyway I would have expected that wicket ensures the parent component model >>> gets >>> initialized first, seeing how components generally query their parents when >>> they >>> don't have a model of their own. And I'm still considering to report this >>> as a >>> bug in Jira. >>> >>> Cheers >>> Edmund >>> >>> >>> Pedro Santos wrote: The child model's initModel() gets called first There are no especial ordering programing to initModels calls. Basically they are called by public final IModel getDefaultModel() { IModel model = getModelImpl(); // If model is null if (model == null) { // give subclass a chance to lazy-init model model = initModel(); setModelImpl(model); } return model; } What about your custom component gain an model that implements IComponentInheritedModel and assign his children default models with the desired logic? On IComponentInheritedModel you can access your custom component parent model, and if you use getDefaultModel method, you don't need to care with initialization ordering too... On Wed, Sep 30, 2009 at 9:51 AM, Edmund Urbani wrote: > Hi, > > I was just trying to create a component of my own which - in some of my > pages - > is created without a model. In the initModel() method I would then call > super.initModel() and wrap the resulting model for use in a child > component. The > problem is the initialization order: > > The child model's initModel() gets called first, the parent (my custom > component) does not yet have a model (getModelImpl() returns null) so it > goes up > farther in the component hierarchy and retrieves a wrong model. > > Looking at the Component source code (Wicket 1.4.1) I see a commented out > line > where initModel() used to to call the parent getModel() instead of > getModelImpl(). There's also a comment explaining that doing so would > "initialize many inbetween completely useless models". Well, not so > useless > for > what I am trying to do I guess. > > So, from my perspective this looks like a bug that causes necessary > initialization to be bypassed. Obviously though it was done like that on > purpose, so I decided to put the issue up
Re: Component initModel() order (design issue?)
Can't be done, because the component does not yet know its parent during object initialization. initModel/getDefaultModel needs to be called later, when the component knows its place in the hierarchy. by giving the child component a model that obtains the model from its parent (MyTextfield) the call to getDefaultModel is delayed and it works. Cheers Edmund Igor Vaynberg wrote: > why not > > class mytextefield extends panel { > public mytextfield { >add(new textfield() { initmodel() { return > mytextfield.this.getdefaultmodel(); }}); >} > } > > since this is essentially what you want to do - have textfield use the > same model as the panel. > > -igor > > On Wed, Sep 30, 2009 at 9:47 AM, Edmund Urbani wrote: >> You're right, getDefaultModel ensures initialization. I should have suggested >> that instead of getModel (which is not available in the component class >> anymore >> in 1.4.x). >> >> However, I did not want to override the initModel() method (and copy most of >> its >> code) just for that. So now I solved it by creating a new wrap model, which I >> pass to the child component and which wraps around the >> parent.getDefaultModel(). >> >> public class ComponentWrapModel implements IWrapModel { >>private Component component; >>public ComponentWrapModel(Component component) { // component = parent >>this.component=component; >>} >> >>@Override >>public IModel getWrappedModel() { >>return component.getDefaultModel(); >>} >> >> } >> >> Here's some more background which should explain why I chose to do this: >> I replace form components (eg. Textfield) with custom components (eg. >> MyTextfield) to add a few things my application needs to them. The name >> MyTextfield is a bit misleading here, because this is actually a subclass of >> Panel, and it merely contains a Textfield as a child. Still I wanted to use >> MyTextfield as a drop-in replacement, even when used in a form with a >> CompoundPropertyModel. This is where things got a little tricky, because the >> Textfield would end up trying to retrieve a property model matching its own >> wicket:id, when the relevant wicket:id had now become that of MyTextfield. >> >> Anyway I would have expected that wicket ensures the parent component model >> gets >> initialized first, seeing how components generally query their parents when >> they >> don't have a model of their own. And I'm still considering to report this as >> a >> bug in Jira. >> >> Cheers >> Edmund >> >> >> Pedro Santos wrote: >>> The child model's initModel() gets called first >>> There are no especial ordering programing to initModels calls. Basically >>> they are called by >>> >>> public final IModel getDefaultModel() >>> { >>> IModel model = getModelImpl(); >>> // If model is null >>> if (model == null) >>> { >>> // give subclass a chance to lazy-init model >>> model = initModel(); >>> setModelImpl(model); >>> } >>> >>> return model; >>> } >>> What about your custom component gain an model that implements >>> IComponentInheritedModel and assign his children default models with the >>> desired logic? On IComponentInheritedModel you can access your custom >>> component parent model, and if you use getDefaultModel method, you don't >>> need to care with initialization ordering too... >>> >>> On Wed, Sep 30, 2009 at 9:51 AM, Edmund Urbani wrote: >>> Hi, I was just trying to create a component of my own which - in some of my pages - is created without a model. In the initModel() method I would then call super.initModel() and wrap the resulting model for use in a child component. The problem is the initialization order: The child model's initModel() gets called first, the parent (my custom component) does not yet have a model (getModelImpl() returns null) so it goes up farther in the component hierarchy and retrieves a wrong model. Looking at the Component source code (Wicket 1.4.1) I see a commented out line where initModel() used to to call the parent getModel() instead of getModelImpl(). There's also a comment explaining that doing so would "initialize many inbetween completely useless models". Well, not so useless for what I am trying to do I guess. So, from my perspective this looks like a bug that causes necessary initialization to be bypassed. Obviously though it was done like that on purpose, so I decided to put the issue up here instead of filing a bug report. Has anyone else run into similar issues? Would it really be so bad to just call getModel()? Cheers Edmund >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional co
Re: Component initModel() order (design issue?)
why not class mytextefield extends panel { public mytextfield { add(new textfield() { initmodel() { return mytextfield.this.getdefaultmodel(); }}); } } since this is essentially what you want to do - have textfield use the same model as the panel. -igor On Wed, Sep 30, 2009 at 9:47 AM, Edmund Urbani wrote: > You're right, getDefaultModel ensures initialization. I should have suggested > that instead of getModel (which is not available in the component class > anymore > in 1.4.x). > > However, I did not want to override the initModel() method (and copy most of > its > code) just for that. So now I solved it by creating a new wrap model, which I > pass to the child component and which wraps around the > parent.getDefaultModel(). > > public class ComponentWrapModel implements IWrapModel { > private Component component; > public ComponentWrapModel(Component component) { // component = parent > this.component=component; > } > > �...@override > public IModel getWrappedModel() { > return component.getDefaultModel(); > } > > } > > Here's some more background which should explain why I chose to do this: > I replace form components (eg. Textfield) with custom components (eg. > MyTextfield) to add a few things my application needs to them. The name > MyTextfield is a bit misleading here, because this is actually a subclass of > Panel, and it merely contains a Textfield as a child. Still I wanted to use > MyTextfield as a drop-in replacement, even when used in a form with a > CompoundPropertyModel. This is where things got a little tricky, because the > Textfield would end up trying to retrieve a property model matching its own > wicket:id, when the relevant wicket:id had now become that of MyTextfield. > > Anyway I would have expected that wicket ensures the parent component model > gets > initialized first, seeing how components generally query their parents when > they > don't have a model of their own. And I'm still considering to report this as a > bug in Jira. > > Cheers > Edmund > > > Pedro Santos wrote: >> The child model's initModel() gets called first >> There are no especial ordering programing to initModels calls. Basically >> they are called by >> >> public final IModel getDefaultModel() >> { >> IModel model = getModelImpl(); >> // If model is null >> if (model == null) >> { >> // give subclass a chance to lazy-init model >> model = initModel(); >> setModelImpl(model); >> } >> >> return model; >> } >> What about your custom component gain an model that implements >> IComponentInheritedModel and assign his children default models with the >> desired logic? On IComponentInheritedModel you can access your custom >> component parent model, and if you use getDefaultModel method, you don't >> need to care with initialization ordering too... >> >> On Wed, Sep 30, 2009 at 9:51 AM, Edmund Urbani wrote: >> >>> Hi, >>> >>> I was just trying to create a component of my own which - in some of my >>> pages - >>> is created without a model. In the initModel() method I would then call >>> super.initModel() and wrap the resulting model for use in a child >>> component. The >>> problem is the initialization order: >>> >>> The child model's initModel() gets called first, the parent (my custom >>> component) does not yet have a model (getModelImpl() returns null) so it >>> goes up >>> farther in the component hierarchy and retrieves a wrong model. >>> >>> Looking at the Component source code (Wicket 1.4.1) I see a commented out >>> line >>> where initModel() used to to call the parent getModel() instead of >>> getModelImpl(). There's also a comment explaining that doing so would >>> "initialize many inbetween completely useless models". Well, not so useless >>> for >>> what I am trying to do I guess. >>> >>> So, from my perspective this looks like a bug that causes necessary >>> initialization to be bypassed. Obviously though it was done like that on >>> purpose, so I decided to put the issue up here instead of filing a bug >>> report. >>> >>> Has anyone else run into similar issues? >>> Would it really be so bad to just call getModel()? >>> >>> Cheers >>> Edmund >>> > > > - > 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
Re: Component initModel() order (design issue?)
You're right, getDefaultModel ensures initialization. I should have suggested that instead of getModel (which is not available in the component class anymore in 1.4.x). However, I did not want to override the initModel() method (and copy most of its code) just for that. So now I solved it by creating a new wrap model, which I pass to the child component and which wraps around the parent.getDefaultModel(). public class ComponentWrapModel implements IWrapModel { private Component component; public ComponentWrapModel(Component component) { // component = parent this.component=component; } @Override public IModel getWrappedModel() { return component.getDefaultModel(); } } Here's some more background which should explain why I chose to do this: I replace form components (eg. Textfield) with custom components (eg. MyTextfield) to add a few things my application needs to them. The name MyTextfield is a bit misleading here, because this is actually a subclass of Panel, and it merely contains a Textfield as a child. Still I wanted to use MyTextfield as a drop-in replacement, even when used in a form with a CompoundPropertyModel. This is where things got a little tricky, because the Textfield would end up trying to retrieve a property model matching its own wicket:id, when the relevant wicket:id had now become that of MyTextfield. Anyway I would have expected that wicket ensures the parent component model gets initialized first, seeing how components generally query their parents when they don't have a model of their own. And I'm still considering to report this as a bug in Jira. Cheers Edmund Pedro Santos wrote: > The child model's initModel() gets called first > There are no especial ordering programing to initModels calls. Basically > they are called by > > public final IModel getDefaultModel() > { > IModel model = getModelImpl(); > // If model is null > if (model == null) > { > // give subclass a chance to lazy-init model > model = initModel(); > setModelImpl(model); > } > > return model; > } > What about your custom component gain an model that implements > IComponentInheritedModel and assign his children default models with the > desired logic? On IComponentInheritedModel you can access your custom > component parent model, and if you use getDefaultModel method, you don't > need to care with initialization ordering too... > > On Wed, Sep 30, 2009 at 9:51 AM, Edmund Urbani wrote: > >> Hi, >> >> I was just trying to create a component of my own which - in some of my >> pages - >> is created without a model. In the initModel() method I would then call >> super.initModel() and wrap the resulting model for use in a child >> component. The >> problem is the initialization order: >> >> The child model's initModel() gets called first, the parent (my custom >> component) does not yet have a model (getModelImpl() returns null) so it >> goes up >> farther in the component hierarchy and retrieves a wrong model. >> >> Looking at the Component source code (Wicket 1.4.1) I see a commented out >> line >> where initModel() used to to call the parent getModel() instead of >> getModelImpl(). There's also a comment explaining that doing so would >> "initialize many inbetween completely useless models". Well, not so useless >> for >> what I am trying to do I guess. >> >> So, from my perspective this looks like a bug that causes necessary >> initialization to be bypassed. Obviously though it was done like that on >> purpose, so I decided to put the issue up here instead of filing a bug >> report. >> >> Has anyone else run into similar issues? >> Would it really be so bad to just call getModel()? >> >> Cheers >> Edmund >> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Component initModel() order (design issue?)
The child model's initModel() gets called first There are no especial ordering programing to initModels calls. Basically they are called by public final IModel getDefaultModel() { IModel model = getModelImpl(); // If model is null if (model == null) { // give subclass a chance to lazy-init model model = initModel(); setModelImpl(model); } return model; } What about your custom component gain an model that implements IComponentInheritedModel and assign his children default models with the desired logic? On IComponentInheritedModel you can access your custom component parent model, and if you use getDefaultModel method, you don't need to care with initialization ordering too... On Wed, Sep 30, 2009 at 9:51 AM, Edmund Urbani wrote: > Hi, > > I was just trying to create a component of my own which - in some of my > pages - > is created without a model. In the initModel() method I would then call > super.initModel() and wrap the resulting model for use in a child > component. The > problem is the initialization order: > > The child model's initModel() gets called first, the parent (my custom > component) does not yet have a model (getModelImpl() returns null) so it > goes up > farther in the component hierarchy and retrieves a wrong model. > > Looking at the Component source code (Wicket 1.4.1) I see a commented out > line > where initModel() used to to call the parent getModel() instead of > getModelImpl(). There's also a comment explaining that doing so would > "initialize many inbetween completely useless models". Well, not so useless > for > what I am trying to do I guess. > > So, from my perspective this looks like a bug that causes necessary > initialization to be bypassed. Obviously though it was done like that on > purpose, so I decided to put the issue up here instead of filing a bug > report. > > Has anyone else run into similar issues? > Would it really be so bad to just call getModel()? > > Cheers > Edmund > > -- > Liland ...does IT better > > Liland IT GmbH > Software Architekt > email: edmund.urb...@liland.at > > office: +43 (0)463 220111 | fax: +43 (0)463 220111 33 | mobil: +43 (0)699 > 122011 16 > http://www.Liland.at > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Pedro Henrique Oliveira dos Santos
Component initModel() order (design issue?)
Hi, I was just trying to create a component of my own which - in some of my pages - is created without a model. In the initModel() method I would then call super.initModel() and wrap the resulting model for use in a child component. The problem is the initialization order: The child model's initModel() gets called first, the parent (my custom component) does not yet have a model (getModelImpl() returns null) so it goes up farther in the component hierarchy and retrieves a wrong model. Looking at the Component source code (Wicket 1.4.1) I see a commented out line where initModel() used to to call the parent getModel() instead of getModelImpl(). There's also a comment explaining that doing so would "initialize many inbetween completely useless models". Well, not so useless for what I am trying to do I guess. So, from my perspective this looks like a bug that causes necessary initialization to be bypassed. Obviously though it was done like that on purpose, so I decided to put the issue up here instead of filing a bug report. Has anyone else run into similar issues? Would it really be so bad to just call getModel()? Cheers Edmund -- Liland ...does IT better Liland IT GmbH Software Architekt email: edmund.urb...@liland.at office: +43 (0)463 220111 | fax: +43 (0)463 220111 33 | mobil: +43 (0)699 122011 16 http://www.Liland.at - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org