Does Prism have built-in support for having "groups" of views? If so, how is it done? What I'd like to do is have one regin, call it WizardRegion, where I can have different types of wizards load into that region. Let's assume I have two different wizards: signup and dowork. And each wizard has four pages or views. If I do the normal RegisterViewWithRegion() for each view then all eight views will be visible all the time. When I switch to the signup wizard I want the four views for signup to show. When I switch to the dowork wizard I want the four views for dowork to show.
Do I have to write my own view manager (or extensions) to do this work? Am I completely thinking about it incorrectly? Note that I do not want to have a SignupRegion and a DoWorkRegion.
Yes, you have to come up with some sort of view manager on your own. I believe there are some frameworks out there with this sort of functionality.
Using Prism alone you could use the event aggregator service to send messages to make views visible/collapsed.
If you are doing MVVM you could also bind the visibility of those views to a service/controller class where those properties are set.
You can also use a combination of the two.
Related
I work on site admin application and use marionette. And my problem is - how to organize views and applications for next requirements. Thanks for any help!
There are main menu on header - Users management, Evenets, General settings
And when user clicked to Users management On main region must shows additional menu with
Users Groups Permissions items and by default list of users (first tab is active).
Each item on click should shows coresponding view with list of entities.
And my question is how to organize applications, views and interaction between them?
Is sub menu part of users list view or it independent view? Which type of marionette view it must be?
Sounds a lot like typical web page where it would be much easier to just render HTML on the backend and not build a web-application.
As for structure, there is no one correct way, but I found these couple example projects as decent start to evaluate the best structure:
https://github.com/derickbailey/bbclonemail
https://github.com/Foxandxss/bbclonemail
https://github.com/brian-mann/sc02-loading-views
They all use slightly different structure and coupling. You have to decide yourself which one is best suited for your case.
In your case I guess main application with main region where you show different sub-applications based on user selection (tabs). For specific interaction patterns look at the examples. Try to decouple everything, don't pass around references instead emit and listen to events.
I've built and work with couple bigger web applications and I recommend to no go that path unless there is a reason to do that. Admin interface sounds like something you can "quickly" setup using existing frameworks like django-admin, flask-admin, Rails scaffolding, express-admin, well you get the idea. Then again I don't know anything about the project.
I have a MVVM/WPF based application that can have multiple workspaces (basically containing a TreeView) open at the same time that display and operate on the same data tree. I need to be able to expand and collapse and select the items in each workspace independently and I want to be able to drag and drop items between the two workspaces (e.g. for moving or duplicating items). I also need data virtualization in that the data is only loaded (in both views) when a tree item is expanded for the first time. There is also one workspace-wide details view that shows the details of the selected item of the workspace that currently has the focus. Workspace specific expansion and selection of items must also work programatically.
Could you layout a ruff design for a MVVM based application that embraces theses features? Should I create a separate ViewModel tree for each workspace and implement a Model-ViewModel mapper? Or should I have just one ViewModel tree with two Views? How does the details view know what is currently selected and what workspace has the focus? ...
So to rephrase my question: The Model instances displayed in each View are actually the same instances. But should the ViewModels be the same too? Or better: Could I possibly get away with that?
Also: Is there an open source application I could study that has most of these features? Could Prism or any other MVVM based framework do most of that work for me?
There is a direct correlation between View and ViewModel. The View shows a visual representation of the Model, hosted and "formatted" by the ViewModel.
Since you will have different Model (data) on each View, you need to have several instances of your ViewModel hosting each set of different data.
Now the question is: do your ViewModels share some entities or objects between them ?
If yes, could they change during your application lifetime, and do you want to see these changes in realtime in your TreeViews ?
You then have two options:
Directly bind the model to the View (if the model implements INotifyPropertyChanged) by exposing it through your ViewModel: then all your views will be automatically updated when a model property changes.
Create a component which supervises Model modifications and notify ViewModel exposing them.
The second solution is more pure than the first one because Models should be POCO and shouldn't implement some plumbing oriented-interface. ViewModel should handle the plumbing.
However it's more complicated to design, and 90% of the time, you will end-up saying "come on, just one little interface doesn't hurt" :)
For your details view. You can communicate between your TreeViewModel and your DetailViewModel using a mediator (Messenger in the MVVM Light Toolkit), which is basically a low-coupled event-oriented component. Or use a supervisor which is injected in all your ViewModel and notify them using events.
Speaking of MVVM framework, and for common architecture like the one you are describing, I would recommend the MVVM Light Toolkit.
Maybe I am missing something, but is it not possible to have 2 instances of the same View / ViewModel loaded with different data?
Imagine you have a complex data object. It was complex enough that to edit the various properties of the object, it would be best for the user to have multiple screens. It's essentially a shopping cart for configured items.
So one screen would allow you to add items.
Another would allow you add modifications to those items, predetermined changes that have a cost associated.
A third screen would allow you to configure global settings for your items.
As I'm sure you can guess, each screen is operating on the exact same cart, just altering different properties and relationships of the items inside.
So, we're going to try to write the application using MVVM, and while discussing the various screens (as well as navigation between them) we arrived at the following question:
How do people generally manage application state when using MVVM? The navigation bar that the users will use to change screens will exist outside of the screen, but when a user clicks it, what common ways have people been using to hide one and show another?
More generally, how are people handling global application state? The user can only operate on one cart at a time, there can only be one user logged in at a time, only one screen can be shown at a time. Would it be best to create a singleton that stored these important properties and the ViewModels could keep a copy of them and subscribe to changes via an event aggregator?
As you can tell, I barely even know where to start with this problem, so any advice at all is welcomed and appeciated.
I would use ViewModels to track the application state.
One ViewModel controls the entire application, and it handles what page the user is currently on. The application itself is bound to the main ViewModel, and the majority of the application screen space is a ContentControl that is bound to ViewModel.CurrentPage. DataTemplates are then used to determine which View to display for whatever page the user is currently on
In the past I've used a global singleton for some objects (such as current user) and the ViewModels use a reference to this if needed. So if I wanted to display the UserName on a page, I'd have a property in the ViewModel called UserName and it returns Global.Instance.CurrentUser.UserName
For your type of situation I would look into PRISM. PRISM is a collection of patterns for developing WPF applications in a loosely coupled MVVM manner.
Specifically, for your example of the multiple screens and managing application state, using a "Controller" to load the views for the various representations of your ViewModel (the cart) into separate "Regions" would probably be a good start. There looks to be a great article on MSDN about getting started with PRISM, including composing user interfaces (Regions).
I am writing my first wpf application now .
I want to use a NavigationWindow on each page the user make selections and all the data should be available on the next pages, I have about 6 page.
How I should path all the data ? via the constructor ? or there is some smarter way in WPF .
On the last page there will be a lot data to path from the previous pages.
I would attack this from one of two ways: The Code-behind way (Easy, but difficult to expand, also will get very messy), and the MVVM way (Takes some learning, separates concerns, easy to extend, manage).
In the code-behind way, I would just have a Tab control with the tab headers styled the way you want them (you can style them to look like just about anything you want). In the code-behind you could have some logic that specifies that X Tab is not enabled or Visible until Y criteria are met.
There is a better way, but it comes with a bit of a learning curve, the MVVM design pattern. You would have 6 Page objects that are really just CLR objects that define the contents of the page (e.g. if it is a questionnaire your page objects would contain question objects and title objects for instance).
You could have a couple of Views, a navigation View, and a page view. The NavigationView would be bound to a NavigationViewModel which would have the logic necessary to change the page. The PageView would be bound to one of 6 PageViewModels and the PageViews DataContext (which provides that binding) could be changed based on the NavigationViews logic.
Learning Prism composite application guidance for WPF Silverlight MVVM Fundamentals
MSDN Page for MVVM explanation
Night Walker,
It is difficult to make out exactly what you want to do from your explanation. First, the NavigationWindow is the frame of your application, I think you know this but I just wanted to make sure we understood that we're not creating new instances of the NavigationWindow. I think you mean 'Pages'. Pages are the content of a Navigation window and represent some target that you want to appear in the ContentPresenter that is provided by the NavigationWindow.
I'm again not sure how you are using the phrase 'Path the data'. Typically you would create Pages either directly in the project or in satellite projects and then reference them using Pack URIs. An example of how Pack URIs are constructed can be found here.
http://msdn.microsoft.com/en-us/library/aa970069(v=vs.85).aspx
You can then navigate to the pack URLs using an expression that looks like:
this.Navigate(new Uri("pack://application:,,,/MyAssembly;component/MyPage.xaml", UriKind.Absolute);
If you don't want to get involved with all the nuts-and-bolts of the framework for navigation and just want to focus on the application for your users, you can check out the professional version of the NavigationControl that I put together:
http://www.teraque.com/products/explorer-chrome-suite/
There's an free demo you can download. If this is was you are looking to do I can give you pointers if you don't want to purchase the package directly.
Sincerely,
Donald Roy Airey
donald.roy.airey#teraque.com
I have an App which has a Tasks tab and a Projects tab. I decided to make a separate ViewModel for each of the tabs, TasksViewModel and ProjectsViewModel.
The Tasks tab has a new task area with an associated project pulldown and the Projects tab (obviously) has a list of projects.
What I'd like is for the pulldown on the Tasks tab to share the same collection as the Projects tab list so that any time I add or remove a project on the Projects tab the list on the Tasks tab is up to date automatically. This worked well with a single ViewModel but it was beginning to become quite unruly.
Should I not have split into two ViewModels? Is there a common method of sharing data like this? Perhaps pass the same ObservableCollection<Project> into each of the ViewModels? Perhaps some type of notification back to the TasksViewModel along the lines of ICollectionChanged.
Appreciate any insight/input!
The easiest solution here is often to use some form of Messaging Service to pass information between the two ViewModels.
For example, the MVVM Light Toolkit provides an IMessenger interface for situations like this.
Using a good IoC or DI toolset can help in this situation, as well. That would let you inject the project collection dynamically into both of your ViewModels, allowing a shared collection to be used in both Views.
It seems to me that your concepts of "Tasks" and "Projects" are part of your model, not part of your view model.
Consider this conceptual exercise: Suppose your app was written so that two users could use your application on two separate machines against a shared database, and one user adds a Project:
Would it be a good or a bad thing if the Project immediately showed up in the dropdown on the Tasks tab of the other user's screen?
Would it be a good or a bad thing if the Project showed up in that dropdown after the first user hit "Save" or "Commit" or "Ok"?
If the answer to either of these questions is "a good thing", your data is really part of your model not your view model. And it should be handled as such.
Your view model should incorporate your actual model by reference, and it is a good thing to share the model objects between view models as much as possible. In fact, ideally most of your application has a single set of model objects. The exception might be a dialog box where you want to be able to make some changes but then hit "Cancel" and not save them. In that case, the "Ok" button would copy data from the model maintained by your dialog box into the main application model. In this case the model objects used by the dialog and by the main application are different instances of the same class.
Now let's consider the case where you answered "a bad thing" to both of these questions. This would be an application where you never save your "Projects" list back to the main database/document/whatever, but it is a transient list used only for temporary work. In that case it would really be a view model, and I would attach it to the application (or whatever scope was appropriate) and have the two tabs access it.