Dojo Firebug Extension – from an XPage developer’s perspective

In this article I take a rather irreverent look at, and describe some what I was hoping would be, the useful capabilities of the dojo firebug extension available at https://addons.mozilla.org/en-US/firefox/addon/dojofirebugextension/

Introduction

I love firebug for my client side JavaScript development – for many reasons too numerous to mention here. If you have no idea what firebug is then you should google it and find out – USE IT and you will never go back…..

So what’s this Dojo extension all about then ?

Right off the bat I loved finding this quote “The Dojo Firebug Extension started as an internal IBM initiative to help IBMers working with Dojo.”, and more importantly got me straight off on the thought of what can this do for me in my XPages?

The documentation is available here – https://getfirebug.com/wiki/index.php/DojoFirebugExtension_Reference_Guide and as firebug extensions go – this one is fairly well documented – nice job 🙂

You have to download a different version based on your firebug and your firefox version….that’s kinda weird and disconcerting and they don’t have my version of firebug or firefox – but hey we truck on in hope.

So What does it do for me as an XPages developer?

Good question – let’s find out…

Well the first thing it showed me was how MASSIVELY complicated the Dojo integration with XPages is……check out some of these idTags on this Tab Container!! 😮

Dojo Firebug extension in action
Dojo Firebug extension in action

 

Open API documentation

This *could be* really useful – if you can get over how useless the API documentation site is – let me paraphrase…….IF you understand how the Dojo API documentation works this *could be* fantastically helpful…..

In my previous article on how I figured out how to use the Dojo Tab Container doLayout (where the screenshots come from) I was struggling to find out what I needed to make the Tab Panel heights dynamic. Would this have helped?….I was kinda bitter at this point as I figured it would have….so i soldiered on..

Select the tab container and look at the extension

Selecting open API documentation
Selecting open API documentation

 

and opening the API documentation

Dojo API documentation
Dojo API documentation

 

*yawns* – so not really – but stay with me

The next options *looks* more useful (so why did you show us the API link? Yes you guessed it…… it *is* ‘cos I hate you and I wanted to force you to look at Dojo API documentation – get over it and don’t ask daft questions)

Open Reference Guide Doc

Open Reference Guide Doc
Open Reference Guide Doc

 

Which shows you this…….

Dojo Reference Guide Documentation
Dojo Reference Guide Documentation

 

First of all I am really impressed that this actually links to the 1.8 version which was only released this week – but that is also not helpful because XPages 8.5.(What I am using) uses 1.6 so which a quite switch over on the right hand side

Switching to 1.6
Switching to 1.6

We get…

Aw Butts - really?/?
Aw Butts – really?/?

And I was just saying how awesome you guys were – CRAP.

As it turns out the plugin is too smart and not smart enough to detect 1) the version of dojo I am using and 2) that this feature it thinks I am using is available in 1.6…

DOH
DOH

DOH *grrr*

Que?

So I didn’t solve that problem but I did find another one – I noticed that IBM modified the Dojo specifically for the extlib!! …if you look at the code reference in the extension

Well that is kinda interesting I guess..
Well that is kinda interesting I guess..

[view:_id1:_id2:_id39:djTabContainer1 (Widget extlib.dijit.TabContainer)]

and when we select to go to the Reference Guide Docs – the URL it is sent to

http://dojotoolkit.org/reference-guide/1.8/extlib/dijit/TabContainer.html

You will see that extlib has been inserted into the URL

the REAL documentation is here

http://dojotoolkit.org/reference-guide/1.8/dijit/layout/TabContainer.html

dijit/layout and not extlib/digit.

If you look at an example from david walsh’s blog you can see the difference…

vive la difference
vive la difference

 

Anything else?

Well I found out how to manage FireFox profiles – http://www.howtogeek.com/howto/internet/firefox/use-multiple-firefox-profiles-at-the-same-time/ which is kinda useful – so I did learn something useful from this investigation.

There are a number of cool Dojo debugging capabilities if you are really into writing seriously with the dijits whereby you can subscribe to the data and watch it move all over the place – kinda cool – not helpful for XPage development though.

So is this really useful for an XPages developer?

Well I have to say from an purely educational perspective it is really interesting to get an insight into how the dijits work…

Some really complex cool stuff going on  in here
Some really complex cool stuff going on in here

 

But I think my overall impression of the extension is that it will not help an XPage developer develop their XPages at all in any sort of way

Shame really 😦

PS

Let me rephrase that last sentiment – I think this COULD be really useful if IBM were inclined to apply some time and effort to making a similar extension for XPages Dojo development – but isn’t the point of XPages is kinda so we don’t have to worry about Dojo…so it would be an uber-dojo-geek expert XPages developer tool only…meh…who wants to do that?? 😉

Shame really 😦

PPS

That is two blog articles in a row about dojo – don’t worry I am not going back to the dark side – jQuery still rocks my world 😉

jQuery in Xpages – development tip – using Firebug Console

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

typeAhead and ViewPanel
typeAhead and 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 😦
fail
fail

What happened?

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

jQuery object returned
jQuery object returned

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

Viewing the field through firebug
Viewing the field through firebug

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 😦

Too many Red DIVS
Too many Red DIVS

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 !
A Red field!
A Red field!

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>
CSS fail in IE
CSS fail 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.

jQuery CSS selector
jQuery in the firebug console
	<script>
		$("TABLE[id$='viewPanel1'] td:nth-child(3)").css('background-color', 'green')
	</script>
jQuery rocks around IE CSS support failure

 

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 !