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

BindingBuilder weird behavior with Converter, throws exception. #9619

Closed
jrfinc opened this issue Jun 30, 2017 · 3 comments
Closed

BindingBuilder weird behavior with Converter, throws exception. #9619

jrfinc opened this issue Jun 30, 2017 · 3 comments
Milestone

Comments

@jrfinc
Copy link
Contributor

jrfinc commented Jun 30, 2017

I have found that when binding a field, and setting a converter, the builder does not work as expected.

The following:

        IntItem item1 = new IntItem(10);
        Binder<IntItem> binder = new Binder<>(IntItem.class);
        Binder.BindingBuilder builder = binder.forField(field);
        builder.withConverter(new StringToIntegerConverter("error"));  // < --------------- 
        builder.bind("number");
        binder.readBean(item1);
        this.addComponent(field);

Throws java.lang.IllegalStateException: cannot modify binding: already bound to a property.

However setting the converter and binding in one line like this:
builder.withConverter(new StringToIntegerConverter("error")).bind() or saving it like this:
builder = builder.withConverter(new StringToIntegerConverter("error")). works as expected.

I think needing to "save" the builder is inconsistent, as for what I've tested this is not needed in the case of a Validator (and not quite what one would expect of a builder).

Here's a simple example: https://gist.github.com/jrfinc/c8414af2eaaec0c081ccead78df26907

I'm using 8.1.beta3 but I've tested it with 8.1-SNAPSHOT too.

@tsuoanttila
Copy link
Contributor

The main idea is to use the binding builder as a fluid API, chaining the commands. The typing of the builder actually changes when you apply a converter to it (String -> Integer), which can't be made type-safe to use with method references (.bind(IntItem::getValue, IntItem::setValue)) without this type of approach.

@jrfinc
Copy link
Contributor Author

jrfinc commented Jul 3, 2017

Yes I understand, what I attached is just a sample to show the error, and of course could be changed to used a fluid API.
In practice, to avoid repeating myself, I have generic methods to build and bind fields, otherwise, I would have waaay too much repeated code. In these cases I have to check things before setting converters, or iterate over a list of validators, etc., and cannot use the fluid API.

@tsuoanttila
Copy link
Contributor

if you have your own piece of code that figures out what converter you need, you can actually always apply a converter (see: Converter.identity()) and chain a converter same way every time.

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