Radical Documentation
View on GitHub
release-2
release-2
  • Home
  • Presentation
    • AbstractViewModel
    • Conventions
      • Bootstrap Conventions
      • Runtime Conventions
      • Conventions override
    • Commands and DelegateCommand
    • IViewResolver
      • Default view behaviors
      • view life cycle events
        • Callback expectations
        • notify messages
    • Message broker MVVM built-in messages
    • Application boot process
      • Application configuration
      • Application shutdown
      • Singleton applications
    • AbstractMementoViewModel
      • Simple ViewModel graphs
      • Collections and complex ViewModel graphs
    • Validation and Validation Services
    • Resources
      • Services as resources
      • ViewModels as resources
    • UI Composition
      • Region content lifecycle
      • TabControl region
      • Create a custom region
  • Concepts
    • Inversion of Control
      • Third party DI containers
    • Entities
      • Property System
    • Messaging and Message Broker
      • POCO messages
      • Standalone message handlers
    • Observers
      • PropertyObserver
      • MementoObserver
      • BrokerObserver
  • Memento
    • Change Tracking Service
      • MementoEntity and MementoEntityCollection
      • Handling change tracking:
        • Simple model
        • Collections
        • Complex objects graph
      • Atomic operations
      • Change Tracking Service API
      • Property Metadata for the ChangeTrackingService
      • Handling collection sync
      • Property State
  • Behaviors
    • DataGrid Behaviors
    • Password
    • Generic routed event handler to command behavior
    • Overlay adorner
      • Busy status manager
    • TextBox behaviors:
      • Command
      • Auto select
      • DisableUndoManager (.Net 3.5 only)
  • Markup Extensions
    • Editor binding
    • Auto Command binding
  • How to
    • Get the view of a given view model
    • Bi-directional communication between different windows/views
    • Handle the busy status during async/long running operations
    • Implement a customer improvement program
    • Manage focus
    • Create a splash screen
    • Access view model after view is closed
    • Intercept ViewModels before they are used
  • Upgrade guides
    • Radical Presentation 1.x to Radical 2.x for .NET Core
Powered by GitBook
On this page
  • Intercept ViewModels before they are used
  • Interceptors
  1. How to

Intercept ViewModels before they are used

PreviousAccess view model after view is closedNextRadical Presentation 1.x to Radical 2.x for .NET Core

Last updated 4 years ago

Intercept ViewModels before they are used

One of the typical scenario in a desktop application is the requirement to “open” a new view passing to the newly created view/view model some data, the ideal solution is also to be able to pass data to the constructor of the new view model in order to be sure that at the end of the construction process everything is correctly setup.

When dealing with Inversion of Control framework this is generally a pain point because each framework provides ways to achieve the goal, but generally the solution is really weak and full of pain points.

In order to solve the above problem the general approach is something like the following:

var viewModel = myFavoriteIoC.Resolve();
viewModel.Initialize(someData);

In a view first scenario, like the one proposed by default by Radical this is not so easy because you end up with the following code:

var view = viewResolver.GetView<MyView>();
var viewModel = conventions.GetViewDataContext( view ) as MyViewModel;
viewModel.Initialize( someData );

it works, using the built-in we retrieve an instance of the attached view model and set it up, but the problem is that the setup occurs after that the view model has been wired to the view, and in some cases this is not ideal.

Interceptors

The Radical lets the user intercept the view model before it is wired up to the view:

var view = viewResolver.GetView<MyView>(vm => 
{
  //do what you want with the view model
});

the Action that intercept the view model is called before the view model is attached to the view, in the above sample, since we cannot infer the view model type, the view model is passed to the action as object, if you know upfront the type of the view model you can explicit tell Radical what it is:

var view = viewResolver.GetView<MyView, MyViewModel>(vm => 
{
  //do what you want with the view model
});

And the delegate will be of type Action<MyViewModel>.

conventions
view resolver