Well, I have implemented a very simple demo of the first steps. So far, the script only makes sure to add some extra text to the current selection when ever the mouse button is released (which is how most users select most text) and it only works in Firefox (tested in 3.6). Next steps include making the link direct to the actually selected content, record text copying in Google Analytics, add cross-browser checks etc.

The script is published under the same license as these ideas, CC-BY 3.0.

Why?

Copy-paste is another quite common way of interacting with websites and allowing people to easily spread the word about your website in a new way ensures you credit where such is due. Creating a full-featured jQuery-plugin from this should be fairly easy and then making sure it integrates with Google Analytics if present – and then we’re actually done.

What’s next?

Do with this idea whatever you like – expand, implement, trash or forget. Just remember, that if you use it in anyway make sure to attribute me according to the Creative Commons Attribution 3.0 License, that all these 365 Social Ideas are published under.

Related posts:

1. Social Traffic Analyzer – January 2010 Ideas
2. Comment On Everything – January 2010 Ideas
3. App Idea Store – January 2010 Ideas

1. Setup
2. Direct children
3. Descendants
4. Conclusion

I was playing around with E4X last night working on an upcoming blog post about the capabilities of E4X. While playing, I was thoroughly reading the ECMA-357 standard, and found that there are some special rules about assignment and compound assignment, that produce truely unexpected results.

I will try to summarize common pitfalls and provide valid work-arounds.

Setup

This post will for most examples work on the following document:

var e:XML = <employees>
	<person>
		<name>John</name>
		<age>35</age>
	</person>
	<person>
		<name>Joe</name>
		<age>25</age>
		<hobby>Swimming</hobby>
	</person>
</employees>

Sometimes other documents will be used explicitly.

Direct children

How would you go about changing the hobby of Joe to running? Well, we could traverse all the way to the node:

e.person[1].hobby = "Running";

This of course works as expected. Actually, we ought to be able to skip the index [1], as only the second person has a hobby and thus only this node ought to be the target for the update:

e.person.hobby = "Running";

But no, this throws a runtime-error:

TypeError: Error #1089: Assignment to lists with more than one item is not supported.

But it is not a list with more than one item, is it?

trace(e.person.hobby.length()); // traces 1

The issue here (I expect, I had a hard time figuring out what the spec actually said about it) is, that the second-to-last list in the assignment target has more than one item:

trace(e.person.length()); // traces 2

This can be tested by introducing some extra level of nodes and try to update one of these:

var more_nodes:XML = <employees>
	<person>
		<name>John</name>
		<age>35</age>
	</person>
	<person>
		<name>Joe</name>
		<age>25</age>
		<hobby>
			<primary>Swimming</primary>
			<secondary>Sewing</secondary>
		</hobby>
	</person>
</employees>
trace(more_nodes.person.length()); // traces 2
trace(more_nodes.person.hobby.length()); // traces 1
trace(more_nodes.person.hobby.primary.length()); // traces 1
more_nodes.person.hobby.primary = "Running"; // no error, updated as expected

Voila, it works. What this means is, that the error is not related to the actual XMLList, that you are assigning to – but to the XMLList, that is the parent of this in the statement. We could actually have reached the desired result by adding an extra level to reach the text node inside the (single) hobby node:

e.person.hobby.* = "Running"; // no error, updated as expected

In this case again, the second-to-last XMLList (the target object for the assignment) has a length of 1, and the update can be accomplished.

Descendants

But if we really just wanted to update the single hobby, that we know only one of the employees have, then we would normally try:

e..hobby = "Running";

Now things start to get really interesting. Because, what happened? No error was thrown, but the document after this update looks like:

<employees>
  <person>
    <name>John</name>
    <age>35</age>
  </person>
  <person>
    <name>Joe</name>
    <age>25</age>
    <hobby>Swimming</hobby>
  </person>
  <hobby>Running</hobby>
</employees>

That is, the existing hobby was unchanged, but a new hobby node has been appended to the end of the outermost node? The statement works the same, as if I had just written:

e.hobby = "Running";

Which would do exactly that – create and append a new hobby node to the outermost node and set its text value to “Running”. But the two lists aren’t identical in the original document:

trace(e..hobby.length()); // traces 1
trace(e.hobby.length()); // traces 0

But again, assignment to xml (and xmllists) does not really have to do with the last part of the assignment target but the penultimate. And again, adding an extra level to reach the text node(s) works:

e..hobby.* = "Running"; // no error, and this time updated as expected

Why the previous statement seemed to ignore the descendant-part of the statement, I’m not really sure. Could be a bug, could be a loop-hole, but it definitely does not make sense.

There are many other ways to reach the same list of the single hobby node when simply consuming, but they cannot all be used in the same way when updating:

e..*.hobby = "Running"; // throws the same Error #1089 about more-than-one element lists
e..*.hobby.* = "Running"; // and it works again
 
e.descendants().hobby = "Running"; // throws the same Error #1089 about more-than-one element lists
e.descendants().hobby.* = "Running"; // and it works again
 
e.descendants('hobby') = "Running"; // compile-time error
// the parser simply does not allow assigning to a function invocation
e.descendants('hobby').* = "Running"; // and it works again
 
e..*.(localName()=='hobby') = "Running"; // compile-time error
// the parser simply does not allow assigning to (what looks like) a function invocation
e..*.(localName()=='hobby').* = "Running"; // and it works again

Conclusion

Be aware that assignments to XMLLists does not care about the last list – it is the second-to-last list, that must contain only one value. Internally, a statement like:

expression.property = value;

Is not a new thing at all, but it is handled in a new, special way, when expression has a value of either XML or XMLList. Thus, if you either get compile-time errors, runtime-errors or nodes appended in completely wrong places, just add extra level of element traversal with the wildcard-identifier .* to reach the text node of the single node you want to update.

No related posts.

Before even testing whether implementations are conformant and/or where their differences lie, I will try simply to list all implementations.

It is noteworthy, that while LibXML (like many other libraries) is based on libxml2 (which in itself does not implement either traversal nor range) LibXML has a partial implementation of DOM2 Traversal.

If you know of any other implementations of DOM and particularly implementations of either traversal or range, please comment.

References

Some of this has been found simply by googling, some has been found through the DOM bindings list and some found at Wikipedia about DOM comparison. Finally I found this list of DOM software, which has many other open or commercial implementations, that I will have to look through – many of them seem to use one of the above-mentioned, many only support DOM1, but the list might add some relevant implementations.

Related posts:

1. ccTLD’s for second-level foreign registration