InteractivityQuickstart with an Injection example about prism-samples-wpf HOT 12 CLOSED

I wouldn't use the interactivity for that, I would use a custom dialog service instead.

from prism-samples-wpf.

So... if i undertand it correctly, if i only use View and ViewModel Injection with MEF, i should not use interactivity at all ?
So how can i decouple ui and controller ? (mockup service)

from prism-samples-wpf.

I don't use MEF as it is not a DI container, so I am unable to help you there.

from prism-samples-wpf.

Also, even if a sample was created it would not use MEF, it would only use a container such as Unity.

from prism-samples-wpf.

I proposed MEF because i use it currently in a project but i also use Unity in others projects and, for me, the issue remains the same... (but i maybe haven't understand how to correctly use Unity)

from prism-samples-wpf.

Interactivity is not meant to be a silver bullet for showing all the dialogs in your app. Only use it for simple stuff. You will have a custom dialog service to handle the more complicated and full featured dialogs in your app.

from prism-samples-wpf.

I would add that while the original intent for interaction request was to have the pure separation of responsibility so the view model was never "deciding" what the UI was for an interaction, the implementation is so complicated compared to just letting your viewmodel do a ShowDialog with an appropriate View/ViewModel or doing a nav in a region to show something to a user, I almost never use it even for simple scenarios. Yes putting the call to ShowDialog makes that method in your ViewModel in-unit testable, but you can easily fix that by putting the call in a virtual factory method that you can override in unit tests. So I'm with @brianlagunas that this is not something I would spend time on.

If you are really convinced you want to stick with interaction request, you would either have to do it in the code behind of the view (whether MEF, Unity, Autofac or any container because XAML can only call default constructors in the parsing process. Or possibly there would be a way to attack it with a custom markup extension, but that is only available in WPF. There was a framework someone put together back in the glory days of WPF and MEF called MEFfedMVVM or something like that which I think used custom markup extensions to let you "inject" things in XAML, but never spent any time with it myself.

from prism-samples-wpf.

@brianlagunas @briannoyes I do not think that "custom dialog service" is a good suggestion. The user will have to solve from scratch all the problems that are handled by InteractionRequest: positioning the dialog window, setting its parent window, closing the dialog window from within the view model, etc.

the implementation is so complicated

I agree that current design of InteractionRequest is a bit messy. My major complains are:

a) Built-in dialog windows with one or two buttons are not really usable in a real-world applications because they cannot be customized to the styling of the application.

b) Consequnce of (a): You need to create two view models for an interaction request, both for the same window content. See ItemSelectionViewModel/ItemSelectionNotification in the InteractivityQuickStart. It's a complete mess.

I started to use InteractionRequest in v.4 when there were no PopupWindowAction for WPF and implemented my own based on the same proto-code as Prism v.5. I simplified the thing and now use it a lot in all my projects for all dialogs and I am very satisfied with it.

Do you think you could change the InteractionRequest? This will be a breaking change, of course. I can wrap up a proposal for a change.

from prism-samples-wpf.

AutoWireViewModel is designed for View-First Navigation. You navigate to a view, and view model for the view is constructed automatically.

InteractionRequest works in the opposite direction: while sitting in the view model, you provide another view model in the InteractionRequest.Raise, and the view for that view model is auto-wired by the definitions in PopupWindowAction of the parent View.

An attempt to combine these contradictory approaches leads to a mess like ItemSelectionViewModel/ItemSelectionNotification.

InteractionRequest does not fit AutoWireViewModel. It works fine with View Model-First though.

from prism-samples-wpf.

Good distinction there of view-first vs viewmodel-first @dvorn in terms of identify the main point of impedance mismatch between the interaction request model and ViewModelLocator.

In terms of the custom dialog service, it obviously depends on the application requirements. I have worked on a number of apps where it was part of the design to have a common, shell-level experience for dialogs so that it was always consistent for the user. In that case centralizing the logic that creates the dialog, positions and sizes it, sets the parent and so on into a dialog service is a perfect fit and works well. To let the dialog's ViewModel control when it closes and so on it is easy to just have an interface contract that the viewmodel can implement (i.e. IDialogAware - similar to INavigationAware) that the DialogService can use to communicate with the ViewModel while the dialog is open while avoiding any unnecessary coupling between them.

If you want to leave the control of how the presentation happens to the individual views, well that was the original intent of the interaction request model. That code has to go somewhere in the view, so that means either code behind that is not easily reused or wrapped in a behavior so it is, which is exactly what the interaction request related behaviors are for presenting the view. I'm not opposed to considering adding a new behavior that does things differently if it is more flexible and has more options for controlling the presentation to meet people's needs, but would not want to do anything with the existing one to break existing users of it.

And like all requests like this, we are an open source project so if someone wants that bad enough, the way to do it is send us a PR with what you would propose and we will consider it, but we don't have time to implement everything everyone asks for.

from prism-samples-wpf.

@briannoyes

the logic that creates the dialog, positions and sizes it, sets the parent and so on into a dialog service is a perfect fit and works well. To let the dialog's ViewModel control when it closes and so on it is easy to just have an interface contract that the viewmodel can implement (i.e. IDialogAware - similar to INavigationAware) that the DialogService can use to communicate with the ViewModel while the dialog is open while avoiding any unnecessary coupling between them.

All this is already implemented in interactivity. The interface already exists and is called IInteractionRequestAware. Why let the user re-implement all this?

from prism-samples-wpf.

@briannoyes @brianlagunas I created a PR #25 to demonstrate how simple and straightforward interactivity actually is (review ItemSelectionViewModel). Unfortunately, current definitions of interfaces do not allow to make it even more clean.

It is possible with interfaces defined differently (a breaking change).

If you want to support ViewModelLocator in interactivity, a different definition of IInteractionRequest is needed which will not require a view model as an argument.

from prism-samples-wpf.