Duplicate method set in BindableProxyLoaderImpl

[saso5]

Because of legacy code (GXT 2.0) our models contain "get" and "set" method with the same signature as default methods in BindableProxyLoader so the compiler throws an error "Duplicate method set(String, Object) ...".

I've looked at the BindableProxyLoaderGenerator and don't see any way of turning off specific fields.

Could you add an annotation for this kind of fields or just skip them in the generator?

[mbarkley]

Hi Sašo,

Could you add an annotation for this kind of fields or just skip them in the generator?

Could you clarify what you mean by this? Is it that you have a model of type A that has a property of type B and B as a set(String, Object) method?

[saso5]

This is the the GXT interface that all our model objects implement. When I annotate them, I get a conflict because BindableProxyLoader also creates the "get(String)" and "set(String, Object) method.

ModelData (Sencha GXT 3.1.4)

[saso5]

I would really appreciate some input here, so we can decide how to proceed forward.

[mbarkley]

Unfortunately there's no way to avoid generating a proxy with set(String, Object) and get(String) methods for a @Bindable type. It's unlikely we could come up with a fix for this issue before our upcoming 4.0.0.Final release.

The best suggestion I have for you is to write a wrapper classes for you GXT models to use with data-binding. Data-binding properties are inferred from method names so something like this could work (where there are getters and setters for all the properties in the wrapped type that all delegate).

[saso5]

Max, thank you for a quick response.

For now, I've done exactly that - class wrapper, but we have a few hundred model objects which would mean a lot of overhead, conversions.... there is also a problem of models inside of models... (one-to-one, one-to-many).

While we are testing the framework and getting things started it's not a big problem, but eventually, this will become a show-stopper.

Can we rely on a fix for this or should we start looking for an alternative approach?

[mbarkley]

Unfortunately I cannot guarantee a fix for this issue. We currently have users of the BindableProxy API (they use it for limited run-time reflection on @Bindable models), so we would have to investigate solutions that maintain or minimize change to the API.

Still I encourage you to create a JIRA to track the issue. I will at least be able to investigate the issue after Errai 4.0.0.Final is released.

[saso5]

I've added the issue to Jira. I was thinking of creating a local fix in the meantime. I could make a pull request if you'd like, but not sure which way you are leaning with a "fix" - annotation or skipping the property.

[mbarkley]

Well if you are planning to come up with a fix yourself I would be happy to review a PR to see if it should go into master. Like I said before, this probably isn't something we can merge into master before our 4.0.0.Final release but possibly shortly afterwards.

As long as a fix doesn't break existing API I am not very opinionated about how to approach this.