CSLA for Silverlight - what's wrong with this code?

James Thomas posted on Wednesday, January 28, 2009

Hi All,

After getting databinding working nicely, I'm learning manipulation of objects in Silverlight now. I've written the following code where ProjectStaffList is an EditableRootListBase. It works fine, but seems much simpler than some of the examples I see. Is there something intrinsically wrong with it?

Thanks, James.


public void LoadProjectStaffData()
        {
            ProjectStaffList.GetProjectStaffList(ProjectStaffListLoaded);
        }


void ProjectStaffListLoaded(object sender, Csla.DataPortalResult<ProjectStaffList> e)
        {
            foreach (ProjectStaff ps in (e.Object as ProjectStaffList))
            {
                string test = ps.ProjectStaffName;
                etc...
            }
        }

James Thomas replied on Friday, January 30, 2009

Any chance someone knowledgeable could take a quick look? I'm not sure it's quite right - nor how I can get 'busy' animations integrated.

tia, james.

sergeyb replied on Friday, January 30, 2009

James Thomas replied on Saturday, January 31, 2009

Thanks for your help Sergey. I can see that DataProviders are the way to go for most purposes - it's just that now and again I think I'll need to hand code behaviours. Good to know that I'm not doing anything disastrous in my code.

RockfordLhotka replied on Saturday, January 31, 2009

btw, there's nothing wrong with your code James. It is totally acceptible to have the UI interact directly with the factory methods, providing a callback or event handler to process the result.

For that matter, you can skip the factory methods entirely and have the UI interact with the data portal - though personally I think that's less than ideal because you lose a level of abstraction.

Sergey is right though, in that we worked very hard to make the CslaDataProvider the simplest model. Not that we're attached to the data provider necessarily, but I think it is absolutely the case that in a XAML-based world you want to have as little code-behind as possible. Ideally that means writing NO code-behind at all, and that's certainly what I'm driving for.

There are two main areas left to address: authorization and exception handling.

I think a Csla.Silverlight.ExceptionDialog control can solve the exception issue. Such a control could be a resource on the page, and the data provider's DataChanged event could route to it. The result would be a messagebox (or something) on any data provider exception - all without code-behind.

Authorization is harder, because neither .NET nor Silverlight have a standard notification scheme to tell your code when the current principal has changed. And that's the primary trigger for re-running authorization logic.

But at least within the confines of Csla.ApplicationContext.User I can solve that problem and provide the notification, so there's some hope. That'd eliminate the need to have any code-behind to deal with most authorization scenarios as well.

In the end, I really think the goal must be to have zero* lines of C#/VB in any XAML UI - just XAML binding to objects and that's it.

* other than "scripting" style UI code - the kind of thing a designer might write behind some XAML to do animations or other UI-ish stuff; and even that is mostly a XAML thing now, so there should be very little of that either

 

James Thomas replied on Friday, February 06, 2009

Hi Rocky,

Thanks for your reply. In the end I changed my code back to using the CslaDataProviderand standard databinding. I am finding that I'm needing to use C# code to make up for a lack of functionality in some of the UI objects I'm using (e.g. I want to change the colour of cells in a datagrid depending on their value, but DataGridTextColumn doesn't allow me to bind a ValueConverter to its CellStyle - so I'm having to do this manually), but basically sticking to the principle of aiming for zero C# code looks to be a good one.

Many thanks for a great set of objects!

Cheers, James.