What is the correct way to open a modal dialog in WPF using the latest version of the MVVM Light framework. I also want to be able to pass values to the ViewModel of the window used as the modal dialog.
I cannot find any samples on the MVVM Light site.
You should use the DialogService which abstracts the visual representation of the view so that you can do "Show" within the view model (and later possibly/hopefully) mock it for testing.
More info on the DialogService here.
-edit- I was wrong, as Alan Rutter (OP) points out the IDialogService is only for simple message boxes. I don't think MVVM light will help you much here but you can build a similar service (e.g. ICustomDialogService?). Custom dialogs can register as available with the service, and then the interface provides calls that will allow you to invoke a specific dialog by name (String or Enum perhaps) and pass any parameters you want.
Dialogs can register with the service in a few different ways - can happen for the type in static constructors (that you somehow have to force) or more explicitly through attributes in assemblies. Possibly even using class attributes. It depends on your startup sequence and general infrastructure.
Related
or "How to decouple UI from business logic in Delphi?"
Each target platform has its own set of native firemonkey controls (Windows=VCL, MacOS=TMS mCL, Android=D.P.F, iOS=TMS iCL and D.P.F). The new FireUI (multi-device form designer) is a great solution for styled components, but not for native components because it still requires the same component on the master pane to support all platforms. As you cannot mix them on the same form, it completely breaks the whole idea with Delphi.
A lot of developers would say that Delphi is the broken approach, see "Why FireMonkey is so fundamentally wrong in every aspect". However, the premise for this question is NOT to argue against Delphi, but to get the best results out of what it does offer.
The conclusion is then that for each form in your application you have to make a separate form for each target platform. This leads to these questions:
Challenge 1: How to include different form files in your project depending on your target platform?
Solution 1: include all of them, i.e. MainForm_IOS.pas, MainForm_Android.pas, MainForm_Win, MainForm_OSX.pas, and then use compiler directives inside the files, so only the content of one of the files is active. Disadvantage: a large application can have many forms (we have around 40), so we are talking about a large number of included files.
Solution 2: Do not include them in the project, but instead just place them in seperate folders. Then you can add the matching folder to the search path for each target platform. Disadvantage: They will not show up in the Project Manager, so it will slow down the workflow every time you need to find a file.
Solution 3: Create a project for each target platform. Disadvantage: Every time you add new units or change common project settings you have to (remember to) apply it to all projects.
Update: As suggested in the Malcom Groves video, placing all the business logic in a package will remove the disadvantage from Solution 3. So I consider solution 3 as the best approach.
Challenge 2: How to connect the different device forms to the (same) business logic?
Possible solution: Create a "Helper" class that contains all the code you would normally have in the form unit.
Update: This "Helper class" is actually what the MVVM calls a ViewModel. What I need seem to be a MVVM framework that can support the databinding. I have made another question about that.
Any input and suggestions about best practice are welcome.
For challenge 1:
You can conditionally link in your FireMonkey form resources depending on the compile target:
{$R *.Windows.fmx MSWINDOWS}
{$R *.Macintosh.fmx _MACOS}
etc.
This is excatly what the XE7 Multiview designer does, but I see nothing against using this mechanism to link whole form files conditionally in to your executable. Of course you might also want to ifdef the corresponding units in your project file.
For challenge 2: Just use some form of Model View Controler logic. So your platform dependant forms will talk to a platform independant controler.
I am new to this and still trying to get a feel for the best way to do things with MVVM. I can't find an answer with Google.
For convenience, I have created extensions on multiple custom classes, e.g.,
public static AppointmentLabel ToLabel(this textblockPatient tbp)
{
return tbp.appointmentlabel;
}
In my MVVM model, I have placed these extensions in the Model as they seem to convert one source of information into another. However, some of the custom classes are UserControls and live in the View. Doing it this way would require the Model to "know" something about the View, as the above textblockPatient is a UserControl.
How is this done within a MVVM pattern? Are extensions considered to be an exception to the pattern?
Thanks for any help.
In my opinion this is not a mvvm related thing. I would suggest that you put your extension classes near to the classes they extend. By doing it so you reach some level of cohesion. Sometimes it make sense to put the extensions in a seperate project. For example if you know you want need that extensions all the time and you want to have a small codebase or faster compile time.
I'm having a little bit of a hard time getting into mvvm. I'm writing a simple app, Notebook. I have one viewmodel, it's name is actually ViewModel. It has an ObservableCollection of Notes inside and methods to save and load those from Isolated Storage. My only Model is Note.cs, it implements INotifyPropertyChanged and I'm of course RaisingPropertyChanged.
I've also got two view, both of them are user controls. One to display list of notes and one to edit the one chosen from the list.
My questions are:
Where do I create an instance of my vievmodel?
How should I implement going from the page with list of notes to the page with detailed view after choosing one Note to edit? At the
moment I'm saving the index of Note in App.xaml.cs, going to the next page and setting
the DetailedView DataContext to the right Note in OnNavigatedTo, but
I don't think it's actually the perfect solution.
Where should I save my Notes? I guess Application_Closing in App.xaml.cs is the right place to do it, but I'd have to have my viewmodel as a global object there, is this the right approach?
Additional question:
I have to add possibility to group notes. I guess that class Group with dictionary (GroupName, howManyNotes) is going to be allright since I don't have to be able to for example write all notes from selected group. Do you think there's a better approach I should think about?
Thanks for respones,
Michał.
I would suggest you take a look at Calibrun.Micro which is a great framework for MVVM. You can get some sample from the CodePlex.
I have used that in a bunch of Project, and will give you flexibility in case if your project grows in size.
Google for Caliburn.Micro sample and you will find a number of sample for all technologies like WPF, Silverlight, Windows Store, Windows Mobile.
Caliburn.Micro CodePlex
I have a Wizard with two pages: pageone extending WizardNewProjectCreationPage, and pagetwo is extending WizardPage. I want the user to be able to create the project first, and then add files to the project on the second page.
For the latter I want to use a SWT Table (?) like when you pick an interface in the Java Class Wizard in Eclipse IDE (cf. picture here). Also the "Add" button next to it.
How can I achieve this? Do I have to use Eclipse Forms API for this? Or simply add a SWT Table? I have used the Plug-In Spy but the source code given in NewClassWizardPage and NewTypeWizardPage seems to be very specific to this example and I cannot make sense of it.
I've also had a look at vogella's tutorial for JFace table, but I can't get my head around it.
Just some basic steps would be great, or maybe somebody has done this before?
I can easily understand why you're confused... there are indeed many ways to do this. You even left out Data Binding which provides you with yet another way to populate and decorate the table in question.
To sum up the usage of the different APIs:
SWT provides the basic widgets and controls. Often these have a rather irregular low-level interface - especially compared with Swing - but you need to access the SWT controls to lay them out (an exercise that can be complicated in itself). Also many of the listeners are on the controls.
JFace provides a set of viewers on top of the corresponding structured SWT controls - e.g. TableViewer on top of Table. These viewers provides a high-level interface to the functionality of the underlying control - e.g. with models, label providers, sorting, filtering and more. (The viewers can easily be compared with the Swing counterparts...)
Eclipse Forms provides a (relatively) simple way to create views, dialogs, etc that looks like web pages. Examples of this are the various PDE editors.
Data Binding provides a (somewhat complicated) way to bind controls (including Tables) to a data structure (Bean, EMF or POJO based).
So... you have to decide on whether to use the model facet of JFace and Data Binding, but the rest of the APIs are often combined in the same view or dialog.
NewClassWizardPage and NewTypeWizardPage are both particular complicated examples of wizards - don't base your own work on these!
For your particular case - as I understand it - I would use a simple JFace TableViewer to hold the list of interfaces... (I use a TableViewer rather than a ListViewer as the later cannot have an image as part of the label provider.) The "Add" and "Remove" buttons will manipulate the model of the viewer and then update the viewer. You don't need Eclipse Forms as the wizards usually don't look like web pages. And Data Binding is also an overkill here given the very, very simple data for the wizard.
Please note that the function of a wizard is only performed after all the wizard pages has been shown and the "Finish" button is pressed.
I'm building a Zend-based Web app that will permit third-party extensions.
Essentially, this application's database will have a generic "content store." Extensions are added to render different pieces of content in different ways.
Think of a rich mail store: When the user asks for a "Calendar" item, I instantiate a Calendar class (or something) and ask it to render the item's content. The same database might contain "Mail" items, which are rendered by a different class (or whatever). So I'm basically defining a base class with the needed methods to handle content items, and then add-ins are written which inherit from that to deal with specific item types.
Each of these add-ins may need to access its own View files, since each of them will obviously have a different visual layout.
I can't foresee all the content renderers that might be used; new ones will be "installed" (in some fashion) so that my application knows "when I see content with a database type column of XYZ, I'll call the XYZ thing to render that."
Likely, what will happen is this: User will visit a URL for the application, thus triggering an action within a Controller. That Controller will use a Model method, telling it which specific content item was requested.
From there, either the Model or the Controller (which?) needs to call something (what?) that gets the item from the database (okay, the Model clearly does that) and renders it using some predetermined View. This would be PART of a larger page that might well include several rendered items (as in, a list of content items).
So two questions:
What's the best way to architect this in Zend Framework? I do want these add-ins to inherit from a base renderer class that I provide, because very simple renderers may simply need to call functionality from that base class, rather than having any of their own code (e.g., a "Note" and a "Memo" might well use the simplified rendering functionality from the base renderer class).
What's the best way to "register" these add-ins with my application? An .ini file, perhaps a database table? The goal is simplified installation steps for whoever is operating the application - e.g., editing an .ini file is often easier than manually querying a database, although I could also provide an admin back-end UI for new content renderers to be registered in.
I'd implement the Visitor Pattern for this.
Each third-party extension should implement an interface that you define, so that you know you can call a specific method, say render() on any object that is an instanceof that interface.
Each extension then implements its own rendering. Perhaps it utilizes a View partial in the Zend Framework architecture. Or else perhaps it uses some totally different code to render itself as a PDF or something (maybe each extension needs to be able to override content-type headers?).
As for how to register it, check out the Zend_Application framework for defining resource plugins.