Hi MAMA

MAMA (Metadata Analysis and Mining Application) is Opera's structural
search engine that reviewed over 3.5 million URLs (pages); whereas
normal search engines return results about the content of pages, MAMA
returns results about site structure, including what doctype the page
uses, whether it validates, what HTML elements and CSS properties it
uses, what plugins, what scriping constructs, and much more. This is
an invaluable tool for many individuals and companies involved in our
industry, and Opera wants to share it with everyone -- so I'm going
to help with a link. Here's their key findings

http://dev.opera.com/articles/view/mama-key-findings/

This is brilliantly useful information.

Problem: Multi-Domain Shopping Cart

How does one create a shopping cart system that crosses domains?

The basic problem looks like this: I want to create a shopping cart
system that will retain it's state across multiple websites that
don't have the same root domain. For example: www.rnsoft.com and www.rssdreamfeeder.com and www.rssreplay.com and www.socialink.us -- all different domains. They don't even share a common root, so a
cookie-based system couldn't be shared.

I've been pondering this problem for a while. I figured I'd ask the
assembled masses and see what ya'll think. I'll be writing more on
the solution I've been cooking up later (it involves a mix of
javascript, ajax and php), but I'd really like your feedback because
I'm not sure my crack-pot scheme will work.

Thanks everyone.

JavaScript textContent vs innerText

OK JavaScript fans, this week's tip isn't so much a tip as a nod and link to the guys over at CoderLab. 

I was having problems last week with innerText -- the property of DOM nodes that capture the text without the HTML tags. And I was having this problem with Firefox and no other browsers. And that just didn't make sense to me. Sure, if it has been IE I'd have called it par for the course, but I just wasn't expecting it from Firefox.

Anywho, as it turns out, Firefox 1.5 uses the textContent property instead of innerText even though the DOM standard says innerText. Great move guys.

At any rate CoderLab wrote about this one back in April of 06, but I only just found a need for it this past week as I was finishing SociaLink. Here's the link to CoderLab:

http://blog.coderlab.us/2006/04/18/the-textcontent-and-innertext-properties/

Showing Attributes with For Each

So I have been working further with my development frameset and adding attributes to the object that I am building to control social bookmarking on a web page. There are over 24 different attributes and I may have to add more. I'd like to see what they all are when I run a test and I'd like the flexibility to see any new ones I add without having to add new code to the testbed.

