Making the Common Ground Contact Page Less Intimidating with Clicks and a Little Code

The way that we use today means that we track a lot of data about contacts.  We have fields relating to a contacts relationship with us as a volunteer, staff member, staff alumni, and recruit.   Until now, we’ve used Record Types and the associated page layouts as a way of managing what information is displayed for a particular record.  With our implementation of Common Ground, however, we’re going to need to consolidate down to a single primary record type (Household Contact), so as to not break any of the out of the box functionality of the package.  This leaves us with a bit of a problem, as not only will we need to display all of our existing fields on a single page layout, but also Common Ground adds a host of fields to the layout as well.  We’re concerned that such a long form will make it difficult for our users to find the data that they need, increasing the likelihood of incomplete data entry and slowing adoption.

At Dreamforce last week, I saw some neat tricks for using VisualForce to help manage this kind of information overload, and I’m looking forward to using them in the future, but because I want to interfere as little as possible with the core Common Ground functionality, I can’t use a VF page to override the base contact page. I’d love to set up a tabbed layout for the page, but that will have to wait for some time after we’re successfully up and running.  I’d also like to be able to set the default behavior of different sections to be minimized, but although there is an idea on the IdeaExchange (vote for it here) there’s no sign of it being under consideration, so that won’t work.

My next best alternative then, seems to be to bring up a secondary page that displays the information I’m looking for.  It does require an additional button click on the part of users, but it should be faster than scrolling through 200 fields on the record.  Creating a custom button on the object is simple enough to do, and a basic Visual Force page for it to load is also straightforward.  One twist, however, is that I also want to be able to accommodate the addition and removal of fields easily (meaning without out having to recode pages whenever the fields change).  This led me, naturally to a new feature in the Spring 11 release that I haven’t gotten to try yet:  Field Sets!

A Field Set is a collection of fields on an object that can be set up and maintained (adding and removing fields) by an administrator and can then be called by a VisualForce page using a simple <apex:repeat> tag (a good blog post explaining the use is found here). Whenever the page loads or refreshes, it will cycle through all the fields in the Field Set, picking up whatever has been added or deleted by the administrator.

By defining a couple of Field Sets on my Contact object (go to Setup/Customize/Contacts/Field Sets) and then building a simple VisualForce page to display the fields, I’m most of the way to my solution.  Of course, just viewing the data isn’t going to be sufficient, our users also want to be able to work with it, so I also want to be able edit the data.  I’m trying to keep this solution light on code, however, so I don’t want to have to build a controller to support business logic on the page (ideally, this page wouldn’t even exist), so I want to keep using the standard Contact controller if at all possible.  Another neat new feature from Spring 11 comes into play here:  VisualForce Inline Editing.

Inline editing has been around in the native UI for a while now, but only became available recently for VisualForce pages.  There are a couple of ways of implementing it, but for my purposes, the <apex:inlineEditSupport> component added to an <apex:outputfield> does the job splendidly, combined with the addition of the right buttons and voilà ! I’ve got a functional page that allows my users to view and edit their specialized data.

Here’s the VF Page code:

<apex:page standardController="Contact" showHeader="false">
<apex:form >
<apex:pageBlock mode="inlineedit" title="Citizen Teacher Specific Information">
<apex:pageBlockButtons >

<apex:commandButton action="{!save}" id="saveButton" value="Save"/>
<apex:commandButton onclick="resetInlineEdit()" id="cancelButton" value="Cancel"/>
<apex:pageBlockSection >

<apex:repeat value="{!$ObjectType.Contact.FieldSets.CT_Info}"
<apex:outputField value="{!Contact[field]}">
<apex:inlineEditSupport showOnEdit="saveButton, cancelButton"
hideOnEdit="editButton" event="ondblclick"
changedStyleClass="myBoldClass" resetFunction="resetInlineEdit"/>



There’s some more that can and needs to be done (a tip of the hat to @dschach in this post that the Cancel button doesn’t really cancel and reset your values, it just exits you out of the edit) – but it was a pretty easy way to get around a somewhat vexing problem.

About these ads

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Get every new post delivered to your Inbox.

Join 1,078 other followers

%d bloggers like this: