Click here to Skip to main content
15,889,834 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
See more: , +
I have a converter in my Xaml that pays attention to both a security option embedded as a parameter in the converter call in Xaml and a binding to a visiblilty property on my viewmodel class. I can make the tab and the control in the tab visibility=collapsed based on this, but if I do it programatically and am on the tab that is to be hidden, I get just a collapsed tab window and the tab header is removed. I can then click on other tabs and get to them properly, but is there a way to cause the current tab to be changed automatically to the next or prior tab in the collection when its visibility is changed to collapsed?
We are trying not to use codebehind, as we are injecting all our views and want to be able to override the xaml if needed. We are also going to the Prism framework.
Now it is not a simple case of programatically deciding the next item in an array of tabs using different views/viewmodels (in this case, the tabs are all dealing with the same base item, just different details that are all part of the primary class), as the security option is invoked from the Xaml side of things and may have taken the tab out of the display and the viewmodel will not know that.
Brian
Posted

1 solution

As I’m not privy to your code – I can only speculate. How about a visible tabs collection or visible tab index property in your view model? A bit of modulus trickery could cause this to automagically wrap around to the first visible tab when passing the end of the collection - well it's just a thought :)

Regards
Espen Harlinn
 
Share this answer
 
Comments
Brian Risley 16-Feb-11 16:34pm    
Problem is Viewmodel will not know what the security control handled by converter in Xaml has done.
I need either some sort of Xaml based trigger or an extension to the tabitem class that can detect the change and pass the tabcontrol and the current tab in to some processing logic that can output the destination tab and have it switched there. The security uses a lookup based on the current user to see if they have the proper right to a given key.

Brian
Espen Harlinn 16-Feb-11 17:29pm    
One of the wonders of the view-model in M-V-VM is that there is no exact definition of what it is or what it’s supposed to do – personally I tend to think of the VM as just that: a view model – something that exists purely for the purpose of the view, containing both elements that have no purpose beyond the view; and entities or facades for entities from the application data model.
I get the feeling that your definition of View Model is somewhat more focused on the model than the view – at least compared to how I tend to look at things, but then there are no hard rules in this area.
If I was defining the entity model for your solution, elements that the user should not have access to would not surface beyond this boundary – as it’s often likely that this forms a natural boundary in a multi-tier architecture.
The notion that security control is handled by converter seems somewhat foreign, but it would be interesting to know how it works out – I’m not saying that I think you are going about this the wrong way, just that you are obviously using an approach that’s quite different from how I would go about designing an architecture. Good luck – if it works out, you could always consider writing an article here on CP sharing your experiences, I have to admit that I’m a bit curious about how you are putting things together.
Brian Risley 16-Feb-11 17:39pm    
Our plan is to support the security to a certain extent in the xaml, as we have varying site security needs. We will have standard Xaml, but will have an option to load the Xaml from the database if an override is present. If a site wants to specifically control fields that appear in the Xaml, they will be able to do so. They may also add their own security flags which our logic will not have to know about. Certain tasks and some data may be restricted in the viewmodel by similar flags. Some of these controls aren't just for security information, we have customers who don't use some of our properties and don't want to see them. This way they can set a flag at the highest level in the Xaml override, and not see them or they can even redo the Xaml and remove them. We have no Single customer to design our views for, we have certain ideas and patterns, but the individual customer has the ability to control the fields. With this approach, we don't have to build the Xaml from scratch, just modify an existing template/base style. Our code won't be changed because one customer has to have field x removed or moved on a view.
Brian
Espen Harlinn 16-Feb-11 17:52pm    
Sounds interesting - have you looked at http://www.devexpress.com/Products/NET/Controls/WPF/Layout/layout_control.xml

supports layout persistence via XML, and allows users to redefine their own UI - could quite possibly be used to further your customizable design. As I mentioned, an article would be interesting - I'm not pulling your leg :)
Sandeep Mewara 17-Feb-11 0:48am    
Good answer and discussion. My 5!

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900