As it turns out, its not actually that hard to do with current JavaScript (though early versions of JavaScript didn't support this).

I have added a DIV block to the page called "showattrs" and that's where I'm going to drop the output of this little script.

<div id="showattrs"></div>

Then I've written a simple function that accepts an object as its parameter and uses the for each loop to go through the elements within the object.

function showattrs(theObject) {
   var out="<pre>"
   for (var attr in theObject) {
      out+=attr+":"+ theObject[attr]+"\n"
   }
   out+="</pre>"
 
   var block = document.getElementById("showattrs")
   block.innerHTML=out
}

This works with objects or associative arrays -- which are essentially the same thing in JavaScript. Now I just call this function after I make my changes and update my display.

showattrs(sclSociaLink)

I added the pre tag to it to make the text monospaced just because its my preference for codey stuff.

Now, I know its called a for each loop, but the word "each" doesn't actually show up when coding this (it does in some other languages). The line

for (var attr in theObject)

can be read as

for each attr in theObject

I think its important to be able to read code in english. It helps to clarify thinking and makes debugging much easier. By the way, if you don't already know, var is just for making the variable attr a local variable.

So this will show all the attributes and in some browsers it will also show the code to any methods you have defined for your object. In all browsers it shows them in order of definition. So as a rule I define my methods after my attributes. This makes sure that I will see the attributes first, and then the methods.

Also, this is a cool spelling error capture. How often have you typed object.attrivute instead of object.attribute. It just happens. Well if you have done this you will now notice that attrivute is within the list. I just copy it (copy so I don't mistype again) and the do a global search on my code to find where I made my mistake.

Happy coding.

Development Frameset

So I've been working on a JavaScript tool that will control the linking and display of an element on a web page. The content will be generated by the script and will naturally be dependent on parameters passed and properties of objects. And just like any script its got to be tested in lots of web browsers.

Eventually I'll be using document.write to place the content onto the page, but while developing the page I change the innerHTML of a div within the page. That also means that when I change the settings I can regenerate the block and see if everything is working. Now some people might ask why not just stick with innerHTML instead of document.write, but this approach will allow me to have no impact on the layout if JavaScript is disabled and to have multiple of these elements within a page if needed. Some coders might think document.write is antiquated, but I believe in using the right tool for the job, even if they are a little well-worn.

<div id="show"></div>

var block = document.getElementById("show")

block.innerHTML=generatedElements

Now as I am working on this I want to be able to change the attributes of the object that controls the display. One easy way to do this is to add controls. I could add them to the same document, but then my test document becomes less reflective of the documents that will hold the code in the end. Also, my test document has to meet some requirements -- for example, it has to be a template-based document -- and I didn't want to mess that up.

So what I did was make a frameset with controls on the left frame and my test document on the right. Now I can enter exactly the parameters that I want to test and see the results immediately.

What makes this a little slicker is that I named each form element that controls an attribute "atr_XXXX" where "XXXX" is the name of the attribute to be modified within the object. Now I simply cycle through the form's elements and modify the object's attribute with that name (I use eval to make is simpler). And because its in another frame I have to poke at it with parent.rightFrame. I think it works really well.

function Update() {
  if (parent) {
     var l=document.theform.elements.length
     for (var i=0; i<l; i++) {
        if (document.theform.elements[i].name) {
           if (document.theform.elements[i].name.substring(0,4)=="atr_") {
              var out='parent.rightFrame.sclSociaLink.'
              out+=document.theform.elements[i].name.substring(4,
                   document.theform.elements[i].name.length)
              out+="="+document.theform.elements[i].value
              eval(out)
           }
        }
     }
     parent.rightFrame.showTestbed()
  }
}

HTML Comments and JavaScript

So lets say that you want to get at the comments within an HTML document. Why, you ask, would that be useful? Well for several reasons. Perhaps you have settings, variables, or other things within comments that you would want to gather for processing. Perhaps you have trained your website maintenance staff to put identification information (like the day the page was last updated) within comments.

But if you're a Dreamweaver user comments can contain things like where the start and end of template regions are. That's no small thing, so I want to say it again. Web pages built based on Dreamweaver templates will have little HTML comments in them that identify where the beginning and end of an editable region is -- like this:

<!-- InstanceBeginEditable name="PageContent" -->

<!-- InstanceEndEditable -->

These are just comments, just like any other comment. They don't impact that layout or rendering of the page in the web browser. They're just there to provide a little meta information.

Now lets say that you want to grab the headline of a page -- but it could be styled any number of ways. If the page is based on Dreamweaver templates one approach could be to grab the relevant editable region.

If you read the DOM documentation you'll discover that there are node types called comments. So you might think that you could follow the DOM tree and look for nodes with the right type.

node.type== Node.COMMENT_NODE

The problem is that support for this is spotty even in the best browsers. For the most part, it looks like comments are simply removed from the page before it is processed. You can see that there are no comments within the document's html code -- check your favorite browser.

document.body.outerHTML

Before we can even being to figure out how to read the comments, we have to find them. As it turns out you can do it by using document.documentElement. The complete pre-processed html for the page, including comments, can be found by looking at

document.documentElement.outerHTML

Now all you have to do is match the comment using a regular expression or a couple of indexOf statements. Whichever method you prefer or understand better. *

exp="<"+"!"+"--"+"([\\s\\S]+?)"+"--"+">"

rexComment=new RegExp(exp)

Moreover, the really big win is that you can identify data based on its placement within a template. That's really important. Templates are built to control the display of content within a website to make the pages consistent -- sure. But they allow flexibility so editors can change only the parts of the page that are relevant to theri work -- headlines and bylines and stories. So naturally, if we're interested in the parts of the page that are about the content, then we'll be interested in the stuff that's in the template regions.

This really expanded my way of thinking about templates. They're not just about pretty -- they're about data structure.

* A Note on "exp="

You'll notice that I broke the expression apart into pieces -- that's to avoid any browsers biting on the comment tag if it were all together as one piece. This

exp="<!--([\\s\\S]+)?-->"

is the same as this

exp="<"+"!"+"--"+"([\\s\\S]+?)"+"--"+">"