the long path of unittesting JS in Plone (in Jenkins of course)

One of the main goals of Mockup (the new JavaScript story for Plone) is to unittested.

Before Mockup there was no systematic way to unittest JavaScript, you could only do some really slow integration tests via Robot Framework (with its Plone integration plone.app.robotframework).

Now with Mockup he have the other side of the coin as well: we can not only check how the code  integrates within Plone but we can also check its logic with fast unittests.

There’s already Travis integration for Mockup and Mockup-core (a building block for Mockup), but as Plone is using Jenkins it makes a lot of sense to run them there as well.

So, how that’s done? I’m glad you ask, exactly like this:

  1. Add Nodejs on Jenkins nodes (plone.jenkins_node)
  2. Configure Jenkins so that tests will find where Nodejs is (plone.jenkins_server)
  3. Configure Grunt (a JavaScript test runner) for Jenkins (mockup-core)
  4. Add a make target for the new Grunt configuration (mockup)
  5. Create a Jenkins job that runs it (jenkins.plone.org)
  6. Profit!

All the code is there, the last three pull requests are pending to be merged.

Once that’s done jenkins.plone.org will be able to run our JavaScript unittests!!

Happy hacking!

P.D: remember that tomorrow is WPOD!

On javascript events

One thing that always get on my nerves with Javascript is that it was a pain (until today for me) to get from an HTML element to the actual javascript that runs once you hover, click, etc that element.

I’m a visual kind of guy so my rationale was:

  • I see a button on a webpage that does something that smells like javascripty
  • I open firebug and select that element
  • I expect to have some kind of panel/hint about the events that are registered for that element without success :S

Today, tired of it, I start looking for a solution, and I found an amazing one, let me introduce you visual events 2!

It’s a bookmark that you place on your browser and if you click on it the page gets blue rectangular overlays on all elements that have a javascript event handler!

But not only that, if you hover over one of those boxes you will see what I was expecting from the beginning: the code that is executed and where it lies (which file and line).

Brilliant!

mostrar o amagar les traduccions

logotip del GNOMEdesprés de dinar no sabia què fer i m’ha picat el cuc hacker i m’he decidit a tancar el l’errada #106779 :)

moltes, moltes, moltes hores després he aconseguit que totes les peces encaixin i ara per fi ja he pogut enviar un pedaç que afegeix la funcionalitat d’amagar o mostrar les traduccions que ja estan al 100%

per fer-lo m’he basat en l’enllaç que hi havia en l’últim comentari de l’errada, però el problema era que no s’havia de commutar un o tots els elements de les llistes, sinó que uns i prou

de manera que m’he tirat dels cabells navegant per Internet fins que he trobat una manera fàcil i còmode:

  • primer de tot es defineix un identificador a cada una de les dues taules (la de documentació i la de interfície gràfica [1])
  • seguidament a partir d’aquests identificadors agafes els elements tr d’aquestes taules i els passes per un bucle
  • en el bucle l’únic que has de fer es comprovar si tenen un identificador que acabi amb -complete[2] i si es dóna el cas fer un (obj).style.display = ‘none’ o (obj).style.display = ”
  • evidentment, perquè això funcioni, fa falta posar-hi els identificadors quan es generen les pàgines

tot i que és molt millorable, si s’aplica aviat i es posa en els servidor en producció (el l10n.gnome.org) anirà que ni pintat ara que ja falta menys d’un mes per al llançament del GNOME 2.22 :D

[1] realment no caldria fer-ho així i es podria fer directament amb tot el document de cop, però com que les pàgines son prou grosses així la consulta al DOM es més curta

[2] i això és possible gràcies a que disposem d’expressions regulars a Javascript!