jQuery .slideToggle() – enhancing user experience *and* reducing code

In this article I will demonstrate how the jQuery .slideToggle() method can create a better user experience within your XPage *and* makes your code easier to maintain than using SSJS to achieve the same goal.

Demonstration

The effect is demonstrated here

Introduction

Many use cases require information to be hidden from a user depending on the current state of the web form they are working on. Upon the desired trigger, more information is made available to them. This is a simple demonstration on how to make a better user experience and also reduce your code. In this case I have demonstrated how to show and hide a viewPanel. When displayed all the normal pager functionality continues to work and both examples maintain the state of the pager.

,slideToggle() demo page
,slideToggle() demo page

.slideToggle()

.slideToggle() is a core jQuery method which acts on a specified container. It performs the following

  1. binds two other core methods, .slideUp() and .slideDown()
  2. toggles the style, display: block and display: none

in its simplest form you would use something like this

<xp:div styleClass="reveal" id="showDiv">
	Your stuff HERE
</xp:div>

and then at the bottom of your XPage markup you’d add

<script>
	$(".reveal").slideToggle('slow')
</script>

This would very simply animate the expansion of the section and when it was clicked again it would animate the collapse of the section. This is really nice because we do not have to programmatically track the state of the display.

To do the same thing in SSJS we have to track the state of the display. I do this by adding an attribute to the div programmatically and tracking a viewScope variable. This is also 8.5.3 code only because I need to add an attribute to the xp:div.

<xp:div styleClass="reveal" id="showDiv">
		<xp:this.attrs>
			<xp:attr name="style">
				<xp:this.value><![CDATA[#{javascript:"display: "+viewScope.showPanel}]]></xp:this.value>
			</xp:attr>
	Your stuff HERE
</xp:div>

I would then use a button with the following markup to track the current state and then onclick change the state and partialRefresh

<xp:button value="SSJS Partial Refresh" id="button1">
	<xp:eventHandler event="onclick" submit="true"
		refreshMode="partial">
		<xp:this.action>
			<xp:executeScript>
				<xp:this.script><![CDATA[#{javascript:sTemp = viewScope.showPanel == "none" ? "block" : "none"; viewScope.showPanel = sTemp}]]></xp:this.script>
			</xp:executeScript>
		</xp:this.action>
	</xp:eventHandler>
</xp:button>

You also have to consider there is a round trip to the server every time an SSJS button is clicked which on a slow connection can be detrimental to the user experience.

partialRefresh() round-trip to the server and back
partialRefresh() round-trip to the server and back

Even in this simplistic example you can see that there is more code to maintain in the SSJS version and advantages to using the jQuery version.

Conclusion

jQuery can make both your user experience and your maintainability easier when used judiciously.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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