So the model that needs the innermodel implements the getInnerModel()??
and how does it then get the innermodel? (it needs it it implements such an
interface
because it wants to get it)
is ICompoundModel then always also a IComponentAssignable?
so that in the getInnerModel() call it does have the component and call
something on component?
But why do we then have the getInnerModel() method on an interface?
Remember as far as i understand this discussion, the model itself wants to
have a compound injected
This model could be the standard model of a component or a special model
(like the label and href models of ExternalLink)
So something like this:
Form form = new Form("x", new CompoundPropertyModel(new Person()))
form.add(new TextField("y", new
WantTheAboveCompoundPropertyModelWhenMyGetObjectIsCalled("specialnameproperty"));
So which model of the 2 should implement that ICompoundModel???
And when is the CompoundPropertyModel assigned to the textfield model? and
how?
i still think this is all getting much to complex. when it is so easy now to
solve:
CompoundPropertyModel model = new CompoundPropertyModel(new Person());
Form form = new Form("x", model)
form.add(new TextField("y", model.bind("specialnameproperty"));
the only thing is that you need to have access to the compoundmodel at the
moment you create the textfield...
johan
On 4/6/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
when i was discussing this with jon i came up with a slightly different
idea
there are two issues at work, or two paths
one to get the "root" model, and one to "unwrap" the model.
so we used to have iwrapmodel.getnestermodel() which should have returned
the model that created the wrapper. we used that to unwrap the model.
the assumption has been that unwrapping is always the same as going one
step
closer to the root, which with this new componentpropmodel is wrong.
so maybe what we need is a different interface,
ICompoundModel.getInnerModel
()
so any imodel can implement icompound and its getinnermodel is the path up
to the root. and this is independent from iwrapmodel.getnestedmodel()
which
is a path to unwrapping.
dont know if we need this or if the above makes sense :)
-igor
On 4/6/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
>
> i have thought about this some more.
>
> wat you want is i think is a interface: IIWantParentModel
> (setParentModel(IModel))
>
> the problem is when to call it?
> For normal models this is easy: getModel() does the checking.
>
> but for ExternalLink that has 2 own models.. should handle that then
> internally.
> so when we do this:
> Object hrefValue = href.getObject();
>
> we should do:
>
> Object hrefValue = testIfParentModelIsSet(href).getObject();
>
> then it works for all models and we don't have anything special.
>
> johan
>
>
> On 4/5/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
> >
> > why would the models component have to be null?
> > couldn't it be the one with the compound?
> > Or be the one with another main model?
> >
> > But this model (that is still not really a model) is just so that this
> > constructor:
> >
> > public ExternalLink(final String id, final IModel href, final IModel
> > label)
> >
> > can be called with 1 or 2 models that take the value out of a compount
> > model??
> >
> > Just use a property model for that... and do it yourself.
> >
> > new ExternalLink("id", new PropertyModel("href", XXXX), new
> > PropertyModel("label", XXXX))
> >
> > and XXX can be a compound or another model.
> >
> > the only thing you avoid here is the XXXX part because you still have
to
> > do new XxxxModel("label")
> > so what is the gain here?
> > What we do gain is suddenly models implementations that aren't really
> > model implementations.
> >
> >
> > johan
> >
> >
> > On 4/5/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >
> > > maybe when a wrap occurs on one of these we can check to make sure
> > > the model of the component is null (compound property model is being
> > > inherited). we would need to expose Component's check of model ==
> null
> > > in getModel() through something like isModelNull(). but that would
> make
> > > it fairly safe.
> > >
> > >
> > > Johan Compagner wrote:
> > > >
> > > > Then that name of that class is really wrong
> > > > So it is a model for something that isn't uses as the real model
of
> > > the
> > > > component??
> > > > Now it is just very fuzzy, and if used as normal model you get an
> > > > exception.
> > > > So thats not something i like to have in the core, that we can
have
> a
> > > > model
> > > > that can't be used as a model... (normal model)
> > > >
> > > > johan
> > > >
> > > >
> > > > On 4/5/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> Johan Compagner wrote:
> > > >> >
> > > >> > That one really doesn't work if i understand correctly what it
> > > should
> > > >> do
> > > >> >
> > > >> > i guess it should do this:
> > > >> >
> > > >> > Form form = new Form(new CompoundModel(new Person))l
> > > >> > form.add(new TextField(new ComponentPropertyModel("name")))
> > > >> >
> > > >>
> > > >> no. it's for use with something like ExternalLink which takes
> > > IModels
> > > >> that cannot work with compound models yet. the code above
already
> > > >> works with just: new TextField("name")
> > > >>
> > > >>
> > > >>
> > > >> >
> > > >> > AssignmentWrapper(final Component component, final String
> > > propertyName)
> > > >> >
> > > >> > /**
> > > >> > * @see
wicket.model.INestedModelContainer#getNestedModel
> ()
> > > >> > */
> > > >> > public IModel getNestedModel()
> > > >> > {
> > > >> > return component.getModel();
> > > >> > }
> > > >> >
> > > >> > And this piece of code is really wrong. the getNestedModel
should
> > > >> return
> > > >> > the
> > > >> > parent model of the current model and that is not the
> > > >> component.getModel
> > > >> ()
> > > >> > because that is the assigmentwrapper it self!
> > > >> >
> > > >> >
> > > >>
> > > >> the component has no model in the case where you use this class
> > > >> so getModel will find the compound model via initModel().
> > > >>
> > > >> use case for this model is ONLY:
> > > >>
> > > >> final ExternalLink titleLink = new ExternalLink("title",
> > > >> new ComponentPropertyModel("link"), new
> > > >> ComponentPropertyModel(
> > > >> "title"));
> > > >>
> > > >> where more than one model is being used by a component and that
> > > component
> > > >> cannot directly support compound propertymodels. the idea is
that
> > > this
> > > >> functionality
> > > >> will be folded into PropertyModel so the use case will just be:
> > > >>
> > > >> final ExternalLink titleLink = new ExternalLink("title",
> > > >> new PropertyModel("link"), new PropertyModel(
> > > >> "title"));
> > > >>
> > > >> again, the component has no model. it's referencing the compound
> > > >> property
> > > >> model
> > > >> of the parent.
> > > >>
> > > >>
> > > >> --
> > > >> View this message in context:
> > > >>
> > >
>
http://www.nabble.com/The-new-ComponentPropertyModel-tf3531176.html#a9859800
> > > >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> > > >>
> > > >>
> > > >
> > > >
> > >
> > > --
> > > View this message in context:
> > >
>
http://www.nabble.com/The-new-ComponentPropertyModel-tf3531176.html#a9861817
> > > Sent from the Wicket - Dev mailing list archive at Nabble.com.
> > >
> > >
> >
>
