Visualforce Inline Editing – I’m In Love

I’m totally addicted to the new Visualforce inline editing feature. It all started with this post by Josh Birk at Developerforce. I liked it, but as a “standardstylesheets” specialist, I wanted a bit more.

Then I looked at the Visualforce apex:inlineEditSupport documentation, and I was hooked.

Okay, so you’re probably wondering why this is so neat. I’ll show you how to enable fields for inline editing, and then I’ll show you why the apex:inlineEditSupport tag is completely unnecessary!

Here’s a simple example. You’ll notice that inline edit support has only been given to the contact.phone field.

<apex:page standardController="Contact" standardstylesheets="true"
	showheader="true">
	<apex:form >
		<apex:pageBlock mode="maindetail">
			<apex:pageBlockButtons >
				<apex:commandButton action="{!edit}" id="editButton" value="Edit" />
				<apex:commandButton action="{!save}" id="saveButton" value="Save" />
				<apex:commandButton onclick="resetInlineEdit()" id="cancelButton"
					value="Cancel" />
			</apex:pageBlockButtons>
			<apex:pageBlockSection >
				<apex:outputField value="{!contact.lastname}"/>
				<apex:outputField value="{!contact.accountId}" />
				<apex:outputField value="{!contact.phone}">
					<apex:inlineEditSupport showOnEdit="saveButton, cancelButton"
						hideOnEdit="editButton" event="ondblclick"
						resetFunction="resetInlineEdit" />
					</apex:outputfield>
			</apex:pageBlockSection>
		</apex:pageBlock>
	</apex:form>
</apex:page>

1. resetInlineEdit() is referenced in the code, but the actual Javascript isn’t shown anywhere. PLEASE don’t be fooled by the bad code in the documentation: It works perfectly for that “undo” arrow by the inline edit field, but it doesn’t work on the cancel button.
2. changedStyleClass is optional. Omitting it uses the standard style we’re all used to. And referring to a style that isn’t included anywhere just defaults to the system default.
3. PageBlock here has no “mode” attribute. This means that we can specify only the fields we want for inline editing. However, if we place the inlineEditSupport tag as an immediate child of the PageBlock, it will apply to every field in that PageBlock (or dataList, dataTable, form, outputField, pageBlockSection, pageBlockTable, repeat).

Here’s my next step: Find a way to hide the Cancel button on pageload, but show it when any field is inlineEdited. Javascript gurus have a solution?

(An aside: In Josh’s code sample, he uses a standard method called “quicksave.” It’s not in the Apex or Visualforce documentation, but we find here that “The quickSave() method on the standard controller performs the same database operation as the save() method but returns the user to the same page rather than navigating away.”)

Want to know why this is unnecessary?

It is undocumented, but is shown in the code sample in the Visualforce guide: use

<apex:PageBlock mode="inlineEdit" >

to set every field to inlineEdit and use default styles, etc. I don’t know how it will affect buttons shown/hidden, but give it a shot.

The attributes for inlineEditSupport are pretty simple:

Attribute Name	My Description
changedStyleClass	can refer to a style class included in the page or in a referenced CSS sheet in Static Resources
disabled	disables inline editing. This is really cool because you can put any logic in here. (On a separate note, inline editing respects field-level security, so if the user can’t edit a field, this attribute is basically set to TRUE. This is also a good tag because it lets you avoid using the rendered attribute with a plain outputtext/outputfield component to do your “can the user edit this” logic.
event	What makes the field switch from output to input. This is the usual list of Javascript events. (ondblclick, onmouseover, onmousedown, etc)
hideOnEdit	This one is cool. Give every commandButton on the page an id (because you do that anyway, right?) and then list the ones that should only be shown when this field is in input mode.
id	Seriously, folks, always give your elements ids. Not only is it good practice for adding Javascript to your page, but it avoids that silly “j_40” style id automatically generated… which shows when I view the source of your page, making you look bad.
rendered	We all know how to use this. I admit: I can’t think of a reason to use this as a child of outputfield, but I can certainly think of reasons to use it when it’s a child of apex:repeat, as those don’t necessarily respect field-level security when used with custom controllers.
resetFunction	This one is addressed below. It’s the Javascript function that resets the field, undoing all non-committed inline edits.
showOnEdit	Buttons to show when the field is edited. See hideOnEdit.

What are your next steps? Planning to add this to your page layouts? Looks like anyone with cool tools to convert regular page layouts to Visualforce layouts is going to have a lot of work to do!