With the MVVM pattern, how does one go about dynamically binding
an ICommand to the click event of a hyperlink inside of a
RichTextBox?
It's a few steps to get there, but you can do it.
You have to use a bindable rich text box, rather than the one that comes with WPF which is not something you can bind. Details here: http://michaelsync.net/2009/06/09/bindable-wpf-richtext-editor-with-xamlhtml-convertor
Once you have that, you'll have a Rich Text Editor that you can bind to a FlowDocument in your ViewModel.
When your FlowDocument is created, hookup a handler for the Hyperlink.ClickEvent in your ViewModel:
Here's the call that adds the handler to the FlowDoc
TheDocument.AddHandler(Hyperlink.ClickEvent,
new RoutedEventHandler(HandleHyperlinkClick));
//Here's the handler definition
private void HandleHyperlinkClick(object sender, RoutedEventArgs args)
{
Hyperlink link = args.Source as Hyperlink;
//...
}
This is the only thing I've ever seen done. FlowDocuments are a little strange because they are sort of a data type and sort of a visual element so in some sense it feels wrong to have it reside in your ViewModel, but this is the way to go.
You find a lot scenarios where it is not possible to use wpf data binding. In these scenarios you can create a new control (e.g. inherit from RichTextBox) and provide the missing dependency properties so you can use data binding.
However, creating a new control to handle simple scenarios is inefficient. It's not forbidden to implement code in the View's code behind file and this makes often more sense than creating a new control.
A concrete example how this can be done is shown in the ViewModel sample of the project:
WPF Application Framework (WAF)
http://waf.codeplex.com
Related
Rookie question that I'm not having much luck with. In my e4 RCP application, I have a couple of instances where I create an object in a wizard that should then appear in one of my views.
The desired behavior is similar to how the eclipse Package Explorer View updates after a new project is created.
I was thinking I could just grab the view from the partService and run my own update method:
MPart ingredientsView = partService.showPart("com.personal.recipes.part.ingredientsview", PartState.ACTIVATE);
IngredientsView iv = (IngredientsView) ingredientsView.getObject();
iv.updateView();
While this works in other places, when called from a wizard 'partService' is null and the app NPE's out.
So what is the proscribed method of forcing e4 views to update after modifying their contents?
EDIT:
I tried to use the ContextInjectionFactory like #greg-449 showed in his answer, but I'm uncertain where to place it in my code, or how to define the context. I'm launching the wizard from a toolbar button, and placed the following code in my handler:
#Execute
public void execute(Shell shell) {
IEclipseContext context = EclipseContextFactory.create();
IWizard ingredientWizard = ContextInjectionFactory.make(IngredientWizard.class, context);
WizardDialog wizardDialog = new WizardDialog(shell, ingredientWizard);
wizardDialog.open();
}
However, when I tried to get the part service with #Inject EPartService partService; I got an InjectionException saying no error was found.
Once injection is available, using the EventBroker looks like the way to go.
enter code hereThe best way to update a view is to use a model for the content of the view. Your wizard seems to allow editing or creating ingredients. When you perform the finish of your wizard you are probably modifying some ingredient data. The ingredient model should be informed of these changes. If the view uses a content provider that observes this model is will update automatically when the model sees the update (this is the observer pattern).
How this works depends on the nature of your data. You could use the PropertyChange-Support in Java.
To do so let the content provider implement the org.eclipse.jface.util.IPropertyChangeListener interface and fire property change events when the data is changed.
UPDATE
My ContentProvider implements the property change interface. Whenever a property change event is received the viewer is refreshed(asynchronously). All my persistence operations are handled by data managers similar to Fowler's the table data gateway pattern but sometimes for more than one table. The data manager fires the property change event. This way the UI (wizard) does not need to know about persistence
Injection is only done on objects that the application model knows about. So it is not done on Wizards or Dialogs unless you do it 'manually' using ContextInjectionFactory when you create the dialog:
IWizard wizard = ContextInjectionFactory.make(YourWizardClass.class, eclipseContext);
WizardDialog dialog = new WizardDialog(shell, wizard);
This will do injection on your wizard class giving you access to the EPartService.
You could also use the 'event broker' (IEventBroker) to broadcast an event to anything that is interested rather than finding your specific view.
I am developing painting application in which i need to save my painting.
To save i need to show save file dialog , As i am implementing MVVM pattern i can't directly use event handler.
But while implementing i thought of using PropertyChanged event directoly.
I have implemented INotifyPropertyChanged in ViewModel , I have bind all commands.
In save command in ViewModel i have called
OnPropertyChanged("Show Save Dialog"); // in ViewModel
and in code behind of user control I have added event handler as
ViewModel.PropertyChanged += new // in code behind of user control
System.ComponentModel.PropertyChangedEventHandler(ViewModel_PropertyChanged);
and in ViewModel_PropertyChanged i have
switch (e.PropertyName ) // in code behind of user control
{
case "Show Save Dialog": ShowSaveFileDialog();// this function shows dialog.
break;
}
This works fine in my situation but I don't know the dark side of this implementation.
Is it right ????
Right? There is no right or wrong, only the best choice at the current time. The only way for purists would be to abstract away the process of gaining such input from the user behind an interface, then create a View class which serves this interface and inject it somehow (IoC/DI, or perhaps by composition in the xaml if your ViewModels are instantiated that way).
Personally, I wouldn't spend too much time worrying about this, unless you must worry about this. I've done it both ways. For your average MVVM app, I think it is no great crime to just use a MessageBox, OpenFileDialog, etc. For heavily tested apps, you'll need to abstract it away. And there are other situations that demand it as well. For example, I have code that exists in an application and in a Visual Studio extension. VS has its own dialog types which should be used instead of, say, MessageBox. So abstraction is appropriate. But I wouldn't invest the work unless I had a reason to.
Why don't you just create a custom event? Something like this in your ViewModel:
public event EventHandler<EventArgs> ShowSaveDialog;
and then use
ViewModel.ShowSaveDialog += OnShowSaveDialog;
private void OnShowSaveDialog(object sender, EventArgs e){
//handle the event
}
I wouldn't just "abuse" PropertyChanged like that. There's probably nothing wrong with your implementation, it just doesn't feel right. Also, you're using magic strings, but if you have a custom event it's much more declarative, and other users of your code will immediately figure out there is a way to subscribe to this event.
If you need to pass extra information, then make a implementation of EventArgs and add the properties you need.
Well as Will said there is no right or wrong ... only best choices!
Personally, I tend more to the purist side and try to architect a system to have a clear separation of concerns ... but that's just me!
Here is an answer I gave to a post dealing with the same problem as yours. There I show the two current approaches floating around when you want to keep your view model clean of any view code.
But again, choose the way that best fits your needs/preferences!
Lets say that on all my views, or generally at any time in my app, I want to be able to show an error message popup, and it always looks the same. How do I do that?
First thought is having all my view models extend a base view model which facilitates these things, but after that, do I have this base view model actually create the UI widgets and display them?
thanks,
Mark
If you've got some common functionality that you want to provide across a range of views, then you can implement a base class that inherits from the PhoneApplicationPage, and then derive all your classes from that class instead. The XAML for your pages then looks like this:
<local:BasePage xmlns ...
xmlns:local="clr-namespace:MyNamespace"
x:Class="MyNamespace.MyPage">
However, you will not be able to define common UI components in the XAML for your base page. If you wanted to have common UI components you would have create them manually in the code-behind for the base page, perhaps in a handler for the Loaded event, but I think a better solution would be to provide your common UI in a UserControl, which you then add to each of your pages.
If you want to show a Toast or Message Box, then I would recommend the ToastRequestTrigger and MessageBoxRequestTrigger from the Silverlight Toolkit as described in the patterns & practices WP7 Developer Guide.
you could probably define an event on base view model, which is fired inside view model whenever an error occurs, then in view, you can subscribe to this event and display the popup. You can carry error context in EventArgs of the fired event.
Additionally you could unify the logic for displaying the popup but that's probably another story :)
This is testable and nicely decoupled from the view.
Hope this helps,
Robert
I have a WPF user control ...which is in MVVM. The user control(which contains a listview) need data from the page (where it is included). I have to set a property in View's code behind to get this data input. Will this comply with MVVM(But MVVM pattern do not support adding code in code behind file of view as far as i know).if not, what is the way for the same?
You want to do this via data binding. The controls are bound to properties in your viewmodel which receives the data, applies the needed logic and gives it back to the view for displaying it.
Have a look here to get an idea on how all that works.
I have got a link : http://social.msdn.microsoft.com/Forums/en/wpf/thread/a3eedc3e-0d59-420c-aba0-44fe8b00552f
But I'm not really getting whats meant by injection in it (as given below) :
an interface to the UserControl public model called IUserControlModel. It has the properties that should be visible from outside;
- a UserControlViewModel that contains a public property of type IUserControlModel that is injected in the constructor; plus all the properties used for XAML binds specific to the usercontrol implementation; XAML may have binds directly to the IUserControlModel properties too;
- a MainWindowViewModel that nests the IUserControlModel inside.
I think your problem can be solved in easier way. If you expose ItemsSource property of ListView as Dependency Property of your user control you can achieve what you want without unnecesary (in this case) overhead of implementing MVVM pattern : You then can just use databinding to add data from the page where the user control is included.
post that I think answers your question :
Post link
I'm using MVVM in a WPF app. I'm very new to both. Let me state that I am not a purist in the MVVM pattern, I am trying to use as many best practices as I can but am trying to make what I think are reasonable compromises to make it work in our environment. For example, I am not trying to achieve 0% code in my View code-behind.
I have a couple of questions about best practices.
1) I understand I don't want my VM to know about the attached View, but is it reasonable for the View to have a reference to its VM?
2) If a control in a View opens another View (such as a dialog) should I handle this in the View? It seems wrong to handle it in the VM since then the VM has some knowledge of a specific View.
1) The View has definitely a reference to the ViewModel through the DataContext. And you are allowed to cast the DataContext in your View:
public class ShellView : Window
{
…
public ShellViewModel { get { return DataContext as ShellViewModel; } }
This isn’t a violation with the Model-View-ViewModel pattern.
.
2) You are right. A ViewModel shouldn’t open another View. A better approach is to use Controllers. They are responsible for the Workflow of an application.
If you are interested in more detailed information then you might have a look at the WPF Application Framework (WAF).
1) Here are two simple practices for View's "knowing about" a ViewModel. It's reasonable for a View to know about a ViewModel (for Data Binding) -- but you may not need it in your case. See if either of these approaches help solve your problem. There are other ways, but these should be simple enough:
public View(ViewModel vm)
{
View.DataContext = vm;
}
public Bootstrapper(View v, ViewModel vm)
{
v.DataContext = vm;
//or, if you want it to have no parameters
View v = new View();
ViewModel vm = new ViewModel();
v.DataContext = vm;
}
The first option isn't bad if you have a service location tool, but there is a flavor of MVVM that doesn't like any code in the View's Code-Behind. The second option isn't bad either, should be simple enough for your task.
2.) This question can be a bit of a sticky point in MVVM design. If we are talking about a general Win32 MessageBox, I will often separate that logic into an additional object and put it in the VM. This way tends to a little more clear. (For example, I have selected an item in a ListBox, I have attached a Delete ICommand to that action, and in my ViewModel when this ICommand is Executed, I will poke my MessageBoxObject to ask if the user "wants to really delete" this item). More advanced "Dialogs" would use additional ViewModels and DataTemplates for those ViewModels. I prefer the Mediator approach.
1). The view will need a reference to the view model at some level, since the viewmodel will act as the view's datacontext.
2) One way to handle this is to have a generalized viewmodel representing a dialog, that is owned by the main viewmodel (the one being used as the views datacontext.)
You can use a command to crate a new instance of a dialog viewmodel, which will have a corresponding datatemplate defined in your resources. This template will be set to bind to the dialogviewmodel type.
Quite late, but I think this is tricky enough to deserve lots of different perspectives.
I understand I don't want my VM to know about the attached View, but
is it reasonable for the View to have a reference to its VM?
As already answered, a proper View-ViewModel arrangement involves the ViewModel being assigned as the View's DataContext property. That allows DataBindings to be "automagically" established from declarative XAML, or fine-tuned via code behind.
Sometimes, you'll be tempted to write, in your code behind, something like this:
var dc = DataContext as CleverViewModel;
CleverViewModel.CleverProperty.Add(someValue); // just a simple example
I believe the proper way to achieve this sort of things is NOT to cast DataContext, but instead:
Have some dedicated control in View, for example an ItemsControl with its ItemsSource two-way databound to some property in viewmodel:
<ItemsSource x:Name="cleverControl" Visibility="Collapsed" ItemsSource="{Binding CleverProperty, Mode=TwoWay}"/>
Cast the bound property instead of the whole ViewModel, in code behind:
var collection = (ObservableCollection<double>)cleverControl.ItemsSource;
collection.Add(someValue);
Note the important difference: the second approach in this example doesn't require the View to know the ViewModel type, it only needs a property named CleverProperty of type ObservableCollection<double>. This allows me to have polymorphic or even duck-typed ViewModels.
If a control in a View opens another View (such as a dialog) should I
handle this in the View? It seems wrong to handle it in the VM since
then the VM has some knowledge of a specific View.
This shouldn't happen in strict MVVM, and its not difficult to avoid using DataTemplates. DataTemplates map a given type of DataContext to a given type of view, so anytime the datacontext of a ContentControl changes, its display also changes, provided that you have a DataTemplate for that type:
A control in the view could send a command to the ViewModel, which in turn would update some of its own properties, that would be reflected by the view.
A View could contain another View, outside the knowledge of the ViewModel. In this case, the code behind can manipulate the datacontext of the contained view.
There are more subtleties, but I have been using this approach with good results. Hope this helps someone.
Build Your Own MVVM Framework
I found the approach suggested by Rob Eisenberg very interesting.
Key points:
Convention over configuration
ViewModel first
Which is very similar to ASP.NET MVC philosophy.
I highly recommend watching the video.