Questions

[Evangelink]

I am currently trying to create some projects using your MVC framework and it seems some of the code you are using in fsharp-wpf-mvc-series are now missing or have changed.

What is the current recommended way to use an existing converter (for example a BoolToVisibility converter)? It seems the only correct way (based on my understanding of your code) is to provide a function that acts as converter and not to use a converter class (IValueConverter).

I am also wondering how you would handle displaying a message (for example message box but I assume the behavior would be the same) at the end of an operation? For now, I am passing a method (string -> string -> unit) as an argument of my controller and I call this method when needed. Doing so I am able to keep my unit tests quite simple as I can fake my methods. But I am wondering if the problem should not be inverted, meaning that the XamlView implementation should not subscribe to a result of the controller's method to trigger the message box.

[dmitry-a-morozov]

Hi,
I apologize for delayed response.

1. BoolToVisibility converter.
   To solve this issue I can bring back pseudo extension method Apply
   https://github.com/dmitry-a-morozov/fsharp-wpf-mvc-series/blob/master/Chapter%2012%20-%20BindingMicroDSL/FSharp.Windows/Binding.fs#L33

But I recommend to avoid 2-way converters for several reasons:

• Hard to debug & unit tests
• Exceptions/errors in ConvertBack method are problematic
• A converter is bad place to keep presentation logic - it belongs to controller.
  Some of my thoughts on the subject is here
  https://github.com/dmitry-a-morozov/fsharp-wpf-mvc-series/wiki/Data-Binding.-Growing-Micro-DSL
  Also chapter 7 of F# Deep Dives, pages 177-178 have some relevant comments.

My suggestion - define property of type Visibility on a model. Based on it you can have conditional logic in controller or define one-way data bindings that depends on a value if this property.

2. Message box invocation from inside a controller is tricky topic. It's certainly most underdeveloped part of the library. Please give some time to write down my thoughts and maybe come with some code examples.

[Evangelink]

Hi,
First of all, thank you for your response.

1. I am quite keen to put back the Apply method to make it easier to switch to your framework.
   But I think you are right to recommend to use controller or model based conversions are we have more control on the result, the errors and it is probably also easier to test.

2. Perfect. I am waiting for your ideas.

[dmitry-a-morozov]

Would you mind to send a PR for Apply? Attach unit test(s) that cover both Convert and ConvertBack.

[dmitry-a-morozov]

Have a look at
https://github.com/fsprojects/FSharp.Desktop.UI/tree/DialogService

The core change: IDialogService interface.

Let me know if you need more clarifications.

But that's not all I have in mind. I was not particularly happy with a way navigation
handled in the series.
https://github.com/dmitry-a-morozov/fsharp-wpf-mvc-series/wiki/Child-Windows

I'm going to create another branch based on DialogService to show my ideas. I'll keep you posted.

[Evangelink]

Sorry to answer only now, but I had a busy time.

Thank you for your changes I will have a look at it.
By the way, it's fine for me to try the PR for the Apply .

Cheers

[dmitry-a-morozov]

I pushed a small update to DialogService branch