gokubi.com

I wrote the other day that VisualForce was the real deal. I wanted to follow that post up with some more thoughts now that we’re actively developing with it.

First, let me say that we are trying not to write any S-Controls anymore. One reason is that S-Controls have a shelf life baked into them. At the top of my S-Controls I include Saleforce’s AJAX toolkit, which is what makes them so powerful. But, a bunch of my code was still using an old toolkit (circa way back in 2006) that is no longer getting updated. That’s fine with me–all my new development was always with the new toolkits. But, when Firefox 3 came out, all my code with this very old toolkit broke because of something with Firefox. I have no idea why, but it did.

With VisualForce, there are no includes of files that will go obsolete. So it is the most future-proof way to build UI in Salesforce short of hosting everything yourself.

Second, after spending years building S-Controls, VF is a dream to work with on so many levels. In that earlier article I talked about the big architectural reason why it’s better. Some practical realities have hit home since I’ve been writing actual production code.

1. Testing is the gift that keeps on giving - UI that I write with VF has all it’s logic in Apex classes. I can write tests for these classes. Testing is massively helpful in creating, understanding, and maintaining code. I can’t overstate it’s value.
2. Deployment is getting much easier - moving code around has massively improved with the new metadata api. Just yesterday I dragged-and-dropped VF with Apex classes from a sandbox into production. It just plain worked. I was shocked, but it shows how much implicit respect I have for the Sf.com development team that I even tried it. I find myself constantly trying things that I know probably won’t work, and very often things just work! Kind of like using an iphone in that way.
3. Fewer languages is better - All my logic is now in Apex. So I don’t have to remember how to write logic in S-Controls. Thank god. In some cases we had moved some of the logic from S-Controls to Apex webservices. Migrating this code to VF and Apex turned out to be really easy. And ditching the webservices simplifies and speeds up everything, of course.

So every new idea we have is going right to the VF drawing board. However, there still are some things to improve:

1. Invoking code - you can’t hook VF into buttons as easily as S-Controls, so we’ll be putting URL calls in there until we can directly reference the pages. Nice thing is that we reference by the page name and not the ID.
2. List buttons - there isn’t any way to have a list button written in VF process many checked records from a list. So we’ll have to keep writing JavaScript for these functions.
3. Detail of a record in edit mode - See my idea from yesterday for this killer platform feature. I think this is a massive one for the user experience and would really compliment Apex triggers with UI based “next actions.”
4. Packaging - I’m sure this will come in the next release.

As we get more proficient with VF (and testing VF) I’ll write more. But to date, I have to say I’m very pleased with the framework. This is a learning curve well worth climbing.

This entry was posted on Thursday, July 31st, 2008 at 7:58 am and is filed under CRM, Technology. You can leave a response, or trackback from your own site.