Feature patches: improved $x, new $X and fixed makexpi

[Johan Sundström]

I've upgraded Firebug's $x to handle an optional context node and to
be sensitive to the result type. I also threw in a convenience $X I've
found convenient to no end (it returns the first match only), and
fixed the broken build script (the ant build script is still broken,
by the way, but I don't speak ant).

Net effect 1: you can use relative xpaths, for instance pick a node
with the inspector and pick some node relative to that.

Net effect 2: whether you're on a site with some wacky frame
configuration or not, by supplying a context node (for instance by
clicking it with the inspector and using $0) you can use $x to find
stuff in the neighbourhood.

Net effect 3: you can ask for count(), substring() and similar and get
numbers, strings or booleans back instead of an array of nodes.

An example use I'm quite fond of is to pick a node anywhere in any
page with the inspector and find the closest linkable anchor above,
which is good, for instance if you want to bookmark some comment on
broken blogs like Ajaxian that don't provide any clickable links for
that. That looks like this in the console:

location.hash='#'+$X('string(preceding::*[@name or @id][1]/@id)',$0)

Patches attached.

--
/ Johan Sundström, http://ecmanaut.blogspot.com/

[Johan Sundström]

Any chance we could see this feature migrated to 1.1 too from 1.05?

It's the only thing I miss from 1.05 in 1.1 and holding me off from
recommending peers to upgrade, as the 1.1 Net monitor is a great
improvement for Greasemonkey scriptwrights (since it reacts to its
GM_xmlhttpRequest:s, which 1.05 did not).

There is a ticket http://code.google.com/p/fbug/issues/detail?id=18 on
it, and I could probably retarget the patch to the 1.1 branch if it
would help getting it there, but I assume it's on hold for some other
reason.

[John J Barton]

Johan, can you explain what this feature is, I've not used it.

John

[LightGuard]

Has anyone else had the need to use namespaces with their XPath? I
had a need a while ago, and created a patch, but it doesn't look like
anyone else has come across this. If it's not needed, I guess there's
really not much of a point for the patch.

[Johan Sundström]

On Sat, Feb 23, 2008 at 2:50 AM, John J Barton
<johnj...@johnjbarton.com> wrote:
> Johan, can you explain what this feature is, I've not used it.

Certainly. The DOM XPath API, while powerful, can't be blamed for
being typing efficient, nor delivering useful javascript data types,
and the Firebug's commandline shorthand $x addresses both; a little in
Firebug 1.0 (and 1.1), and a lot in Firebug 1.05.

To be precise, 1.0/1.1 takes a single parameter (the XPath
expression), and always returns an Array, regardless of what the XPath
result -- usefully of Nodes, when the result was a NodeList, less
usefully the empty array, when the result was not.

1.05 improved on this behaviour by allowing two parameters, the second
being an optional context node (third argument to document.evaluate)
from which to resolve the expression, and by returning javascript
basic types matching the result of the expression -- an Array of
Nodes, when a NodeList, or a string, number or boolean, when executing
expressions like $x('string(//a[1]/text())'), $x('count(//a)') and
$x('count(//a) = 12') respectively.

1.05 also added $X, being a light wrapper around $x that returns a
non-Array basic type of whatever $x returned; the first match, in
effect, or null, if none, so you needn't test for length and index out
[0] before being able to use the value when you wanted a node.

I miss all these three features severely in 1.1.

LightGuard then attached another, largely unrelated, orthogonal change
to also add the possibility of adding a third namespace resolver
parameter to either function, so you can use $x / $X with xhtml
documents too, but the details of how to use it are foggy to me as
xhtml served as xhtml is still a rather rare sight on the net (I can
only name http://intertwingly.net/ off the top of my head). It is
unclear to me whether the convenience level of his suggested variant
is on the same convenience level as the other $x features (or indeed
if they can even be made so at all; xml with namespaces has never
seemed to bestow anyone anything but pain in my experience, but I am
probably one of the unenlightened heathen in that department :-).

--
/ Johan Sundström, http://ecmanaut.blogspot.com/

> On Feb 22, 4:51 pm, "Johan Sundström" <oyas...@gmail.com> wrote: