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

Would it make senese for FlatMapProperty to provide orElse(...) implementations? #3

Open
ryanjaeb opened this issue Nov 29, 2014 · 2 comments

Comments

@ryanjaeb
Copy link

Hi,

If there's a better place to post inquiries like this, please let me know. Would it make sense for FlatMapProperty to have orElse(...) implementations that return Property<?> types? Consider the following usage of EasyBind:

private final ObjectProperty<SomeModel> model = new SimpleObjectProperty<>();

private BooleanProperty disabled;
private Property<Boolean> modelDisabled;

{
    disabled = new SimpleBooleanProperty();
    modelDisabled = EasyBind.monadic(model).selectProperty(SomeModel::disabledProperty);
    disabled.bindBidirectional(modelDisabled);
}

Assuming the above is a reasonable thing to do, I'd like to handle the null cases more explicitly. For example:

private final ObjectProperty<SomeModel> model = new SimpleObjectProperty<>();

private BooleanProperty disabled;
private Property<Boolean> modelDisabled;

{
    disabled = new SimpleBooleanProperty();
    modelDisabled = EasyBind.monadic(model).selectProperty(SomeModel::disabledProperty).orElse(false);
    disabled.bindBidirectional(modelDisabled);
}

Basically I'm trying to do bidirectional select bindings.

I'm also curious with regards to how a swap of SomeModel would be handled in my first example. I assume it would be treated as a change in the selected property, so the disabled property would be updated from modelDisabled. Is that correct?

@TomasMikula
Copy link
Owner

Hi Ryan,

I think we could define orElse(T) returning a Property<T> in a meaningful way. The task is to define the behavior of set(T) on the returned property. We could define p.orElse(t0).set(t) to be the same as p.set(t).

Anyway, doesn't the following serve your purpose equally well?

modelDisabled = EasyBind.monadic(model)
        .map(SomeModel::disabledProperty)
        .orElse(new SimpleBooleanProperty(false))
        .selectProperty(Function::identity);

The only problem would arise if you do modelDisabled.set(true) while model was null. That would overwrite your default value false to true.

@ryanjaeb
Copy link
Author

Hey Tomas,

Sorry for the slow response. Yes, the snippet you posted accomplishes what I was trying to do. Overwriting the default value isn't a big deal. I would normally have the state bound to some type of input control (ie: checkbox) and would ensure that control is disabled when model is null.

It doesn't make any difference to me if orElse(...) is able to return a Property<T> given the example you suggested.

BTW, EasyBind is a fantastic library!

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

2 participants