Using jQuery to test if a checkbox on your XPage is checked

Problem
I have a checkbox and if it is checked I need to hide a table. How can I test if it is checked or not in a simple fashion?

Solution
Here is the checkbox

<xp:checkBox text="Audit" value="#{project.audit}" id="checkMarky">
</xp:checkBox>

And here is my table

<xp:table styleClass="markyTable" style="width: 100%">
<xp:tr >
	<xp:td styleClass="td1" colspan="4">
		..stuff
	</xp:td>
</xp:tr>
</xp:table>

When the page Loads
When the page loads I determine if the table needs to be displayed or not based on the checkbox status. Using the “.is()” function I can return true or false and then based on that I can determine if the table is hidden or not.

$('document').ready(function(){
	//test if the id ending in checkMarky is checked
	if ( $('[id$=checkMarky]').is(':checked') ){
		//if so then hide all items with the class markyTable
		$('.markyTable').css('display', 'none')
	}
})

Toggling the Table
And then in the onChange event of the checkbox I make a very simple change using slideToggle. In the onLoad I determined if the table should be hidden or not – so if the status if the checkbox is reversed (changed) then either show or hide the table – and in this case use nice transition as well just as a bonus.

	$(".markyTable").slideToggle()

Conclusion
.is(‘:checked’) is the secret sauce in this example and returns true or false if the checkbox is checked.

7 thoughts on “Using jQuery to test if a checkbox on your XPage is checked

    • Thanks for the comment(s) Thimo

      There is a good article on doing jQuery the right way – http://eng.wealthfront.com/2010/10/jquery-right-way.html – and there are multiple jsperf comparisons done on the subject – it is hard to say what significant means – it is really dependent on the size of the page and the number of elements that have to be processed.

      As a general rule I have tended to use id$= in my examples because I think it is easier to understand/read than having to go into lengthy detail about how the XPage makes the ids and how we reference them using the # or $ notation. You are right to point out though that there is “some” performance lost in doing it this way – $(‘#idTag’) is always going the fastest because it uses the native getElementById JS method.

      • That’s a great article you link to.

        I added “significant” because without it the answer would be an easy “yes”. Of course there’s an impact on performance, but how likely is it that the user will notice it? And that’s the thing that counts. Up until now I would always use the ‘#id’ selector, but I might ease a bit on that now and create cleaner code.

        If performance is acceptable also greatly depends on the browser/computer combo that’s being used. See this page for a testcase with two different selectors executed on a full range of different browsers: http://jsperf.com/attribute-versus-class-selector

    • Dojo also makes use of the “$=” such as:

      dojo.query(“[id$=’someId’]”);

      Just as an FYI I’ve ran into times where I got the wrong element by using using that, so I recommend to also include the “:” in that statement like:

      dojo.query(“[id$=’:someId’]);

      I do that because an id that ends with “someId” or “othersomeId” would match and you might end up with something other than what you were expecting.

      • Thanks Keith

        You can break it with the :someId as well. If you have the same field id on two custom controls, put both of them on the same Xpage – both will be displayed but will have the same “ending” idTag in the DOM.

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