Binding WPF Page to Csla Object

Binding WPF Page to Csla Object

Old forum URL:

GreggR posted on Wednesday, February 17, 2010

Writting a WPF Browser Application.  Is there an example on how to bind a xaml page to a csla object?  I am guessing I need to use the new Csla.Xaml?  Below is a code snippet from my page.  I am getting an "Unable to load the metadata for assembly 'Csla.Xaml'....  Could not load file or assembly 'Csla.Xaml' Version= .... or one of its dependencies.  Operation is not supported" error.  Along with a "type 'csla.CslaDataProvider' was not found" error, of course.  I am running VS2010 Release Candidate on XP.  Referenced the Csla.Xaml and Csla 4.0 dlls from the Client directory in my WPF project.

My try at binding code:




























<csla:CslaDataProvider x:Key="Facility"




ObjectType="{x:Type PCA:Facility}"



























Peer replied on Wednesday, February 17, 2010

Hi Gregg,

I'm learning Xaml for Silverlight  and Csla myself and I had (still have) a great help by watching the Video serie from Rocky. It explains how to set up a Silverlight project and spread the logic over the different projects. I Spend over 2 months now and stepped in about every pitfall there is, and there are many...

Just keep reading and trying...


P.S.: Maybe it helps when you remove the blank lines in your codesample ;)

ajj3085 replied on Wednesday, February 17, 2010

I don't think he's talking about SL though, its a Xaml Browser Application

RockfordLhotka replied on Wednesday, February 17, 2010

Xaml browser apps are a real pain. It is like Microsoft decided to take the worst of the web and shoehorn it into the (otherwise nice) WPF world.

Most notably, they went to great pains to simulate the Alzheimers suffered by the web in WPF - so it is nearly impossible to maintain any state from page to page. Really amazingly poor if you ask me.

This messes with all sorts of CSLA stuff, because you can't keep any objects alive from page to page.

And they mess with the thread principal, so it is hard (impossible?) to use a custom principal. That's not really a CSLA issue, but it blocks entire classes of application.

When I was writing the 2008 book I was going to use Xaml browser apps as my WPF example - but the entire model was so ill-considered that I abandoned it and never looked back.

Peer replied on Thursday, February 18, 2010

Oops , Sorry . Thanks Andy for the link, wasn't  aware of  that type of applications.


RockfordLhotka replied on Wednesday, February 17, 2010

I guess I could be more constructive...

Binding to a CSLA object in a single Xaml browser app page is the same as binding to an object in a normal WPF form or usercontrol. It all works the same way.Create the object as a resource, or create a viewmodel as a resource or create a data provider as a resource - then bind the UI to that resource.

You just need to be aware that you can't preserve anything from page to page - and I never did figure out how to make the back button actually work - because it navigates back to a previous page - but the underlying objects behind that page are then gone - so binding is all messed up. The lack of navigation events was a serious roadblock - I couldn't figure out how to trigger re-loading of the objects (not that re-loading is ideal, but what else are you going to do?).

GreggR replied on Wednesday, February 17, 2010

Thank you for the reply.  I was able to bind to the object and my data is saving, but I'm still having some trouble implementing the CslaDataProvider (would like to for the error handling if nothing else).

Your first reply raises a bigger question.  What would you recommend for an internet accessible application?  Would I be better off using WPF forms, web services, with a click once deploy?  What about Silverlight?  I am at the beginning stages of this project and want to make sure I'm heading in the right direction.

One more, unrelated question.  We have another project in the works that is using windows forms.  You have hinted that Microsoft is steering away from windows forms.  How concerned should we be about them dropping support in the near future?  Concerned enough to start over with WPF screens instead?

Thanks again for the input.

RockfordLhotka replied on Wednesday, February 17, 2010

I don't know why the data provider wouldn't work. But as I said, I abandoned this UI model in 2007 or so in frustration, so perhaps there are unforeseen issues.

I'd look seriously at Silverlight or ClickOnce as better alternatives. The Seesmic twitter client is a good example of a widely used ClickOnce WPF app. I think Chrome might be too - or at least they emulated the ClickOnce look and feel.

But as I've said in other threads, for my part I default to Silverlight and only fall back to WPF/ClickOnce if necessary.

It is clear that Windows Forms is in maintenance mode. Just look at the new features in .NET 4 - oh wait, there aren't any. Hmm. I guess you see what I mean.

But Microsoft has not announced any end-of-life plans for Windows Forms. And they normally keep things limping along for 10 years after they do announce end-of-life. So it isn't like there's a big rush to move off Windows Forms if you are happy with what it does - because it won't be changing to keep up with the times.

My recommendation is that organizations should be developing migration strategies to shift off Windows Forms over the next 5 years or so. That's a workable time-horizon, because I suspect in the 5 year timeframe it will start to become more difficult to find developers that are willing to work on Windows Forms. By then everyone will clearly understand it is a legacy technology, and a dead-end career-wise; while today that's not yet true.

Copyright (c) Marimer LLC