Ajax Bestiary

Cross Site Scripting – the new old way

Dave Mahon — Tue, 20 Oct 2009 23:02:35 +0000

Cross Site Scripting (XSS) is a big security no-no. It’s never supposed to happen, because as we all know, any script operating within your page has full access to the entire DOM of the page.

Then again, there is so much functionality that we want to implement without reinventing the wheel. Marketing departments want to use third-party tracking tools. The IT folks want to distribute the load for our network heavy site across the third-level domains www.domain.com, static.domain.com and data.domain.com. And users want more functionality than we can hope to provide on our own.

So resigned to the reality that XSS is a legitimate necessity, we need a way to do it. The old way (as far back as the mid-90’s, in fact) was straightforward:



document.write(‘<script language=”JavaScript” type=”text/javascript” src=”http://data.domain.com/myscript.js”>’);

This is of course problematic as it treats DOM nodes improperly and may not even get processed by modern browsers. Instead, jQuery provides access to JSONP which will do the same thing – insert a new script node in the DOM – but do it in an XHTML compliant way.

Accessing JSONP is pretty straightforward:

$.getJSON("http://data.domain.com/myscript&callback=?”, inPageFunction);

The key bit is &callback=? – this causes jQuery to insert a script node into the DOM, which is then immediately executed and returned to the callback function, inPageFunction, like so:



inPageFunction({data:"foo";})

If you forget &callback=? you’ll get the error Access to restricted URI denied. And yes, since we’re inserting a script node, we’re limited to GET requests. And if the call fails, you’ll simply get nothing back – no useful error messages.

Further, the next generation of browsers is coming out with integrated support for cross site XMLHttpRequest, but since when have we not had to code to support multiple versions of browsers?

There are loads of good guides to expand your knowledge:

Using the jQuery data method as a local datastore

Dave Mahon — Thu, 15 Oct 2009 23:37:37 +0000

At some point, we all have to store datasets on the client. We can clutter the namespace with ever more variables and try really hard to avoid collisions. We can cram variables into some local object that we’re using in the normal execution of our script anyway. We can attach custom attributes to HTML nodes, violating the sacrosanct purity of XHTML.

Or we can attach the document-specific variables, in script (thus keeping those automated validators happy), to the document itself. This fairly intuitive approach has not been given the notice it deserves.

Some advantages:

Arbitrary value names can be assigned and we can basically assign as many of these variables as we want.
They can be applied to anything jQuery can access, meaning that we can rapidly assign values to entire sets of DOM nodes without having to add CSS classes or clutter the markup.
They can be dynamically added, accessed, changed and removed at will, without network transfers.

There is the disadvantage that they are not persistent across page loads, but we’ve lived with that problem for a long, long time, haven’t we?

So how do we use this handy method? The documentation is pretty clear cut, but I’ll give a slightly more grounded example:

My HTML is very simplistic in this example:

<body>
 <div>
  <span id="stats"></span>
  <button id="add">Add Data Point</button>
  <button id="reset">Reset Set</button>
 </div>
 <div id="data"></div>
</body>

The JavaScript is similarly intuitive:

appExample = {
 addDataPoint: function() {
  var dat = this.getDataSet();
  dat[dat.length] = Math.floor(Math.random()*101);
  $('#data').data('points', dat);
 },
 resetDataSet: function() {
  $('#data').removeData('points');
 },
 dataSize: function() {
  var dat = this.getDataSet();
  return dat.length;
 },
 getDataSet: function() {
  var dat = $('#data').data('points');
  if (undefined == dat) return [];
  if (Array != dat.constructor) return [dat];
  return dat;
 },
 updateDisplay: function() {
  $('#stats').text('Data Points: ' + (lim = this.dataSize()));
  var tmp = '';
  var dat = this.getDataSet();
  for (var i = 0; i < lim; i++) {
   tmp += dat[i];
   if (i < lim - 1) tmp += ',';
  }
  $('#data').text('[' + tmp + ']');
 }
}
 
$(document).ready( function() {
 appExample.updateDisplay();
 $('#add').bind('click', function(e) {
  appExample.addDataPoint();
  appExample.updateDisplay();
 });
 $('#reset').bind('click', function(e) {
  appExample.resetDataSet();
  appExample.updateDisplay();
 });
});

In this case, I’m storing everything as an array in points. While I’m storing randomly generated integers, you can just as easily store entire objects, opening the possibility of a JSON solution.

Note that we can identify those objects lacking the chosen dynamic attribute by calling it and testing for undefined.

The future of Ajax Bestiary

Don Albrecht — Thu, 08 Oct 2009 02:41:34 +0000

One of my colleagues pointed out the rather high ranking of Ajax Bestiary in his Net News Wire Dinosaur Report today. While 2nd place isn’t the worst possible ranking, It demonstrates that I haven’t posted anything in quite a while.

I’ve had the best of intentions to resume blogging, but time concerns and the high level of secrecy around my current projects have both pushed me away from regular blog updates. I’ll be making a bigger effort in the future, but I’ve also recruited a second author for the blog. David Mahon is a talented front-end web developer who has agreed to produce regular content for AB.

You can expect Dave’s first post sometime in the next few days.

Converting Between Wiki Markup & HTML with Prototype: Part 2 ListsAt

Don Albrecht — Fri, 19 Dec 2008 15:00:26 +0000

At the end of part 1 of the series, the system could easily handle direct replacement of certain html entities with their wiki markup counterparts. Unfortunately this was a pretty limited implementation that could only handle those entities that had a direct, symmetrical relationship with html. In the case of lists, we have to keep track of depth and better cleanup the input text. We also need to enforce default behavior on the input stream.

Since lists are dependent on dedicated whitespace as part of their markup, we need to clear out all unnecessary white space from the html before processing it. To do this, we simply replace all whitespace characters with an innocuous single space to remove any extra new lines.

$(textNode).innerHTML = $(textNode).innerHTML.gsub( '\s', '' );

Next we need to cleanup the recursion. Since we need to know significantly more about the given node to properly assess it. We can replace the Prototype templates with simple curried function calls and migrate the recursion to the curried methods.
var ConverterTable = { strong: Converter.curry("'''", null, true), b: Converter.curry("'''" , null, true), em: Converter.curry( "''" , null, true ), i: Converter.curry( "''" , null, true ), h1: Converter.curry( '=' , null, false ), h2: Converter.curry( '==' , null, false ), h3: Converter.curry( '===' , null, false ), h4: Converter.curry( '====' , null, false ), h5: Converter.curry( '=====' , null, false ), h6: Converter.curry( '======' , null, false ), ul: Converter.curry('', {li:Converter.curry(['* ', ''], null, false)}, false), ol: Converter.curry('', {li:Converter.curry(['# ', ''], null, false)}, false), p: Converter.curry(['','\n'], null, false) };
The parameters passed into the individual rules are
The Markup String or an array of strings for start and end tags
An optional library of child rules. These rules will be applied to any children of the given node before the default rules are applied.
An indication as to the ‘inline-ability’ of the given tag. This controls the bracketing of the resulting markup with ‘\n’ characters.

The modified Converter now looks to apply rules in the following order
If the node is marked as a stopping point, no recursion proceeds on the branch.
If any over-ridden child rules exist for the given tag, those rules are applied and a memo is passed on to child nodes to denote the depth of the recursion.
Any default rules are processed as per the earlier versions of the code. Note. A prototype template is no longer used in favor of simple string construction.
The node itself is removed from the DOM.

function Converter( markupString, nestedRules, inline, textNode, memo ){

var startString, endString;
inline = inline ? ” : ‘\n’;
memo = memo ? memo : ”;
var children = textNode.childElements();

if( typeof markupString == ‘object’){
startString = inline + markupString[0];
endString = markupString[1] + inline;
} else {
startString = inline + markupString;
endString = markupString + inline;
}

for( i in children){
if( typeof children[i] != ‘function’){
if( nestedRules && typeof nestedRules[children[i].tagName.toLowerCase()] == ‘function’){
startString = memo.strip() + startString;
nestedRules[ children[i].tagName.toLowerCase() ]( children[i], startString);
} else if( typeof ConverterTable[children[i].tagName.toLowerCase()] == ‘function’){
ConverterTable[children[i].tagName.toLowerCase() ](children[i]);
} else { Converter( ”, nestedRules, true, children[i]), memo }
}
}
textNode.replace( startString + textNode.innerHTML + endString );
}

Converting Between Wiki Markup & HTML with Prototype

Don Albrecht — Thu, 18 Dec 2008 15:00:07 +0000

Wiki’s are amazing and powerful tools, unfortunately their dependence on specialized markup creates a huge barrier to their general adoption in many organizations. This is a first step at building a wysiwyg editor for wiki markup. While I will be focussing on the syntax unique to the popular MediaWiki platform, these techniques should be applicable to any wiki system.

The general flow of the converter is as follows:

Converter is passed the root node of an html fragment to translate.
Converter recurses through each of the child nodes and converts them.
Root node tag is replaced with wiki markup.

There’s really only 2 key components involved in this first pass. A converter object and the recursive method.

The Converter Object

The converter object is little more than a collection of name value pairs. The name corresponds to an html tag. The value is a Prototype template to use in the direct replacement of the given node. By convention we’ll write all of the tag names for the converter object in lower case.
var Converter = { strong: new Template("'''#{body}'''"), b: new Template("'''#{body}'''"), em: new Template("''#{body}''"), i: new Template("''#{body}''"), h1: new Template('=#{body}='), h2: new Template('===#{body}=='),
h3: new Template(’===#{body}===’),
h4: new Template(’====#{body}====’),
h5: new Template(’=====#{body}=====’),
h6: new Template(’======#{body}======’) }

The Converter Function

The Converter function always performs 2 checks before attempting to convert a given node. First it ensures that the node is in fact a node and not a stray function from the Prototype enhanced object. Next it verifies that a converter exists for the tag. The toLowerCase() on the tagName is necessary due to the inconsistent behavior browsers demonstrate with this attribute. While all browsers return the variable in all caps for traditional html, they are not reliable about returning lower case values for xhtml markup.

function convertToWiki( textNode ){ //make sure textNode isn't a function on the object if( typeof textNode != 'function'){

//provide a way to stop execution on select sub trees if( !textNode.hasClassName( 'stop')){ $(textNode).childElements().each( convertToWiki ); }

//make sure a converter exists for the given tag if( liteConverter[ textNode.tagName.toLowerCase() ] ){

//replace the text node with a converted version of itself textNode.replace( liteConverter[textNode.tagName.toLowerCase()] .evaluate({body:textNode.innerHTML})); } } }

A Fast & Easy Prototype Based Curry

Don Albrecht — Wed, 17 Dec 2008 15:44:20 +0000

in Javascript the Good Parts, Douglas Crockford presents a simple method to curry functions. It’s a great tool that allows you to build functions with arguments predefined in them dynamically. In his implementation Array.splice & an indirect method declaration is used. In my version, I use prototype’s enhanced Array object & a direct call to the Function object to the same effect.

Function.curry = function() {
var args = $A(arguments), that = this;
return function() {
return that.apply( null, args.concat(arguments));
};
};

I’ve been using this method for a few months now in both its prototype & jquery forms and find it invaluable, especially when faced with a need to manipulate a large number of similar objects.

WysiHat Prototype Based Rich Text Editor

Don Albrecht — Tue, 21 Oct 2008 19:59:31 +0000

37 Signals has recently announced a new open source rich text editor built on protoype.

It’s a unique take on the Rich Text Editor that focuses on developers over the kitchen sink.

WysiHat is a WYSIWYG JavaScript framework that provides an extensible foundation to design your own rich text editor. WysiHat stays out of your way and leaves the UI design to you. Although WysiHat lets you get up and running with a few lines of code, the focus is on letting you customize it.

Check it out here:
http://github.com/37signals/wysihat/tree/master

And Read the announcement here:
Introducing WysiHat: An eventually better open source WYSIWYG editor

YUI Calendar Popup from Text Input

Don Albrecht — Mon, 20 Oct 2008 01:05:20 +0000

I needed a way to provide my users with a date picker that was automatically provided when a text area received focus. I was eager to use the excellent YUI calendar as a starting point, but the provided documentation didn’t provide a solid example for this type of implementation.

Dav Glass has provided a solid example of the Calendar tied to a text input. But, his example is highly dependent on the text input having specific ids. This doesn’t take advantage of YUI’s excellent Selector library really didn’t meet my need for a simple universal solution.

Key Requirements:

Progressive Enhancement (No inline javascript)
Yui based
Universal implementation across all pages in a site.
Support for multiple date inputs on a page.

Getting Started:

The bulk of the code used is pretty solidly Dav’s I’ve simply replaced all of the hard coded references to dynamically generated targets and moved from hard coded ID’s for the target fields to a css class. Lastly, I’ve added a “activeCal” class to the currently active target input so that one calendar can be recycled across multiple text areas on the page.

Source:


var cal1;
var over_cal = false;
function transmogCals() {
    cal1 = new YAHOO.widget.Calendar("cal1","cal1Container");
    cal1.selectEvent.subscribe(getDate, cal1, true);
    cal1.renderEvent.subscribe(setupListeners, cal1, true);
    var pickers =  YAHOO.util.Selector.query('.date-picker'); 
for( i in pickers){
    YAHOO.util.Event.addListener(pickers[i], 'focus', showCal);
    YAHOO.util.Event.addListener(pickers[i], 'blur', hideCal);
    }
cal1.render();
}
function setupListeners() {
    YAHOO.util.Event.addListener('cal1Container', 'mouseover', overCal);
    YAHOO.util.Event.addListener('cal1Container', 'mouseout', outCal);
}
function getDate() {
        var calDate = this.getSelectedDates()[0];
        calDate = (calDate.getMonth() + 1) + '/' + calDate.getDate() + '/' + calDate.getFullYear();
        YAHOO.util.Selector.query('.activeCal')[0].value = calDate;
        over_cal = false;
        hideCal();
}
function showCal(e, targ) {
    var xy = YAHOO.util.Dom.getXY(this);
    var el = new YAHOO.util.Element(this); 
    el.addClass('activeCal');
    var date = this.value;
    if (date) {
        cal1.cfg.setProperty('selected', date);
        cal1.cfg.setProperty('pagedate', new Date(date), true);
        cal1.render();
    }
    YAHOO.util.Dom.setStyle('cal1Container', 'display', 'block');
    xy[1] = xy[1] + 20;
    YAHOO.util.Dom.setXY('cal1Container', xy);
}
function hideCal() {
    if (!over_cal) {
         var el = new YAHOO.util.Element(this); 
        el.removeClass('activeCal');
        YAHOO.util.Dom.setStyle('cal1Container', 'display', 'none');
    }
}
function overCal() {
    over_cal = true;
}
function outCal() {
    over_cal = false;
}
YAHOO.util.Event.addListener(window, 'load', transmogCals);

Adding it to your page

Integrating the code into the page is VERY easy.

In the header of the page add the following css includes.

In the footer add the following script include and include the date-picker.js file

<script type=“text/javascript” src=“http://yui.yahooapis.com/combo?2.6.0/build/yahoo-dom-event/yahoo-dom-event.js&2.6.0/build/calendar/calendar-min.js&2.6.0/build/selector/selector-beta-min.js”>script>

Lastly, place a class of date-picker to any text fields you want to tie to the input and add the following to your pages markup:

Roll your own datagrid with prototype (part 1 the table)

Don Albrecht — Tue, 27 May 2008 16:40:08 +0000

Today I’m going to start a three part tutorial in implementing a custom datagrid with prototype & scriptaculous. In part 1 we’ll explore the html & css underlying the widget. Parts 2 & 3 will look at interactivity and legacy browser support (IE 6).

Disclaimer: this project is designed to work on IE 7 and later. It will not render properly on IE 6. We will look into that more with part 3.

So it starts with a table. Tables are much maligned nowadays. The focus is on semantic markup and creative uses of

and . In the energy behind css layouts over the past few years, the new markup elements available to the venerable table have been slightly overlooked. Sure the reign of table based layouts is over, but tables are now able to display data more semantically and style it more simply than ever before.

Here’s a traditional HTML table to start from.

Item Number	Description	Qty	Unit Price	Total Price
0023	Apples	3	.56	1.68
0057	Pears	13	.74	9.62
0137	Bananas	8	.31	2.48
0587	Kumquats	17	.26	4.42
0054	Oranges	3	.45	1.35
	Total	44		19.55

Item Number	Description	Qty	Unit Price	Total Price
0023	Apples	3	.56	1.68
0057	Pears	13	.74	9.62
0137	Bananas	8	.31	2.48
0587	Kumquats	17	.26	4.42
0054	Oranges	3	.45	1.35
	Total	44		19.55

It’s a decent start, but we can do better. First lets separate the body from the head with & tags. We’ll also replace the header cells with tags to denote their importance. We’re also going to add a set of row numbers. We’ll use for these as well to signify that they aren’t really part of the data (note the empty we added to the header to make everything stay consistent).

	Item Number	Description	Qty	Unit Price	Total Price
1	0023	Apples	3	.56	1.68
2	0057	Pears	13	.74	9.62
3	0137	Bananas	8	.31	2.48
4	0587	Kumquats	17	.26	4.42
5	0054	Oranges	3	.45	1.35
	Total	44		19.55

The specifies the header content. When printed, a browser should print it on every page the table spans. More importantly for us, it is a unique dom node we can grab for styling instructions. works in a similar way, It allows us to break the internals of a table into a set of segments. This will come in handy later. is a different beast entirely. I like to think of it as the ying to ’s yang. & are to

what

are to

: a semantic way to denote name / value pairs.

Now that our table has a header and a body, It’s time to give it a footer. We’ll do this by using the

tag.

At first glance, there is visually no difference between the 2nd and 3rd examples. Both of them look identical. The source, tells a different story. In the 3rd example, the footer row is actually ahead of the

in the source. This is the beauty of It lets us place the footer early in the table and cleanly separate it from the tbody that follows. It also guarantees that the appears last no matter what we append to the table via script.

All of this looks good, except it would be great if the columns were better styled. The two columns with financial data especially should be aligned left to ensure that the decimal points align. In a perfect world, we’d be able to do this with column groups, but that’s something for part 2.

A Rant For Reliable Documentation

Don Albrecht — Wed, 21 May 2008 13:36:18 +0000

I’m a javascript harlot and proud of it. I espouse no allegiance to any particular framework, widget or philosophy and pride myself n my ability to select the best tools for the job based on a project’s unique constraints. I find this puts me in a slightly unique position among developers. I don’t carry the deep and intimate details of the framework in my brain, instead I prefer to maintain a much shallower depth of understanding. I prefer road maps and traffic advisories to in depth aboriginal understanding.

This is why I was affected so severely by what seems to superficially be a minor inconvenience: the Scriptaculous wiki outage. Scriptaculous has already lagged behind prototype in its depth of documentation. This makes sense, after all, much of the heavy lifting and complex API’s are handled by prototype so an extensive documentation isn’t really necessary. For most developers, a few well executed demo implementations of the key features are all we need to get the job done. In fact, well executed demo implementations are especially critical for a framework like scriptaculous where many of the key features require complex implementation and are likely to be only used once or twice per project and not necessarily referenced day in and day out as the project comes together.

Last week, I was tasked to work on just such a feature. We new the type ahead find was straightforward to implement given the Scriptaculous documentation. We also knew that it was fundamentally gravy. Sure, the feature was important to the end product and would mean much of the difference between user frustration and adoption, but It was also significantly less important than some other items like successfully storing to the database, authentication and form processing. In short, we put it off to the end as I’m sure many developers would.

Unfortunately, the documentation was gone when we needed it. The wiki outage had hosed the Scriptaculous hosted media wiki instance and the page we needed was simply missing from the new system. During a several minute minor panic we tried the various internet archives and similar sites in a desperate attempt to find a new solution with negligible success. Eventually we found the documentation we needed.

To Scriptaculous’s credit it was in a surprisingly logical place and well done. Turns out that scriptaculous has wonderful self documentation as part of the functional tests / unit tests suite. These test files provided us with solid demonstrations of features we were looking to use for this project.

There’s no doubt in my mind that a software component’s single biggest asset is its documentation. This is as much a feature as an ultra-fast query selector or smoothly transitioning widget. Scriptaculous provides powerful documentation in a slightly unlikely place but doesn’t provide decent bread crumbs to its existence from the frameworks public site. Given the critical nature of such documentation, It would be nice if it integrated in to the public site or atleast minimally referenced as a resource.