One thing which caught my eye was the integrated debugger within the native Firefox developer tools. This is not a new feature to those of us used to FireBug debugging but a very nice addition to the toolkit. Firebug is a fantastic tool and I cannot do without it – but it takes up memory and slows things down a bit. having an integrated debugger (I assume) will be quicker and less disruptive. We will have to have a play and see.
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.
Things are busy at home and at work so I won’t have a plugin demonstration this week – just a development tip
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
Test In Webpage
Change your jQuery code is XPage source panel
Test in Webpage
Change your jQuery code in XPage source Panel
Remember what it was like in the good old pre-XPages days
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
And there we have it – nothing 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
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
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.