Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prefer @Property on @Entity metamodel generation #7

Open
lakemalcom opened this issue Apr 11, 2012 · 4 comments
Open

Prefer @Property on @Entity metamodel generation #7

lakemalcom opened this issue Apr 11, 2012 · 4 comments
Assignees
Milestone

Comments

@lakemalcom
Copy link

Having a non-standard getter (i.e. one that returns the field wrapped in an Optional) leads to the ClassNameMeta having a wrapper-typed metamodel field. Adding a @Property annotation doesn't help - perhaps the code can be tweaked to prefer the @Property annotation over the getter, when available.

@ghost ghost assigned david-hosier Apr 27, 2012
@david-hosier
Copy link
Contributor

This is not going to be doable, because MetaModel is just a PropertyModel that gives you a typesafe way to build up a property string. Wicket will then interpret that property string to use accessor methods. There is no way via the property expression to indicate that Wicket should use fields vs. accessor methods.

@lakemalcom
Copy link
Author

So rewrite the MetaModel class to incorporate useful bits of
PropertyModel and create a flag on SingularProperty that indicates a
preference for the field vs the method(s).

Or change the MetaModel / PropertyModel implementation to inspect the
return type of the getter / setter before using it.

On Mon, Apr 30, 2012 at 1:56 PM, David Hosier
reply@reply.github.com
wrote:

This is not going to be doable, because MetaModel is just a PropertyModel that gives you a typesafe way to build up a property string. Wicket will then interpret that property string to use accessor methods. There is no way via the property expression to indicate that Wicket should use fields vs. accessor methods.


Reply to this email directly or view it on GitHub:
#7 (comment)

@ivaynberg
Copy link
Member

this would require writing our own property resolving mechanism. the one inside wicket is not meant to be extensible because it is optimized.

@ivaynberg ivaynberg reopened this May 2, 2012
@ivaynberg
Copy link
Member

  • Type of Property needs to take into account the type of field or getter based on the preferred one
  • Property already has get(instance) method, it will need to be tweaked to take the preference of getter/field into account
  • MetaModel's get/set methods will need to split the property expession and loop over each segment calling the correct Property's get/set methods depending on whether or not getObject or setObject is called.
  • The traversal in MetaModel will have to safely handle nulls in getObject

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants