Understanding the Salesforce APIs

This post was going to briefly discuss the differences between the enterprise wsdl and partner wsdl available in salesforce.com and what they both offer to us, the humble developer. However, before we get there, I think it prudent to do the 30,000 foot view of Visualforce and Apex...

When you sign up to Salesforce (you could get a free developer edition right now if you want!) you get (in a nutshell):

- A database

- A web front-end to enable data access

- A collection of objects pre-loaded in your db to define your CRM (Accounts, Contacts, Leads, etc...)

- The tools to configure your CRM (adding fields to objects, putting textboxes on forms, etc.)

What you also get, however, is a complete cloud-based development platform. Unfortunately, the development experience is poor. The least awful way to write your salesforce code is in Eclipse using the now officially sanctioned and supported salesforce.com plug-in, but as an even cruder method, you can simply navigate to the appropriate part of your salesforce site and type the code into your browser.

This poor experience is at the heart of why I'm creating my Salesforce Studio - I would like it eventually to become a feature-rich IDE - but at its core, it needs to be an application in which I could happily spend my days, like Visual Studio; not, unfortunately, like Eclipse + Force.com.

Now, for an organisation wishing to create custom solutions to bolt onto their Salesforce site, there is Visualforce.com - an online development capability which we can use to create pages that connect directly to your Salesforce data, using an MVC pattern.

Very briefly:

'Visualforce' is the umbrella term to describe the UI aspects of custom salesforce development, and there are two primary building blocks: Page and Component. As you might expect, you can nest your components into your pages.

'Apex' is the strongly-typed programming language that gives the developer access to the data, and allows us to add business logic to our applications. It is the 'C' in our MVC paradigm.

Those familiar with OO programming such as java or .net would be able to read Apex code straight off, and with access to the documentation would soon be able to write classes and pages.

Let's wrap this up with the simplest of examples:

First, let's write a custom controller that contains an instance of a custom object. We don't *need* to create a controller, we can just pass the name of the object into the 'standardController' attribute on our page, but a custom controller gives us somewhere to implement our bespoke business logic...

The controller would look something like:

Now we can create a page to display / manage pieces of information related to our custom object. Again, in a very trivial form:

So that's the simplest possible implementation of a custom page with custom logic in a controller.

Now, the 'MyObject__c' object (note the __c notation to define a customisation) is an SObject, as is the standard objects such as Account, Lead, Task, etc...

Why am I telling you all this? Well we need to manipulate SObjects if we are going to write a SOQL helper (or a front end to the salesforce.com db query-engine).

So next time, I'll go over what an SObject looks like in the enterprise WSDL, and what it looks like in the partner WSDL, and why they are both powerful and valuable to the humble developer...

Josh Smith is a legend

I'm creating a Salesforce Studio, and I'm doing it in WPF. Despite the fact that .net 3.0 was introduced to us back in 2006 (or ~25 Internet years ago), one still feels like a pioneer when creating something in WPF. Why have the development community (by and large) not accepted the technology to the same extent as its sister platform, WCF? Who can say? Certainly the much-documented 'learning curve' is reasonably steep - but it is undoubtedly a journey worth taking.

There are of course, some fabulous people at the forefront of the WPF community sharing their experiences with us, the humble (wannabe) programmer, supplementing msdn with their tips, tricks and tutorials. I personally follow Dr WPF, Karl Shifflet, Adam Kinney, Rob Eisenberg, Jaime Rodriguez, and my personal favourite blogger: Josh Smith. Incidentally, if I have missed anybody obvious from this list, then please pass them my profuse apologies, and let me know who and www.where such that I can correct my wrong-doings forthwith... many thanks :)

For those that would like to get into WPF, you really do need to read Josh's blog... WPF is non-trivial, a departure from the norm for practitioners of WinForms and/or asp.net development. Josh has the ability to discuss reasonably complex subject matter with clarity and authority, backing up his blogs with well-constructed, easy-to-follow code examples, typically made available on code-plex.

So it is to codeplex that our adventure begins... The idea that MVVM is a good fit for WPF, and that WPF is a good platform on which to practise MVVM had been maturing as a concept, and in February msdn published this article, which includes a link to a lightweight sample application which nicely demonstrates the core building blocks of an MVVM application:

- A ViewModelBase class which implements the INotifyPropertyChanged interface,

- a 'Workspace' framework, which reminded me of the MDI (multi-document interface) you used to see in C++ (MFC) apps of days gone by.

- A RelayCommand class which implements the ICommand interface, provided for simple commands. Allows the developer to optionally inject CanExecute logic into the constructor.

Skip forward to mid July and Josh posted an MVVM Foundation project here.

Fantastic... I have my starting point. I know my application will be sliced vertically by function: I'm going to want a login page, a SOQL helper, a text-editor for code files, and I have a few other ideas for features and functionality I want to provide in the app, too (but more on that in good time). So now, I have the framework to handle those vertical slices: For each feature, I can create a View, a ViewModel to furnish that View, and the mechanism for gluing them together, and presenting the view to the user in a consistent way.

Next time I want to talk about getting started with the salesforce.com Web Services API, and the fun and games I've been having with the DataGrid control courtesy of the WPF Toolkit (which comes baked into Studio 2010)

A brief update...

I just realised that my blog is still such a long way behind where I am in my project, and I really need to post stuff before the 0s and 1s drop out of my head, and I forget my learnings; but then I'm also cognisant of how much work there is still to be done, and far away I am from having anything substantial to actually blog about... Hamlet had it easy with his existential pondering; "To Code or To Blog - That should've been the question"

So I'm splitting the difference and

1) Writing some unit tests to catch up with the code base so far, and starting to think about the next set of features, and hence the next set of tests... I will get there with TDD, I really will!), and

2) Writing this all too brief post to explain this...

Coming Soon: The framework of the application so far, and why Josh Smith is such a legend...

Embarking on a journey...

It was Scott Hanselman and Joel Spolsky talking on Hanselminutes about (amongst other things) blogging, that suggested lots of blogs complain about stuff - the point of difference for a good blog is one that does something about the problem. They mentioned I Started Something by Long Zheung who doesn’t like UI inconsistency. So rather than complaining about it, he actually made a community website that does nothing but collect screenshots of dialogues with inconsistencies so that people can document and then download them. This was done a couple of years ago but it’s kind of a Stack Overflow for one thing, UI inconsistencies.

So I re-read my recent posts on working with Force.com, and asked myself "were you just bleating about stuff?" ummm....

Decision 1: Talk about stuff that's great, and don't just moan about the stuff that isn't: Change it!

In the meantime, I had decided that writing an article a month about reasonably random topics was fairly lightweight of me, so Descision 2: Blog more.

I'm hoping these two decisions can collide in a fairly positive way... I have decided to create something that will (hopefully) improve my development experience working with Salesforce.com, since it looks like I'm going to be working with it for a few more months at least.

Now usually when I think about writing bits and bobs of software, it's not with any consideration to longevity or stability of the code... It's typically me hacking together cool bits of the shiniest newest technology just to see what happens, so this may be a new experience for me... I really would like to end up with a product that brings actual benefit to at least me, and simultaneously continue my arduous, challenging, invigourating, wonderfully-rewarding journey up the WPF learning curve.

So, for the record, as of today - 5th August 2009 - Here's my grand design:

- Create a Salesforce.com development studio that supports:

• Querying the Salesforce data objects using SOQL / SOSL

• Running anonymous code blocks.

• Editing of Apex code and Visualforce pages/components

- Use WPF as a development platform

- Use M-V-VM as a design pattern

and fundamental to all this is to create a product that *feels* much nicer to use than the existing tool set. I'm hoping to identify pain points with the tools I have, and create a better alternative where possible.

I'll be blogging about the journey, and depending on how happy I am with the destination, I may even post my code for public ridicule along the way :)

Binding to an ObservableCollection in a WPF ListBox

There's a really crucial, and when one stops to consider it, totally obvious step to take when binding an ObservableCollection to a WPF items container... make sure the collection exists!

I spent a fruitless couple of hours recently staring at blog after blog after documentation after blog on this, because I got the timing of the interactions wrong.

There's heaps of documentation available that explains how your View code (your xaml) will listen to changes in ObservableCollections (i.e. items are added or removed from the collection), and how it will listen for changes to objects that implement the INotifyPropertyChanged interface (and fire PropertyChanged as appropriate).

However - the bit I was missing was the fact that the View binds to the ViewModel very early on in the piece; if the ObservableCollection is still null, then the Binding object is null... creating new objects later is irrelevant, because the view is not listening to those new objects, it is listening to 'null'. We need to instantiate an instance of the collection (even if it is empty) in the ViewModel's constructor, such that the binding has an object against which it can listen for changes.

The wrong way:

- declare private instance of ObservableCollection, and public getter that returns this instance

- Bind to Property (which is still null)

- Do work to get data (triggered by some Command, like button click)

- set ObservableCollection to be new instance and populate with data.

- Wonder why no changes are propagating to the UI

The right way:

- Instantiate private ObservableCollection in *Constructor* for ViewModel

- Bind to it (empty *but non-null* collection)

- Do work to get data (triggered by some Command, like button click)

- populate (already instantiated and bound) Collection with data

- Bask in glory as UI fills with data goodness

This is so obvious when you think about it...