I love Firebug, and I’m getting so I understand jQuery pretty well.

I often drop into the console and type in jQuery commands to figure out how to get things to happen on a page. For example, I was looking at a really long page of search results from Taleo that lists out all of my submissions for jobs at CACI. The problem is, that it shows the fully active submissions with the inactive ones, so it’s not very useful for figuring out what I need to follow up on.

 

So it occurred to me that if I could just write a couple lines of jQuery to look for the items that include “Active” in them, I could reduce this list in a way that would be meaningful for me.

So the first thing I did was go look at the page HTML to figure out whether there was something on the page I could use to separate out each row on the search page.

 

 

 

I fired up Firebug by right clicking on one of the items and choosing “Inspect in Firebug”.

 

 

 

 

 

 

 

 

 

 

This starts up Firebug (if it isn’t already showing) and took me to the part of the HTML that I was looking for:

 

 

 

 

 

 

So now I knew I needed to look for something that had a class of “iconcontentpanel” that contained the text “Active”.  I decided to outline it with a green dashed line, so my jQuery looked like:

So I flipped over to the Console in Firebug and tried running that:

 

 

 

 

 

But that gave me an error since there is no jQuery on the original page. But there’s this nifty little thing in the console that says “jQuerify”, and clicking that injects jQuery into the page:

 

 

 

 

 

 

So now that jQuery is available, running the script again gives me what I was looking for:

 

 

 

 

 

 

 

And of course I can add even more jQuery to strip out unwanted parts of the page, change format, etc, leaving me something that is more  actionable:

Enhanced by Zemanta

Recently I’ve been doing some web page work again, and trying to push the envelope on my CSS knowledge.

I was at a talk at 360|iDev where Brian Fling was talking about UI design, and he pointed out that your site should work without your CSS. Now while I know this as a design principle, it seems like something that we probably overlook more often than not.

So, out of curiosity, I thought I’d take a look and see what some of my pages look like without their stylesheets applied.

The first trick is Firefox with Firebug.

Firebug is a plugin that lets you debug and examine the contents of a page and do very interesting things, like modify your page on the fly. By loading up Firebug on one of my sites, it was an easy thing to browse to where the stylesheets are loaded. To start up Firebug, I normally just right click on the page and choose “Inspect Element” from the popup dialog box, or use the Open Firebug option from the Tools menu:

right click menutools_open_firebug

Once you have Firebug open, you can browse your HTML to where the stylesheets are loaded (normally in the HEAD section of your page):

Firebug looking at header

The next trick is that with Firebug, you can change everything

In the above example, I have two stylesheets loading: a basic one (basic.css) and one for print layout (print.css). So to look at my site without the stylesheet, all I have to do is right click on the link that loads the sheet, and choose Delete Element:

delete element

Third trick: debugging missing link includes with Firebug is cool

One interesting thing to note, if you expand the link node, you’ll see the complete style sheet as it was downloaded from the server. I’ve found this very handy in finding issues like a typo in a stylesheet name, or a misconfigured server (which is very easy to happen with frameworks like Cake), since what displays is the actual return from the server (so for instance if you mispell the name, you’ll see the actual 404 file missing):

404 error

Once you’ve removed the link (or even change the name to a bad one as I did above), you’ll see your bare bones HTML, just like it would appear to a browser without styles. If your page was designed correctly, it should have basic navigation links at the top of the page instead of the menu bars, which make the site usable for a browser that isn’t using your stylesheets.

Jc no style

Next: starting a new page so that it works with and without style …

I ran into an odd problem with the way Cake is coded that tripped me up for a couple of days. Because I hate it when things don’t work the way I think they should, I spent way more time debugging this than anybody should.

I got my basic RESTful service working for the VolunteerCake project, and everything was working swimmingly, until I needed to turn on debug to figure something out …

When I had the debug level set to less than two (2) calling the action I was interested in with an extension of “.xml” was working fine. I got back the XML representation of the data in the action I was interested in returned with content-type of “application/xml”. In Cake, if you turn debug to 2 (or 3) it will dump out the SQL that was run in an HTML table.

The problem is that this HTML table is actually spit out  after the rest of the view, meaning that my RESTful service no longer has a well formed document to display. Additionally (for reasons I’ve yet to isolate), when this happens, the document is returned with a content-type of “text/html” instead of “application/xml” as expected. Neither of these things would be acceptable if the site is to provide web services, since it would mean the web services would be broken as soon as somebody needed to debug.

The workaround for this is to manually reset the debug level when the extension of “xml” is detected. Since the debug data is useful, and it’s just the SQL that appears to break the XML, I asked on the IRC channel what the last place I could set the debug might be. The suggestion was to put it either in the afterFilter, or the end of the view itself.

I found that if I put the following code into the beforeFilter method, I could prevent the problem with the price of losing my debug output:

That same code placed in the afterFilter method gave me the debug output in a well formed XML document (excluding the SQL table), as did placing it in the view itself. This leads me to believe that when debug > 1 there is some code that happens after the beforeFilter that is not setting the content type to “application/xml” as would be expected from our routing rules.

Being the bulldog that I am, I dug into the Cake source code to see if I could figure this out. I found the spot where the SQL table was being built, which turned out to be in the showLog() method of the dbo_source.php, which is called by the close() method. Since the close() is called after the view is finished, and the showLog() method simply prints the data, that explains why it breaks the XML. It definitely breaks the MVC encapsulation, since the data gets dumped into an HTML table and spit out after the view is complete.

On the IRC channel, it was suggested that I try creating a data source that would override the showLog method and spit that table out to a table, which might be worth trying.

I posted my question on the CakePHP Google Group and got the useful suggestion to use the FirePHP plugin which basically writes the log data to the FirePHP plugin so it can be displayed in FireBug. So my approach will be to write a dbo_mysql_firephp.php class that does just that. This will at least resolve the MVC encapsulation issue and keep my view relatively clean.

I still want to figure out exactly why the content-type isn’t getting set properly, but for now I have a workaround that I’ll use, and I’ll add the FirePHP debugging to solve the well-formed XML issue if I ever do figure out the content-type problem.

Off to set up my FirePHP plugin and build the dbo class now …

Enhanced by Zemanta