In this article I will demonstrate how using Firebug can significantly reduce your development time with jQuery (or dojo) when you are trying to use selectors. There is no doubt that that out of the box functionality provided by XPages is very powerful, but to accomplish the capabilities we all know (and love?) the accompanying HTML is complex and not necessarily easy to navigate manually.

For more information on FireBug check this out

Things are busy at home and at work so I won’t have a plugin demonstration this week – just a development tip

Introduction
As I have discussed in this blog, using dojo and JQuery selectors are a very powerful way to facilitate “enhancing” your user experience with some nice UI changes. Many times however this can be a frustratingly slow process if you are doing trial and error development something like this:

• Write your jQuery selector code in the XPage source panel
  • Save
  • Test In Webpage
    • Nothing happens
• Change your jQuery code is XPage source panel
  • Save
  • Test in Webpage
    • Nothing happens
  • Curse
• Change your jQuery code in XPage source Panel
• Remember what it was like in the good old pre-XPages days
• *sigh blissfully*
• Curse
• continue…..

Using the FireBug console we can significantly speed up this process by enacting real time changes to the webpage and not creating the XPage code until we know we have good working JavaScript.

Example

Here is a sample page with a typeAhead and a ViewPanel

and here’s our firebug console with a simple piece of jQuery code to change the css of all input fields, giving them a red border

• Enter the text
• Hit run
• And there we have it – nothing happened ?!?
• Curse
• #FAIL 😦

What happened?

Well if you look over on the left you can see the jQuery object which has been returned

Clicking on it shows us the element and look it DID get set……..

What’s happening is that the INPUT we see is actually masked by DIV styles which are pegged as “!important” in the stylesheet and over-ride the inline style 😦 Can you imagine how long it would have taken you to figure that out just by looking at the code? Using FireBug has given us a quick insight into what’s going on….so if we want a red field then we have to traverse up the Document Model (DOM) tree and color the DIV containing the INPUT field…..

As you can see below I tried a few examples but could not get the field to color – and then I took too many parents and made all the DIVs red. it is also a fascinating way to see in real time how the jQuery DOM navigation works…..still I don’t have what I was looking for – a red field on its own 😦

Starting again if you look at the HTML in the DOM you can see what needs to be selected and we can make it red….select the DIV with the id ending in inputText1

• yay !

Now of course you wouldn’t do this in real life – you would set a class and/or style on the field in the XPage client but this is a demonstration 😉

Coloring the viewPanel

We can use a CSS3 selector to style the nth column of the viewPanel – but unfortunately this does not work in IE

	<style>
		TABLE[id$='viewPanel1'] td:nth-child(3) {background-color: yellow}
	</style>

But jQuery rocks browser incompatibility issues and we can use firebug to get the right  jQuery and then apply it through the code to work in IE. Yes we used firebug to make sure the jQuery works – but this is jQuery and it is BUILT to overcome browser incompatibility issues. Instead of using the CSS3 nth-child selector, jQuery detects IE and trverses the table manually looking for the nth child in a loop – this is inefficient but the final effect is the same.

This is a big reason why you should use a library like jQuery or dojo – they were designed to help get around browser incompatibility problems.

	<script>
		$("TABLE[id$='viewPanel1'] td:nth-child(3)").css('background-color', 'green')
	</script>

 

Conclusion

I hope you enjoyed this quick(ish) tip. This only scratches the surface on FireBug and there is SO much more to learn/discuss !