Rockford Lhotka

 Friday, February 18, 2011

Bxf and CSLA .NET both include a TriggerAction control. This control helps support the MVVM design pattern in WPF, Silverlight, and WP7 applications.

(Bxf is completely independent from CSLA – I donated TriggerAction from CSLA to the Bxf project a while back though, so this type is available from either framework)

The specific problem addressed by TriggerAction is the need to invoke a verb (method/command) on your viewmodel object in response to any arbitrary UI event. One common UI event is something like a button click event, though you can often use commanding in that case. But there are numerous other UI events from many controls other than buttons, and you might want to have one of those UI events cause the viewmodel to perform an action.

TriggerAction basically wires arbitrary UI events to methods on the current DataContext (usually the viewmodel object).

<bxf:TriggerAction TargetControl="{Binding ElementName=MyControl}"
                                           DataContext="{Binding Source={StaticResource vm}}"
                                           MethodName="MyAction" />

TriggerAction listens for the trigger event from the TargetControl. When it handles that event, it invokes the specified method (MethodName) on its current DataContext object. There’s nothing more to it.

To get TriggerAction working you need two things: source and target.


  1. TargetControl must be set
  2. TriggerEvent may be set (default is “Click”)


  1. DataContext must be set (or inherited from the container)
  2. MethodName must be set

Parameter (optional):

  1. MethodParameter may be set (to a value or binding expression)
  2. RebindParameterDynamically may be set to true (to force rebinding of MethodParameter to work around issues with certain control properties such as ListBox.SelectedItems)

The most common causes of failure when using TriggerAction are that the TargetControl isn’t set right, or the DataContext isn’t set right, and of those two the most common is that the DataContext isn’t what you think it is (that happens to me all the time).

The method TriggerAction invokes on the DataContext object can accept either 0 or 2 parameters:

public void MyAction()


public void MyAction(object sender, ExecuteEventArgs e)

The ExecuteEventArgs class is also defined in Bxf and CSLA. If you use TriggerAction from Bxf.Xaml, you must use ExecuteEventArgs from Bxf.Xaml. If you use TriggerAction from Csla.Xaml, you must use ExecuteEventArgs from Csla.Xaml.

If you are using Bxf and CSLA together it is important to understand that the ViewModel<T> class from Csla.Xaml uses the Csla.Xaml.ExecuteEventArgs type. If you are using the Bxf TriggerAction control, you’ll need to create your own viewmodel types from Csla.Xaml.ViewModelBase<T> to accept the Bxf.Xaml.ExecuteEventArgs type.

Bxf | CSLA .NET | Silverlight | WP7 | WPF
Friday, February 18, 2011 5:31:39 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, February 15, 2011

CSLA 4 is now available through NuGet, the package installer for .NET products.

This is thanks to Johann Hough (jaans on the CSLA forum) - thank you Johann!

The following packages are available:

  • Core
  • Silverlight
  • WPF
  • Windows Phone
  • Windows Forms
Tuesday, February 15, 2011 10:03:29 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, January 19, 2011

I’ve started the process of porting CSLA .NET version 4.1 to MonoDroid. I expected this to be relatively easy because I’ve already got a version of CSLA 4 running on WP7, and from everything I know about MonoDroid it should be pretty comparable (excluding anything to do with XAML and UI concepts of course).

After a couple hours of trying to get the Android emulator to run on my machine, I discovered that the hybrid C++ and Java worlds really don’t “get” Windows. They interpret Windows configuration in different ways. I’m not sure which one is lame and out of date (by around a decade), but either C++ or Java apparently needs help…

Fortunately some googling (with Bing of course Smile) turned up the answer in the form of an environment setting named ANDROID_SDK_HOME that both C++ and Java will honor. The problem is that my User directory isn’t on the C drive, and either C++ or Java can’t handle this concept. Setting ANDROID_SDK_HOME to the path of my actual User directory solves the issue so the emulator works as expected.

The Android emulator is extremely slow, but functional. Just deploying my tiny little test app takes several minutes, and my computer is no slouch. It is clear that Android developers don’t round-trip very fast in terms of running their code to see if it works. I feel sort of like I’m back in 1992 on a VAX where the compile-link-run cycle took minutes. I’m obviously very spoiled with the performance of things like the WP7 emulator or the ASP.NET development web server, where the compile-debug/run cycle takes seconds (at most).

The process of getting CSLA 4 to at least build in MonoDroid took around 4 hours of work. Not that I’m done, but the code does compile at this point. The holdups and issues are:

  1. MonoDroid doesn’t have ObservableCollection and a set of related types, so I’ve started implementing them myself
  2. MonoDroid doesn’t know about “Add service reference”, it only knows about “Add web reference”, and that means I need to create a new data portal proxy/host pair
  3. It doesn’t look like the System.ServiceModel assembly that comes with MonoDroid actually works – my one remaining build error has to do with this assembly – and this probably means some other client-side data portal elements will be affected (like LocalProxy) – I think this indicates some bad factoring on the part of CSLA in terms of the client-side data portal implementation though, so in an odd way this might be beneficial in that the problem highlights a design flaw that needs fixing
  4. There are some bugs in MonoDroid in VS, where setting some project properties “doesn’t take” – change the property values in VS and they aren’t saved to the project file – but edit the project file in a text editor and the changes are honored – not a big deal, and MonoDroid is in an early beta, so this sort of thing is to be expected
  5. There’s no XAML or directly comparable concept on Android, so I’m not even trying to port Csla.Xaml, only the core Csla project – I’ll probably need to create a Csla.Android project with UI components appropriate to the Android UI technology

I mocked up the initial types to implement ObservableCollection, and it won’t take a lot more effort to make them have the functionality required by CSLA. I don’t feel the need to completely replicate those types – only the parts CSLA cares about.

Creating a data portal proxy/host pair isn’t hard, the data portal is designed with this sort of flexibility in mind. However, this will be the first non-WCF proxy/host pair I’ve built on the Silverlight/WP7 code base, so I’m looking forward to establishing that it is as easy as it should be.

The unexpected dependencies on System.ServiceModel are probably the most worrisome aspect of this project so far. I suspect unraveling the dependencies and fixing the design/implementation may lead to some breaking changes in the Silverlight/WP7 code. On the other hand, if my early suspicions are correct, the design is probably flawed and I’ll be able to improve things as a result.

The question is whether I leave the SL/WP7 code alone and just fix the dependencies in the Android code base. That’s probably what I’ll do in the 4.x timeframe, because I really try to avoid substantial breaking changes in point releases…

The loss of Csla.Xaml is not ideal. At the very least I think a Csla.Android project will need ViewModelBase and ViewModel, but I suspect other Android-related UI components may be required.

Anyway, I’m quite impressed by MonoDroid. It seems pretty complete, pretty functional, and pretty well integrated into Visual Studio. Other than my issues with the emulator configuration the install was painless.

To head off this question before it is asked: I do expect I’ll create a version for MonoTouch at some point.

But MonoDroid has a much lower barrier of entry since it installs on Windows and works in Visual Studio. MonoTouch requires a non-trivial cash outlay to buy a Mac, and a non-trivial time outlay to learn the Mac, MonoDevelop, some Mac svn implementation, etc. Where I’ll probably have a working version of CSLA 4 for Android in under 20 hours, I strongly suspect it will take more than twice that long (and a lot of money) to get a version working in iOS.

In this regard I must give kudos to Google, Android and MonoDroid – they have a much lower barrier to entry than Apple currently provides.

Wednesday, January 19, 2011 11:30:11 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, January 18, 2011

csla_logo1_32I am pleased to announce the release of CSLA .NET version 4.1 with support for .NET, Silverlight and Windows Phone 7 (WP7).

You can download CSLA 4 version 4.1 at

Although there are numerous new features in version 4.1, the primary focus of this release is Windows Phone 7. With CSLA 4 version 4.1 you can now author business classes that run unchanged across the entire .NET platform:

  • Windows Phone 7
  • Silverlight
  • WPF
  • ASP.NET Web Forms
  • WCF services (SOAP and REST)
  • asmx web services
  • Windows Forms

The ability to reuse your business layer on .NET, Silverlight and WP7 is incredibly powerful, enabling you to extend your application to users on Windows, the web, and now the phone.

You can learn how to use CSLA 4 to build scalable, flexible, and maintainable applications through the Using CSLA 4 ebook series. This ebook series is currently a work in progress and will be finished in the first half of 2011.

Tuesday, January 18, 2011 7:30:40 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, January 14, 2011

Dunn Training is offering a CSLA 4 training class on February 23, 2011 in Atlanta.

If you are looking for CSLA .NET classroom training, this is a great opportunity. Here’s a quote from a student who attended the December class:

Dunn’s CSLA training was phenomenal!!! It significantly advanced our team’s knowledge of CSLA and helped layout the roadmap for our future development. Mark Berry  holistically demonstrated how CSLA works with MVVM, Silverlight, WPF, Expression, OO Programming and Code Generators. He also successfully answered extremely challenging CSLA questions that were thrown at him during class. Our team is pretty knowledgeable with CSLA and the other technologies, but Mark took us to an entirely new level, sprinkled in some nice tips, tied it all together, and reenergized our team. The training was well worth the money.

Friday, January 14, 2011 5:36:03 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, January 12, 2011

Anyone who expected HTML5 to be more standard or consistent than previous HTML standards hasn’t been paying attention to the web over the past 13+ years.

Google’s decision to drop H.264 may be surprising as a specific item, but the idea of supporting and not supporting various parts of HTML5 (or what vendors hope might be in HTML5 as it becomes a standard over the next several years) is something everyone should expect.

I have held out exactly zero hope for a consistent HTML5 implementation across the various browser vendors. Why? It is simple economics.

