I'm creating a Silverlight 4 application to manage active directory objects (CRUD Users, groups etc). Now we all know that active directory objects have lots of properties.
I want to save some groups of property names in an SQL DB (ie, samaccountname, mail, etc.) for certain AD object types (users, groups, etc).
When a user in the silverlight app clicks on "create user" I want to
get all the property names I defined in the sql db for the user
create a pre defined silverlight control for each property and add it to the current "create view"
be able to read all the values the user enters in the controls and pass them on
The user controls differ depending on the type of the Active Directory property, i.e. for a property with a datetime value, we will create a user control with a calendar. This way we can keep the "Create" Views dynamic.
The Silverlight / Prism foundation is already there and I'm adding my Views via the RegionManager. It all works just fine but I'm not sure how to add controls in such a dynamic way that it still works with PRISM and the MVVM pattern. Thank you for any input.
I'm going to assume that your comfortable with the getting the properties from the db and saving the values back and focus on the middle area of creating the view with MVVM in mind.
The PRISM part I wouldn't worry about. You say you've got the views registered with the region manager and that's about all you need to do.
My initial thought was how would you "create" controls at runtime with MVVM considered. Creating controls is not the hard part but would require a handle on the element you will be injecting these into, a root grid for example. This would on the surface feel very un-MVVM. Personally I think it's valid to have "view" code done the old fashion way, it's the "data" code used in binding that should be MVVM'd. The issue is telling the code that will inject the controls on to the view what to actually inject. I can't think of a neat way to do this.
As a solution could you not create a view containing all the controls that apply to each of the properties and rather than "create" them when needed "hide" them when not needed? You could bind the "Visibility" property (probably through a value converter) to a property in the ViewModel that can be used to determine if that particular control should be shown or not. If these where placed in a stack panel then the view would dynamically shrink.
If you think a code example would help let me know.
Related
I'm creating an application on which I want different users to use it. I want to insert a variable, only modifiable at development mode. I think maybe there should be a way of using the App.Settings of the WPF Application, but, after one hour googling, I don't have a clear idea yet.
So, I need:
A variable that makes the WPF Application run at administration or client scope
If I have that variable in a specific role, I want to disable some controls
Any idea on where to look for a solution for this?
Well you could add to the base class of your ViewModels a property which contains the value reflecting the mode. As next step you could bind the IsEnabled property of the controls, which shall have this behavior, on this property of their related ViewModel.
Since you don't want to provide different modes with different states a.s.o., this seems to be the best approach.
VS 2010, Windows 7: Windows Forms - I have a number of forms that contain user controls that reference domain model objects. Some of the controls reference single objects and some reference collections of domain model objects. When I open the project or individual forms, the IDE will check out the forms and add dummy domain model objects. In some cases, this has no serious side effects and in others this result in the app crashing. Why is this happening and how do I prevent this from happening in the future? I would like to get to the point where the designer doesn't add anything extraneous - I can crash the system on my thank you very much. Thanks.
The designer will create a default instance for each public property contained in child user-controls in the current control it is displaying. This can be changed using the DesignerSerializationVisibilityAttribute setting the visibility to DesignerSerializationVisibility.Hidden.
This tells the designer to leave those properties alone.
You will likely have to go through the designer file itself and remove the old allocations and assignments for the properties you marked.
I'm using WPF with the WAF framework.
I have a piece of UI (let's say it collects the user credentials) that gets presented on multiple views (see image).
I figured, hey, this is reusable, let's put it in its own user control.
I can get everything working fine if I ignore the inner user control and just "flatten" it if you will, but trying to encapsulate it is making me wonder what the best approach is. Should this "credentials" user control have its own dedicated view model? Should it be exposing its data through dependency properties instead? What's the best approach?
I will need to expose the data collected from the credentials control to the view model of the outer user control.
Should this "credentials" user control have its own dedicated view model? Should it be exposing its data through dependency properties instead? What's the best approach?
A UserControl can serve two purposes -
If you want to use it as a "Control" - which is often the case in a situation like this, I would treat it as 100% view. As such, I would not make the UserControl have a ViewModel at all (at least not publically), and expose it's properties via Dependency Properties. This provides the most flexibility in terms of reuse, as the UserControl acts like any other FrameworkElement, and can be dropped in and bound to your own properties in your other location like any other control.
When a UserControl acts as a View for a ViewModel, however, things are different. Here, the goal isn't reuse, but separation of concerns between your View and VM.
This situation sounds more like the first - you want to have a control that can be reused in multiple locations. In this case, this basically becomes a view element.
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