Request clarification on XAML - how to specify/reference source object

Aug 10, 2013 at 2:51 AM
Markus,

I understand the basics of how the model class injects the data into the view class via the FW.

But now I am trying to get some code to work and need to translate the examples to work with a CODE FW form.

In the example, we have the following in the beginning:
<Window x:Class="WPF_MultiColumnCombobox.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="560" Loaded="Window_Loaded" >
    <Window.Resources>
        <Style x:Key="txtStyle" TargetType="{x:Type TextBlock}">
            <Setter Property="TextAlignment" Value="Center"></Setter>
        </Style>

       <Style TargetType="{x:Type ComboBoxItem}">
            <Style.Triggers>
                <DataTrigger Binding="{Binding Path=DeptName}" Value="IT">
                    <Setter Property="Background" Value="White"></Setter>
                </DataTrigger>
             ....
Now most of that can go into a CODE FW form just fine. But I use:
<mvvm:View
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   xmlns:Controls="clr-namespace:CODE.Framework.Wpf.Controls;assembly=CODE.Framework.Wpf"
   xmlns:Layout="clr-namespace:CODE.Framework.Wpf.Layout;assembly=CODE.Framework.Wpf"
   xmlns:mvvm="clr-namespace:CODE.Framework.Wpf.Mvvm;assembly=CODE.Framework.Wpf.Mvvm"
   IconResourceKey="CODE.Framework-Icon-List"
   Title="My EditForm">
In the 1st example, x corresponds to the class that contains the data used by the controls. But since we inject the data, I am not sure what to put to get the code to work without error.

1) What would I use in the 2nd example so that I could reference x?
2) What other information do you think might help when trying to convert a generic WPF example found on the internet so that it can work properly within a standard CODE FW form?

Thanks,

Fletcher
Coordinator
Aug 11, 2013 at 11:30 PM
I am not totally sure what you mean by "x corresponds to the class that contains the data". Are you referring to the x namespace? In that case, x has nothing to do with the code-behind class part. The x namespace is simply used to express things that have special meaning. For instance x:Key just means that there isn't a Key property on the Style object, but instead, this is the key to be used when the style is added to the resources collection.

Anyway, to get to the core of your question: You can still use the same exact resources definitions as you did in the first example. Except instead of saying "Window.Resources" you would say "mvvm:View:Resources". Everything else remains the same.

As far as how the model ends up in the view: The framework simply takes on the task of assigning the model object to the DataContext property of the view so the view can find the model. If you have a code behind file, you do this by saying "this.DataContext = xxx" and if you do not do that, the class itself will act as the default data context and hence the members of the class will be found by default when using binding expressions.

On a side-note: You can still use code-behind files in CODE Framework. I would discourage a direct use of the Window class, because you lose a lot of flexibility. You could use a UserControl with a code behind file though. If you put one of those into the standard view location, it will be used just like a view without code-behind file. In fact, you could create a code behind file even for mvvm:View defined views, not just user controls. You can actually use any WPF object and define a code-behind file for it that way, and CODE Framework fully supports that.

The reason we don't do that as a default is that we feel it leads to dirty code. People tend to put way to much nasty stuff into code behind files and then end up hardcoding things they shouldn't. Rather than using an action that can be bound to anything in a very flexible way, they end up handling specific events instead. That sort of stuff. Not good. And since we follow the design principle of "doing the right thing should be what the tool/environment/framework leads you to do", we make it the default to not have code behind files. And interestingly enough, hardly anyone uses them in our framework and most people don't seem to miss them very much. So I will take that as a victory for good design! :-)


Markus
Aug 12, 2013 at 7:28 PM
Edited Aug 12, 2013 at 7:33 PM
Markus,

I think you read too much into my question.

I am trying to translate some examples I found on the internet so that I can use them in CODE FW. In the sample code, they have a number of things that require code behind, etc. In CODE FW, I just put that code into the model.

I agree with your points. Where I (and possibly others) get confused is translating the example such that I can use it with CODE FW.

So given a simple example on the internet, what would I (in a general sense) need to change to implement it "properly" in a CODE FW based app.

i.e.
  • Change "<Window " directives to "<mvvm:View" directive
  • No need to use "this.DataContext = " since the model is injected into the view.
  • Any code/properties in the referenced DataContext should be put in the model.
  • if the xaml uses something like "Window.Resources" use "mvvm:View:Resources"
  • if a style is defined, leave it in the xaml or put it in a theme in the themes folder
  • if the sample uses code behind, put the code in the model,
  • etc.
The idea is that if I can translate the examples I find fairly easily , I don't have to bug you (or anyone on this forum) as much when I try to get them working. And I am hoping that the list above (based on your response) is a good start

Just a thought,

Fletcher
Coordinator
Aug 13, 2013 at 11:32 AM
The list you have there looks right to me. The most difficult part in that sense is "putting the code behind in the model", because you will find things like direct event hookups that you can't do 1:1 in the model. Instead, you put those things into a command and then use our ability to bind any event to a command. That should do the trick.

Markus
Aug 13, 2013 at 11:20 PM
Markus,
I recall seeing something about doing just that, but not sure where. If you have a chance, can you post a link to it? Or if I find it first, I will do so.
Thanks,
Fletcher
Developer
Aug 14, 2013 at 8:11 PM