If IE, Chrome, FF and other browsers on Windows were completely standards complaint in all respects there would be no reason for all those browsers. The only browser that would exist is IE because it ships with Windows.

The same is true on the Mac and any other platform. If the browsers implement exactly the same behaviors, they can’t differentiate, so nobody would use anything except the browser shipping with the OS.

But the browser vendors have their own agendas and goals, which have nothing to do with standards compliance or consistency. Every browser vendor is motivated by economics – whether that’s mindshare for other products or web properties, data mining, advertising, or other factors. These vendors want you to use their browser more than other browsers.

So in a “standards-based world” how do you convince people to use your product when it is (in theory) identical to every other product?

When products have a price you could try to compete on that price. That’s a losing game though, because when you undercut the average price you have less money to innovate or even keep up. So even in the 1990’s with Unix standards vendors didn’t play the pricing game – it is just a slow death.

But browsers are free, so even if you wanted the slow death of the price-war strategy you can’t play it in the browser world. So you are left with “embrace and extend” or “deviate from the standard” as your options. And every browser vendor must play this game or just give up and die.

This happened to Unix in the 1990’s too – the various vendors didn’t want to play on price, so they added features beyond any standard with the intent of doing two things:

  1. Lure users to their version of Unix because it is “better”
  2. Lock them into your version of Unix because as soon as they use your cool features they are stuck on your version

The same is true with browsers and HTML5. All browser vendors are jockeying now (before the standard is set) to differentiate and shape the standard. But even once there is a “standard” they’ll continue to support the various features they’ve added that didn’t make it into the standard.

This is necessary, because it is the only way any given browser can lure users away from the other browsers, thereby meeting the vendors’ long term goals.

People often say they don’t want a homogenous computing world. That they want a lot of variation and variety in the development platforms used across the industry. Over the past 13+ years HTML has proven that variation is absolutely possible, and that it is very expensive and frustrating.

Working for consulting companies during all this time, I can say that HTML is a great thing. Consultants charge by the hour, and any scenario where the same app must be rebuilt, or at least tweaked, for every browser and every new version of every browser is just a way to generate more revenue.

Is HTML a drag on the world economy overall? Sure it is. Anything that automatically increases the cost of software development like HTML is an economic drag by definition. The inefficiency is built-in.

The only place (today) with more inefficiency is the mobile space, where every mobile platform has a unique development environment, tools, languages and technologies. I love the mobile space – any app you want to build must be created for 2-5 different platforms, all paid for at an hourly rate. (this is sarcasm btw – I really dislike this sort of blatant inefficiency and waste)

But I digress. Ultimately what I’m saying is that expecting HTML5 to provide more consistency than previous versions of HTML is unrealistic, and moves like Google just took are something we should all expect to happen on a continuing basis.

Wednesday, January 12, 2011 11:49:44 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, January 11, 2011

One of the nicest things about TFS is the way it can be customized and extended to fit different types of process.

A colleague of mine, Mario Cardinal, works for a company who has built an Agile/SCRUM extension:

This really highlights how TFS can be used as the basis for a deep solution around a specific process, methodology or project philosophy. Cool stuff – and if you do SCRUM you should probably take a look at Urban Turtle to see if it can help you out.

Tuesday, January 11, 2011 12:41:56 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, January 4, 2011

The completed first draft of the Using CSLA 4: Creating Business Objects ebook is now online and available for purchase. UsingCsla4-02-120

If you’ve purchased (or now purchase) the Using CSLA 4 ebook series you’ll also have access to this new ebook.

This is book 2 of the series. The next book will be Using CSLA 4: Data Access, followed by Using CSLA 4: Security. These first four ebooks cover all the core concepts around using CSLA 4 to build your business layer, along with various options for building a data access layer and implementing authentication.

After these four are complete I’ll move on to ebooks covering how to use a CSLA .NET business layer to create applications with different types of UI, including Silverlight, WPF, ASP.NET MVC and Windows Phone 7 (WP7).

Here’s the top-level outline of the Creating Business Objects book’s contents:

  1. Introduction

  2. Key Object Concepts

    1. Stereotypes

    2. Serialization

    3. Object Lifetime

    4. Object Relationships

    5. Object Identity and Equality

    6. Platform Differences in .NET and Silverlight

    7. Property Declarations

    8. Method Declarations

    9. Metastate

  3. Solution Structure

    1. Project Types and Assembly References

    2. Combining Project to Create Solutions

  4. Object Stereotypes

    1. Editable Objects

    2. Read-Only Objects

    3. Execution Objects

    4. Criteria Objects

    5. LINQ Types

    6. Windows Forms Types

  5. Business Rules

    1. Business and Validation Rules

    2. Authorization Rules

For those who are wondering, the first ebook is almost through the editing process and the “draft” designation will then be removed.

Tuesday, January 4, 2011 5:41:03 PM (Central Standard Time, UTC-06:00)  #    Disclaimer