My Gotchas so far in CSLA Light (Silverlight)

Jack posted on Thursday, January 29, 2009

So as I finally got my first CSLA use case almost working as expected I starting porting it to CSLA Light so that I can do the UI in Silverlight.  I thought I had done a good job of perusing the forums but maybe a FAQ or a document on things to watch out for would be useful.

So far there have been a few surprises :-).  I do want to retain as a much as possible as I will need to have a WPF/Winforms version of some of the application.

Anyhow so far CodeGen is making a very big a positive difference as I essentially find/replace.  My thoughts:

1)I was wondering if it was possible to add some of the attributes into CSLA light but not have them do anything (maybe a compiler warning?).  I had used the [Indexable] and now my code is littered with #if !SILVERLIGHT [Indexable] #endif

1a) Also turns out DataObjectField is no longer available [System.ComponentModel.DataObjectField(true, false)] - now that is not CSLA but also a gotcha - more #if !SILVERLIGHT

2) The compiler directives are a bit funny and misleading from one of the blogs I read.  In the blog the directive was in lowercase and depending if you are in the silverlight assembly or your .net assembly then it appears as if it works.

#if Silverlight ... #end appears to works fine when not in Silverlight but isn't really.

#if !Silverlight #end if does not work however #if Silverlight else xxx # appears as if it does work until you jump back to Silverlight and try to compile.

#if SILVERLIGHT #end if works fine
#if !SILVERLIGHT #end if works fine

Bottom line - use UPPERCASE (which is annoying if you dislike ALL UPPER).

3) The #if SILVERLIGHT directives do not play well with #region & #endregion.  I basically had to put the #if SILVERLIGHT wrappers inside my regions. Which is annoying when you have nested regions.
 
4) LinqBindingList - I started using this a fair amount to create filtered collections to bind on - I need to change this to ObservableCollection where I'm using it as a dataBinding source.  I was passing them around for updates so I'm not sure how best to do that.  I'm stuck at the moment as my LINQ queries are returning LinqBindingList and that doesn't cast to ObservableCollection so I need to figure that out... which means - what is the role then of LinqBindingList if I want to share assemblies?  The only benefit I see now is the indexing if I do large data processing on the server?  How am I going to do filtering now on my bindable collection in Silverlight?  Do I do it now at the UI level in the grid?

Just some thoughts

jack

RockfordLhotka replied on Thursday, January 29, 2009

Jack:

1)I was wondering if it was possible to add some of the attributes into CSLA light but not have them do anything (maybe a compiler warning?).  I had used the [Indexable] and now my code is littered with #if !SILVERLIGHT [Indexable] #endif

That is an oversight on our part, and I'll make sure this is fixed in 3.6.1. The attribute won't do anything, but at least it will be there so it does no harm.

Jack:

4) LinqBindingList - I started using this a fair amount to create filtered collections to bind on - I need to change this to ObservableCollection where I'm using it as a dataBinding source.  I was passing them around for updates so I'm not sure how best to do that.  I'm stuck at the moment as my LINQ queries are returning LinqBindingList and that doesn't cast to ObservableCollection so I need to figure that out... which means - what is the role then of LinqBindingList if I want to share assemblies?  The only benefit I see now is the indexing if I do large data processing on the server?  How am I going to do filtering now on my bindable collection in Silverlight?  Do I do it now at the UI level in the grid?

LINQ to CSLA has a dependency on the C5 data structure library. At the time we were building 3.6 there wasn't a fully working C5 for Silverlight (might not be now, I haven't checked) and so it wasn't possible to port the indexing features to SL.

LinqBindingList exists primarily to support various data binding scenarios, mostly in Windows Forms. I'm sure it will become important in WPF as well - though there's another thread where the whole question of collections and WPF binding is discussed - and this is probably the thorniest issue I face looking at version 4.0.

The picture was (and is) even less clear in Silverlight. Does LBL have a role? Would it offer value, or get in the way?

Due to those issues, and in the interest of time, because LINQ to CSLA is a volunteer effort on Aaron's part, I decided to leave LINQ to CSLA out of CSLA .NET for Silverlight for the time being.

Jack replied on Wednesday, June 03, 2009

Would this help for an implementation of LinqBindingList in Silverlight?
http://blogs.msdn.com/delay/default.aspx

If Microsoft is maintaining the tree logic ...

Geeky replied on Monday, February 23, 2009

Jack:

#if SILVERLIGHT #end if works fine
#if !SILVERLIGHT #end if works fine

Bottom line - use UPPERCASE (which is annoying if you dislike ALL UPPER).

Project Properties -> Build -> Conditional compilation symbols - change to "Silverlight"?

Although it should be upper case by convention so I don't know if that will even work or if it will affect other things.  You could just add "ag" ;-)

Jack replied on Monday, February 23, 2009