inspecting property models

[Ryan Sonnek <ry...@gmail.com>]

This discussion came out of the recent hibernate wicket-stuff
activity.  For my behaviors/validators/listeners to work, I need to
have visibility into the PropertyModel's internal configuration.  In
particular, I need access to the:
* propertyExpression configured for a particular form component
*  targetClass that this model is using

I've worked around this for now by creating a subclass
(HibernateAnnotationPropertyModel), but it's pretty restrictive and
unfortunate that users are forced to use this non-standard property
model.

Any opinions on a better way to go about this, or change the
wicket-core to support this use case?

http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/trunk/wicketstuff-hibernate-behavior/

Re: inspecting property models

[Ryan <cr...@gmail.com>]

There are times when I would like to use a property model to return the
result of a method that is evaluated on a chained model. In Wicket 1.2 I did
something like this:

new PropertyModel(new Model(someModelOfMine), "someExpression");

This worked because Wicket 1.2 only un-nested models one level deep before
evaluating the expression. Wicket 1.3 no longer has this behavior (which is
fine) so I created a NonUnwrappingPropertyModel that overrode getTarget()
that recreated wicket 1.2 behavior. The recent change of getTarget to be
public final caused this code to break.

Is there another way to accomplish what I am trying to do? Is this a good
use for getTarget to be non final?

Ryan

On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > Why limit to getTargetClass() when its possible to return with
> getTarget()
> > and do a getTarget().getClass() ?
>
> It's a different intention. I was thinking about the type of the
> property, not the target, which is the parent of the property.
>
> Btw, I made getTarget public and final. Team, feel free to roll back
> if you don't agree, but I couldn't think of anything against this.
>
> Eelco
>

Re: inspecting property models

[Ryan Sonnek <ry...@gmail.com>]

On 5/12/07, Johan Compagner <jc...@gmail.com> wrote:
> But it is not the same anyway
> you can't call getTarget().getClass()
>
> that is at least not the class of the property that can never be
> Person.Address.Street (street is a string)
>
> what is the target? Street? but that can be null because it is not set yet
> or is the target Address? Because thats the target where you call
> setStreet(String) on
> but then the class is not the properties class.
>
I understand the model can be null.  If that's the case, I'm SOL
anyways.  Nested property models are tricky, but for right now I
really don't care about them.  It's more of an edge case and isn't the
main use case I'm trying to work with.

Re: inspecting property models

[Johan Compagner <jc...@gmail.com>]

But it is not the same anyway
you can't call getTarget().getClass()

that is at least not the class of the property that can never be
Person.Address.Street (street is a string)

what is the target? Street? but that can be null because it is not set yet
or is the target Address? Because thats the target where you call
setStreet(String) on
but then the class is not the properties class.

so the only thing you can get is the targets property class

johan




On 5/12/07, Ryan Sonnek <ry...@gmail.com> wrote:
>
> On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > Why limit to getTargetClass() when its possible to return with
> getTarget()
> > > and do a getTarget().getClass() ?
>
> I agree with Eelco.  There's nothing "wrong" with exposing the target
> and then calling getClass(), it's just not what I needed.  I didn't
> here anyone else chime in on what they needed for inspecting models...
>

Re: inspecting property models

[Ryan Sonnek <ry...@gmail.com>]

On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > Why limit to getTargetClass() when its possible to return with getTarget()
> > and do a getTarget().getClass() ?

I agree with Eelco.  There's nothing "wrong" with exposing the target
and then calling getClass(), it's just not what I needed.  I didn't
here anyone else chime in on what they needed for inspecting models...

Re: inspecting property models

[Eelco Hillenius <ee...@gmail.com>]

> Why limit to getTargetClass() when its possible to return with getTarget()
> and do a getTarget().getClass() ?

It's a different intention. I was thinking about the type of the
property, not the target, which is the parent of the property.

Btw, I made getTarget public and final. Team, feel free to roll back
if you don't agree, but I couldn't think of anything against this.

Eelco

Re: inspecting property models

[Bruno Borges <br...@gmail.com>]

Why limit to getTargetClass() when its possible to return with getTarget()
and do a getTarget().getClass() ?

-- 
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060

On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > This discussion came out of the recent hibernate wicket-stuff
> > activity.  For my behaviors/validators/listeners to work, I need to
> > have visibility into the PropertyModel's internal configuration.  In
> > particular, I need access to the:
> > * propertyExpression configured for a particular form component
>
> That's a bit weird currently. One option I see is to put:
>
> public final String getPropertyExpression() {
>   return propertyExpression();
> }
>
> in AbstractPropertyModel.
>
> I can't see much wrong with this, so I went ahead and comitted it.
>
> > *  targetClass that this model is using
>
> I think we need to change Wicket core for this. In fact, I think it's
> a broader use case than just property models. I can imagine something
> like IModelTargetTypeAware or something. Besides giving you the tools
> to inspect more, it would also enable us to get rid of that ugly type
> argument in text form components.
>
> I won't be active much for the next few weeks, so Ryan, you'll have to
> push this a bit yourself :)
>
> Eelco
>

Re: inspecting property models

[Eelco Hillenius <ee...@gmail.com>]

> This discussion came out of the recent hibernate wicket-stuff
> activity.  For my behaviors/validators/listeners to work, I need to
> have visibility into the PropertyModel's internal configuration.  In
> particular, I need access to the:
> * propertyExpression configured for a particular form component

That's a bit weird currently. One option I see is to put:

public final String getPropertyExpression() {
  return propertyExpression();
}

in AbstractPropertyModel.

I can't see much wrong with this, so I went ahead and comitted it.

> *  targetClass that this model is using

I think we need to change Wicket core for this. In fact, I think it's
a broader use case than just property models. I can imagine something
like IModelTargetTypeAware or something. Besides giving you the tools
to inspect more, it would also enable us to get rid of that ugly type
argument in text form components.

I won't be active much for the next few weeks, so Ryan, you'll have to
push this a bit yourself :)

Eelco