is "non-intrusive code-behind" a good or bad practice? - xaml

I am a bit surprised that while learning WPF/XAML/Silverlight almost all of the XAML/C# examples I have encountered have the "Click" events in the XAML and very few in the Window or Page constructor.
With all the emphasis these days on "non-intrusive Javascript", I would think that more developers would actually be structuring their XAML/code-behind like this:
XAML:
<Grid>
<Button x:Name="btnEdit"/>
</Grid>
Code behind:
public Window1()
{
InitializeComponent();
btnEdit.Content = "Edit";
btnEdit.Click += new RoutedEventHandler(btnEdit_Click);
}
private void btnEdit_Click(object sender, RoutedEventArgs e)
{
btnEdit.Content = "This button was clicked.";
}
Any thoughts on why this would be a good or bad practice?

Most of the smaller WPF examples give just an impression what is possible without focusing on design issues or good style.
In real world applications XAML should only be used for declarative programming. For example, binding a command to a button or declaring a data binding. Karl Shifflett has some great articles about the MVVM pattern which separates the concerns of your WPF/Silverlight application very well.
Code behind is in my opinion just suitable for tiny applications. It tends to mix view, control and data.

If I remember correctly, I think that there is a partial class which implements the Init code above that is code gened by visual studio. I can’t speak for WPF, but it does this in ASP.Net 2.0, so I’m assuming that it does it the same here. It took me forever to get used to this.
I agree. I hate defining events in the markup.

I agree with your concern.
After much debate, we are following a similar pattern of non-intrusive, ultra-lean XAML and binding commands and data in code-behind.
If you add events in the XAML there is a contextual menu navigation to the event code. If you bind commands in XAML there is no equivalent. You can navigate from the command declaration in the XAML but not where it is assigned to the Command property on a control.

MVVM is bad practice.
You think that you separate Data and View. And what? Total mechanism with XAML binding, binding commands, translating it to methods and implementing INotifyPropertyChanged for what? For UTests (I made - I test conception he-he)? Right software need in only in user's test... It's your code separated in such way in which you sometimes do not understand where is what.
For what you use INotify? For what Microsoft ALL WPF controls and entities as whole in WPF wrote inherited from FrameworkElement with magic DependencyProperties?
Multiple binding is hard resource technique by the word (read authors of MVVM).
I wrote high complicated 3D CAE system without any Patterns less than year...
with classic organization of app with classes and code-behind.
https://skydrive.live.com/?cid=ea6ad1087e3103f0&sc=photos&id=EA6AD1087E3103F0!103&sff=1#cid=EA6AD1087E3103F0&id=EA6AD1087E3103F0!118&sc=photos
All the samples in MVVM are about Customers in Company...
I offer put the name MVVMCC pattern (Customer in Company)

Related

How to bind an event to a command in a Universal App using the MVVM pattern?

I hope somebody can help.
I've spent some time researching the best way to bind an event to a ViewModel command using the MVVM pattern when developing a Universal App. I'm using MVVM Light.
As a test I'm using the SelectionChanged event of a ComboBox.
I've read a few people that have pinched the Behaviours SDK from the Windows 8.1 / WinRT framework and had some success with that. I have also included the Universal App behaviours SDK in my project and tried the following (put together from Windows 8.1 examples but using the UWP SDK).
XAML
<Page
xmlns:interactivity="using:Microsoft.Xaml.Interactivity"
xmlns:core="using:Microsoft.Xaml.Interactions.Core" />
...
<ComboBox ItemsSource="{Binding InputQuantities}">
<interactivity:Interaction.Behaviors>
<core:EventTriggerBehavior EventName="SelectionChanged">
<core:InvokeCommandAction Command="{Binding SomeComboBoxCommand}" CommandParameter="Foo" />
</core:EventTriggerBehavior>
</interactivity:Interaction.Behaviors>
</ComboBox>
View Model
public RelayCommand SomeComboBoxCommand {get; set;}
However, the core:InvokeCommandAction isnt part of the Behaviours SDK and i get Invalid Type: expected type is 'Microsoft.Xaml.Interactivity.ActionCollection'. I've tried to use an ActionCollection.... but I'm not sure I know what I'm doing with that.
Ive successfully got it to work with compiled bindings and using Laurent's Blog Post:
XAML
<ComboBox ItemsSource="{Binding InputQuantities}" SelectionChanged="{x:Bind Vm.SomeComboBoxCommand }" />
View Model
public void SomeComboBoxCommand(object sender, SelectionChangedEventArgs e){//do stuff}
I know this isnt what Laurent is intending to demonstrate here and I think doing this is breaking the decoupling of the view and VM by then having to reference a UI component in my view model to get the selected item. But I've seen references to doing this during my research.
So how can I get this working using The Universal App interaction behaviours, if that's the right way to do it of course?
Update 1.
This is what I attempted to add, believing, incorrectly that I was adding the universal app behaviours SDK. I didn't notice at the time that it was targeting Windows 8.1.
However, my questions still stands: Why wont the InvokeActioncommandwork and why is it throwing the mentioned error? I will look at the other posts as soon as I get to work.
Update 2
After testing this on my works PC (exact same code as above, 1st example and the same behaviours SDK) it works fine and I'm getting the behaviour that I would expect. I need to test again on my home PC to see what has gone wrong. (Thanks to Justin XL for sticking with me)
Update 3
For completeness, after returning home I got the latest version of my project (from being checked in on my works PC) and it now also works on my home PC. I'm not sure what state my Visual Studio was in but it had sufficiently confused me enough to post this question. At least this should serve as a document on how to do what is described in the title. Thanks for all your help.
We seem to be getting this question a lot lately, in several different variants...
I'm not familiar with Universal App but is there any specific reason you're trying to use an event? WPF/Silverlight etc are designed to be data driven, all you need to do is bind the ComboBox's SelectedItem member to a property in your view model and the setter will get called whenever the user selects a new item. Often times you have to do exactly the same processing in response to other parts of your view model changing it (e.g. in Master-Child views) so having that logic in a single place generally makes for a much cleaner architecture.
Check this link: MVVM EventBinding Library ,explains about MVVM EventBinding. This purely decouples the View & View model & pass only the arguements to the command.

Source code for WinRT UI controls publicly available?

Is the source for Windows Store (WinRT) UI controls publicly available? We would like to extend some of the controls and not have to start completely from scratch, like we can for SL and WPF. Googling and looking through SO doesn't turn up anything for Windows 8.
Thanks!
So unlike WPF, [WinRT-XAML] controls are written in C++/CX.
But, it sounds not so much like you want the source code as much as you want to derive from existing controls and extend or override their functionality. You know you can do this, right? It's easy enough and sounds like you will get the results you are asking in your question.
Something like this:
public class MonkeyTextBox : TextBox
{
public new string Text
{
get
{
return "Always Monkeys!";
}
set { /* do nothing */ }
}
}
This is my custom TextBox wherein I have replaced the base implementation of Text with my own. Granted, I hope your custom controls are better. Anyway, you can do this with almost every control, and you can add your own properties and events. Make sense?
Reference: http://blog.jerrynixon.com/2013/01/walkthrough-custom-control-in-xaml-isnt.html
But to answer your question: no, we have not released the source (yet). Hopefully, that will save you the time looking for it. Maybe someday we will - maybe.
Best of luck!

EventToCommand binding with parameters in portable view models

I am implementing a view model that is shared by applications on multiple platforms. I am using MvvmCross v3 that has its own MvxEventToCommand class, but I believe the challenge is the same for other frameworks like MVVM Light. As long as the event is used without parameters, the implementation is straightworward, and this is the case for simple interactions like tapping the control.
But when the command needs to handle event arguments things become more complicated. For example, the view model needs to act on certain scroll bar changes (and load more items in the associated list view). Here is the example of XAML:
<cmd:EventToCommand
Command="{Binding ScrollChanged}"
CommandParameter="{Binding EventArgs}" />
(MvvmCross uses MvxEventToCommand, but the principle is the same).
Then in my model I can have the following command handler:
public ICommand ScrollChanged
{
get
{
return new RelayCommand<ScrollChangedEventArgs>(e =>
{
MessageBox.Show("Change!");
});
}
}
(MvxCommand in MvvmCross).
The problem is that ScrollChangedEventArgs is platform specific and this code simply will not compile in a portable class library. This is a general problem with any command that needs not only a push when an event was fired but requires more specific event details. Moving this code in platform-specific part is silly because it more or less kills the concept of portable view models and code-behind-free views. I tried to search for projects that share view models between different platforms, but they all use simple events like "Tap" with no attached event details.
UPDATE 1 I agree with Stuart's remark that view models should only deal with higher level abstractions, so I will rephrase the original concern: how to map results of low-level interactions to a platform-neutral event that triggers a business logic command? Consider the example above: the business logic command is "load more items in a list", i.e. we deal with a list virtualization where a limited number of items from a large collection are loaded initially, and scrolling down to a bottom of a list should cause additional items to be loaded.
WinRT can take care of list virtualization by using observable collections that support ISupportIncrementalLoading interface. The runtime detects this capability and automatically requests extra items from a respective service when the user scrolls down the list. On other platforms this feature should be implemented manually and I can't find any other way than reacting on ScrollViewer ScrollChanged event. I can see then two further options:
Place OnScrollChanged handler in a code-behind file and call the portable view model higher level event (such as "OnItemsRequested");
Avoid code-behind stuff and struggle to wire the ScrollChanged event directly to a view model, then we will need to remap the platform-specific event first.
As long as there is no support for second option, putting event handler in code-behind file is OK as long as it is done for the sole purpose of event mapping. But I would like to investigate what can be done using the second option. MvvmCross has MapCommandParameter class which seems to be able to help, so I wonder if I should exploit that one.
UPDATE 2 I tried MapCommandParameter approach, and it worked allowing me to insert a platform-specific adapter that would map low-level events to view model-specific commands. So the second option worked without any struggle. Stuart also suggested listview-subclassing so there is no need to care about scrolling events. I plan to play with it later.
I agree that viewmodel commands should normally be expressed in terms of viewmodel concepts - so it would be 'strange' to send the viewmodel a command about the scrollbar value changing, but it might be ok to send the viewmodel a command about the user selecting certain list elements to be visible (which she does via scrolling)
One example where I've done this type of thing previously is in list selection.
I originally did this across multiple platforms using a cross-platform eventargs object -
https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross/Commands/MvxSimpleSelectionChangedEventArgs.cs
this was then used on WindowsPhone (for example) via an EventToCommand class like https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/Cirrious.MvvmCross.WindowsPhone/Commands/MvxSelectionChangedEventToCommand.cs
However... I have to admit that this code hasn't been used much... For list selection we have instead mainly used selecteditem binding, and there simply haven't been any apps that have needed more complex parameterized commands (so far) - you might even need to go back to very old v1 mvvmcross code to find any samples that use it.

Page Navigation in Windows 8 XAML (without using code behind)

For my windows 8 application i am trying to navigate between pages with out using code behind.
For example, i have one image in my UI without creating tapped event for that image i need to navigate to another page,
<Image Source="ms-appx:///Assets/Logo.png" Width="155" Height="110" Tapped="{ // Navigation method here }"/>
Is it possible to navigate between pages like this...? If possible, how can i get this to work??
XAML is just a declarative language without action part so code behind is an essential part of it.
All interactions work via events and event can be handled in a code behind only. So what you want is not possible with XAML(at least with WinRT XAML).
If you are asking if you can specify the code inside the .xaml file, then no, that is not possible.
If you are asking if you can avoid adding code to the .xaml.cs file, then yes, that is possible. You will still need to specify a method but it can even be done as a simple lambda. You will need to use the Command hooks rather than the Event Hooks, e.g.
<Button Command="{Binding GoConnectionCommand}" ... />
The code for this command is usually defined in the ViewModel as part of the MVVM pattern, and Josh Smith explains it far better than I will.
AlSki mentioned using a ViewModel. Although technically the ViewModel is not part of the "code behind" for the XAML file, it's still code and I believe you were asking for a no code solution.
ixSci is correct that there is no way to do this out of the box without code behind in WinRT XAML.
In full WPF it's possible to do this using a behavior called NavigateToScreenAction. You can read about it here. Unfortunately behaviors don't ship out of the box with WinRT, but they can be added back in by an open source project called WinRtBehaviors.
There is no NavigateToScreenAction behavior for WinRT, but one could be created. There is a good article on creating behaviors with the library here. It will obviously require code to create the behavior, but after it's created you could use it in XAML without any code.
Really, the short answer is it's not possible to navigate without code on WinRT.
Dev support, design support and more awesome goodness on the way: http://bit.ly/winappsupport

Metro equivalent for HeaderedItemsControl

Converting a WPF application from .Net 4.0 to Metro.
It uses HeaderedItemsControl in various places.
I have not been able to find that control or a replacement candidate in Metro (Windows.UI.Xaml namespace)
So what is the recommended control in Metro to provide the functionality of HeaderedItemsControl?
You could easily create one by deriving from ItemsControl and adding a few simple dependency properties. You can see which properties are present in the WPF version here. You might not need all of them, but from a quick glance I can see a Header property which is just an object type. You would put a ContentPresenter in your HeaderedItemsControl's ControlTemplate and bind its Content to the HeaderProperty using TemplateBinding. Then bind the HeaderTemplate to the ContentTemplate of the ContentPresenter, etc.
Not sure how useful it is though to port WPF XAML code directly to WinRT. You're just asking for trouble in terms of code compatibility, but also porting a likely desktop-designed UI to a more touch-centric world.