Data Context Availability for Columns

[Philipp]

Hi all

I'm currently evaluating the grid for one of our main applications, and hit a few early bumps. Generally, I'm struggling a bit with the avaliability of the DataContext in cells, columns etc.

The Microsoft grid, while being a very nice control IMO is a bit of a letdown here. What I would be expecting from a grid is this:

<telerik:GridViewDataColumn
  DataMemberBinding="{Binding DisplayName}"
  IsVisible="{Binding IsVisible}"
  Header="{Binding HeaderText}"
  My.AttachedProperty="{Binding Foo}"
 />

This feels just natural and enables proper MVVM without any dirty hacks. Much to my delight, I could easily bind the IsVisible property of the column to a boolean property of my view model. When I tried the same thing with the header: fail. I then created a simple template and did the binding and discovered that the data context of my header is not just empty, but actually an instance of system.object. I have no idea what the reason behind this is. I sure didn't set this.

There's a few threads on the issue, in part with workarounds that make me *really* cringe:
http://www.telerik.com/community/forums/wpf/gridview/column-header-binding.aspx

I can't help but wonder why we have a distinction of cases, and why I end up with a random data context for the header  instead of the grid's data context. After all, it just works for other dependency properties and attached properties.

I'm near certain that this will become a problem for us somewhere down the road - because one of our devs wants to set a header dynamically, we do need localization, have custom templating for headers, or another reason I currently don't think about.

What's Telerik's point on this? Is this a know issue that might get fixed? Is it a deliberate choice made for a good reason I don't see? Is it a bug?

Thanks in advance,
Philipp

[Ivan Ivanov]

Hi Philipp,

Thank you for feedback. As RadGridView is meant to be a powerful data visualization and data processing control, the default logic that is follows implies that the main focus will be set on the data itself and headers won't be updated in the utilization process. So that, by setting them a System.Object DataContext, we have provided greater flexibility of their initial value, allowing users to customize them in the way that fit their needs best. However, let me propose you a fully MVVM compliant approach that accomplishes this task. 

Best wishes,
Ivan Ivanov
the Telerik team

[Philipp]

Hi Ivan

Sorry for not getting back to you earlier - we postponed a potential migration due to the issue, and will be looking into it now. First of all thanks for the sample! Unfortunately, your approach may work for this simple sample, but I'm afraid this has no relevance in a real life environment. Our data contexts won't be static resources, and with this, this falls apart with pretty much every real life MVVM scenario (e.g. think a master detail view with the grid showing the details of the currently selected master).

BTW: we currently go the static route through the Freezable trick with Josh Smith's DataContextSpy which allows you to data bind the data context dynamically to a Freezable, and then resolve it that way.
http://blogs.infragistics.com/blogs/josh_smith/archive/2008/06/26/data-binding-the-isvisible-property-of-contextualtabgroup.aspx

However, DataContextSpy is a dirty hack, or in Josh's own words:
http://joshsmithonwpf.wordpress.com/2008/06/26/datacontextspy/

The columns not being bindable is a bug that plagues many users of the built-in data grid and it would be awesome if your grid would fill that gap (there's a lot of discussions on that subject you can find). We would have migrated our whole UI to Telerik months ago if the grid had solved that particular issue :)

<quote>
So that, by setting them a System.Object DataContext, we have provided greater flexibility of their initial value, allowing users to customize them in the way that fit their needs best.
</quote>

I'm still failing to see the benefit of having the control setting the data context to an arbitrary instance of object rather than the *real* data context (I'm not talking about the data type, but the fact that somewher down the road, the grid seems to do something like this:

mycolumn.DataContext = new object();

What kind of flexibility or customization are you refering to? Could you elaborate?

Thanks,
Philipp

[Ivan Ivanov]

Hello Philipp,

I understand your point but implementing this modification will be a breaking change in our code and will affect a lot of our clients. Would you share some more details about your scenario and the exact behavior you are expecting in your project?  Having more information we can think of alternative approaches and provide you with another solution if possible.

Greetings,
Ivan Ivanov
the Telerik team