5

I'm trying to store a reference of an HTML tag for later reuse.

e.g. If I click on a div and save a pointer to that div within Javascript, will there be a way I could serialize such pointer? So I could de-serialize it and use the pointer in another instance of the web application?

Only methods I can think of are the following:

  • Use id or name attributes

  • Create a CSS selector for that element

Any other ideas guys? =)

RadiantHex
  • 24,907
  • 47
  • 148
  • 244

9 Answers9

4

You could try generating an XPath string for the element - the more complex the string, the more accurate and portable an identifier it will be.

For example, a simple element-only XPath query string would not be very unique, and likely to re-occur:

'//html/body/div/div/p/strong'

Factoring in all attributes might be overkill 

'//html/body[@onclick="somereallylongjavascript" and class="nosidebar"]/div[@id="wrapper" and @class="posts"]/div[@class="entry" and @id="firstentry"]/p[@class="first"]/strong'
But you could probably find a nice middle-ground by limiting to certain attributes, maybe just to IDs: 
'//html/body/div[@id="wrapper"]/div[@id="firstentry"]/p/strong'

You can retrieve XPath natively in all browsers. There's the W3C method:


var myElement=document.evaluate(
  XPathstring,
  document,
  function(ns){return{'html':'http://www.w3.org/1999/xhtml','':null}[ns];},
  9,
  null
).singleNodeValue;

(the ns function is purely if you need application/xhtml+xml support)

The IE method is more simplistic but less flexible:

var myElement=document.selectSingleNode(XPathString);

Creating the XPath string is a different issue of course - there are various options, none native unfortunately. XPather is a moz add-on that provides an interface that does this - its source is MPL-ed and relatively simple but is probably more than you need. There are various shorter scripts available that provide simpler solutions.

Edit: Justin Johnson has provided a link to an SO answer containing a VERY short XPath-generating function. It's a bit simplistic, it uses odd id notation (id(blah) instead of [@id="blah"]) and doesn't toLowerCase() its tagNames which could impair portability, but other than that it looks perfect for your needs.

lucideer
  • 3,842
  • 25
  • 31
  • Thanks!! this is actually a version of what I was thinking. This is an excellent reply and I thank you very much!! I think I might tick this one =) – RadiantHex Jul 23 '10 at 18:43
2

What exactly are you trying to save? And where exactly are you re-using it?

A DOM element would be very specific to that particular browser rendering on that page -- Just hitting refresh will give you an whole new DOM element. So, what about it do you need to save & recreate?

James Curran
  • 101,701
  • 37
  • 181
  • 258
2

How about the innerHTML of the element?

R. Hill
  • 3,582
  • 1
  • 20
  • 19
  • 1
    It could be an empty element, or a repeated one. This would also be quite inefficient as it would involve searching the entire document for strings each time. – lucideer Jul 23 '10 at 16:29
  • Well, I don't know *exactly* what he wants to do, but this does match *serializing* an HTML element, what he asked -- although of course it's out of question to "reuse" the "pointer" itself. From the answers I see here, it seems many interpreted his question as "serializing the reference to an element", instead of "serializing the element itself." – R. Hill Jul 23 '10 at 16:37
  • He's requested the ability to "de-serialise and use as a pointer", so its evidently a reference. He's also given examples of using an ID, or a "CSS selector" - both references. – lucideer Jul 23 '10 at 16:45
  • Thanks guys =) I guess innerHTML would be an accurate way of trying to serialize a pointer. I'm starting to think though that I could store the tree structure of the page using tag denominations, and then just store some kind of selector for each element. – RadiantHex Jul 23 '10 at 18:42
0

Only logical way is to use id.

It is ussually not hard to assign id to all important elements based on database values.

st78
  • 8,028
  • 11
  • 49
  • 68
  • problem is that not every click-able element is guaranteed an id. So I reckon that building a css selector based on common attributes would be more efficient. e.g. class href src tag ... – RadiantHex Jul 23 '10 at 16:10
  • I would limit user to select only from elements which has logical item under it. I am starting to understand your problem - you are building tool which must work with general html. – st78 Jul 23 '10 at 16:23
  • @RadiantHex You can't retrieve CSS selectors in javascript without using some hackish algorithm or heavy JS library - neither efficient. XPath on the other hand is supported natively in every browser and is extremely fast. – lucideer Jul 23 '10 at 16:34
0

I've tried something like this:

{tag:"div", style:"float:left;", "class":"fancy", inner:[
  {tag:"a", href:"http://google.com", inner:"A link to google!" },
  {tag:"a", href:"http://yahoo.com", inner:"A link to yahoo!" }
]}

Seems to work okay, although it's easy to get lost with all the curly brackets.

edit - maybe I completely misunderstood what you want... if you want to serialize a handle to that element, like what would be returned by getElementById, you might as well just use the id.

Dagg Nabbit
  • 75,346
  • 19
  • 113
  • 141
0

It looks like JSON.stringify( yourDivReference ) and JSON.parse( serializedObjectString ) might do what you're looking for.

UPDATE: Actually, the JSON methods don't like the circular references in the DOM. See this question for more details: How to serialize DOM node to JSON even if there are circular references?

I do, however, agree with Sergey that using the ID seems like a better way to go.

Community
  • 1
  • 1
Sean McMains
  • 57,907
  • 13
  • 47
  • 54
0

Based on the way you worded your question, I don't think that would be possible. What exactly do you mean by "another instance of the web application"? Since JavaScript will be running on the client side, you won't be able to share data between clients. However, you might want to do something like store/read from a database. Can you describe more of the functionality you are trying to achieve?

Eric Levine
  • 13,536
  • 5
  • 49
  • 49
0

XPath seems to be the most appropriate; however, only if the page structure is (relatively) static up to that node. Here are some references and code:

Method for getting the xpath of an arbitrary node and example use

getPathTo($("a")[4]):

yields

"id("hlinks-custom")/A[2]"

MDC XPath documentation

Community
  • 1
  • 1
Justin Johnson
  • 30,978
  • 7
  • 65
  • 89
0

Another idea - to generate own custom id's for all elements based on some rules:

  1. element id starts from parent id. -> customid = "body/item"
  2. If normal id is available use it. if not, use element type. Than add order in current subtree.

so, you will get something like "body-0/item-0" for example above or "body-0/div-4" if id is not known.

When you will try to use your "custom id" and page will be changed, you will have a chance to find closest element, comparing all elements custom id to stored "custom id".

st78
  • 8,028
  • 11
  • 49
  • 68