As a Software-as-a-Service for online event registration, however, we face the dilemma of separating out potential customers of our SaaS app and their customers who come to our site to also participate in the marketplace. For every event organizer who visits our site and might be interested in using our system, hundreds of event attendees come to get registered. Including the Hubspot tracking code on our home page makes our traffic numbers look great but has the negative side effect of dropping our lead and conversion ratios well under 1%. Ignore for a moment that this is demoralizing, it also makes reports difficult to use. Picture comparing the success of a landing page with 0.05% conversions and another with 0.07%. They both look effectively equivalent because of the scale but if those numbers instead read 50% and 70%, you would not only be impressed but recognize the latter is performing 40% better!

One option here would be to simply remove the tracking code from the home page and that would fix the statistic and volume issues. But we would lose important referring data. While Google is no longer giving us much in the way of search keywords, we still can see referring URLs when people surf to MotorsportReg.com. If we removed the tracking code from the home page and cookie’d them when they hit the About Us page, we would lose that original traffic source.

So, the challenge began to find a way to cookie the people who were potential leads and do it on the home page so we could capture referrer data. I asked our sales guy, our onboarding rep and customer support. Nobody had any idea how to segment the traffic to weed out the event attendees from skewing our data.

But I had an idea, and it turns out it works pretty well.

What I want to know, specifically, is when someone views our “How it works” or another marketing/sales page as that indicates interest in our SaaS product. I started by tagging all links in the top and bottom navigation that link to our marketing and sales pages with a CSS class like:

< a href="/about" class="hs">How it Works< /a>

On those marketing pages, we include the Hubspot tracking code on every view. But for the home page, I wrapped it inside of a jQuery click handler:

$(document).ready(function()
{
// dynamically load hubspot code only if someone clicks a marketing-related link on the home page
$('.hs').click(function(e)
{
var anchor = $(this), h;
h = anchor.attr('href');
if (typeof _hsq === "undefined")
{
e.preventDefault();
$.getScript('//js.hubspot.com/analytics/'+(Math.ceil(new Date()/300000)*300000)+'/{your-hubspot-id}.js', function(){
setTimeout(function(){window.location = h},1000);
});
}
});
});

The code basically says: if someone clicks a link with the class “hs”, grab the link they clicked, load the Javascript file from Hubspot’s servers, wait 1 second, and then continue to the original link. In the 1 second while we sleep, the code should load from Hubspot’s servers which results in the user getting cookie’d appropriately and Hubspot can still access the referring URLs, search keywords, etc.

This approach is not only limited to Hubspot. It would work equally well with any Javascript-based tracking code like Google Analytics or others if you had some reason to exclude certain users from participating under certain circumstances.

It’s not perfect – the one second pause is too long in some cases, not long enough in others, and adds a delay in all cases which can increase page abandonment. However, we’ve been using this in production now for about 3 months and it’s been working well. Lead volume is slightly up despite the brief delay and we see the full browsing history for contacts in Hubspot. Our lead and traffic numbers are now properly scaled so we can make sense of the data we’re seeing.

If you have multiple audiences viewing your site and only want to apply tracking to some of them, this technique is worth taking a look at.

Two huge thumbs up: take a look at this jQuery table grouping demo.

If you’re using TableSorter 2.0.3 or 2.0.5 from 2008, take a look at Rob’s version today.

What does this have to do with jQuery? Well, while I’m waiting for a database dump in the background to finish downloading so I can extract some data, I whipped up a UI enhancements with a few lines of jQuery that might help someone else:

Highlight table rows with checked checkbox in a column

What if we highlighted the selected rows when the confirmation dialog pops up? It would be one more way of pointing out what is about to happen. Here’s what it looks like now:

In conjunction with Dan Switzer’s qForms library…

objForm.onSubmit = function() {
	// only ask for confirmation when they change more than 1
	if (objForm.uid.getValue().indexOf(",") != -1)
	{
		$('input[name="uid"]:checked')
			.parents('tr')
			.css('backgroundColor', '#fc0');
		var res = confirm('You are about to make a batch change in registration status.\n\nAre you sure you want to continue?');
		if (!res)
			$('input[name="uid"]:checked')
				.parents('tr')
				.css('backgroundColor', '#fff');

		return res;
	}
	else
		return true;
};

The checkboxes are all named “uid” so when it’s submitted to the server I get a list of IDs to work with. I’m using jQuery to select all of the checked checkboxes named “uid”, then get their parent <tr> tags and then update their backgrounds to be a bright gold color while the confirmation dialog asks them if they’re really, really, seriously sure they want to do this. If they click cancel, we restore the background back to white.

My download is about done, so time to restore!

Cue FlowPlayer and a short plugin I wrote. FlowPlayer is pretty impressive… it’s a SWF and a JS file you drop into your site and it leverages the jQuery built into Codex. If you want to use it in conjunction with Codex, you can use my plugin below. The wiki syntax looks like:

{{{ev url="http://url/to/your/movie.flv"
         height="300"
         width="400"
         alt="My alternate text description"
         splash="http://url/to/a/static/splash/screen.jpg"}}}

That code will give you a player that looks roughly like:

This was my first plugin for a Coldbox application and it was pretty easy to take an existing one and create another. It’s also the first Coldbox application I’ve worked with and so far I’m pretty impressed. I am looking at giving it a test drive for a mini app I have to build later this month for club elections and surveys.

Just drop this into your codex/plugins/wiki directory as ev.cfc. The way I’ve written the code, you can have multiple players per page as they’ll all be tagged with a class “flowplayer”:

< !-----------------------------------------------------------------------
********************************************************************************
Copyright 2009 by Brian Ghidinelli (https://www.ghidinelli.com)
********************************************************************************
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
********************************************************************************
$Build Date: @@build_date@@
$Build ID:	@@build_id@@
********************************************************************************
----------------------------------------------------------------------->
<cfcomponent name="EmbedVideo"
			 hint="A wiki plugin to embed video using FlowPlayer"
			 extends="codex.model.plugins.BaseWikiPlugin"
			 output="false"
			 cache="false">

< !------------------------------------------- CONSTRUCTOR ------------------------------------------->	

    <cffunction name="init" access="public" returntype="ev" output="false">
		<cfargument name="controller" type="any" required="true">
		<cfscript>
  		super.Init(arguments.controller);
  		setpluginName("EmbedVideo");
  		setpluginVersion("1.0");
  		setpluginDescription("A video embedding plugin that uses FlowPlayer");
  		setPluginAuthor("Brian Ghidinelli");
  		setPluginAuthorURL("https://www.ghidinelli.com");
  		setPluginURL("https://www.ghidinelli.com");

  		//Return instance
  		return this;
		</cfscript>
	</cffunction>

< !------------------------------------------- PUBLIC ------------------------------------------->	

    < !--- today --->
	<cffunction name="renderit" output="false" access="public" returntype="string" hint="This plugin will embed a video on the page using FlowPlayer">
		<cfargument name="url"  required="true" type="string" hint="The url to the video to display" />
		<cfargument name="height" type="numeric" required="false" default="300" />
		<cfargument name="width" type="numeric" required="false" default="400" />
		<cfargument name="splash" type="string" required="false" default="" />
		<cfargument name="alt" type="string" required="false" default="" />

		<cfset var event = getController().getRequestService().getContext() />
		<cfset var content = "" />

		< !--- use a jquery onready block --->
		<cfoutput>
		<cfsavecontent variable="content">
			<cfif len(arguments.splash)><img src="#arguments.splash#" height="#arguments.height#" width="#arguments.width#" alt="<cfif len(arguments.alt)>#HTMLEditFormat(alt)#<cfelse>Click to start playing</cfif>" /></cfif>
			<script language="javascript" type="text/javascript">
				$(document).ready(function()
				{
					flowplayer("a.flowplayer", "/js/flowplayer/flowplayer-3.1.2.swf");
				});
			</script>
		</cfsavecontent>
		</cfoutput>

		<cfreturn content />
	</cffunction>

</cfcomponent>

The Setup

Development server at dev.domain.com. Off-site developer building an application on his laptop and connecting his AJAX/xmlHttpRequest calls to dev.domain.com.

The Problem

Browsers restrict cross-domain requests for security purposes. So Javascript at http://localhost can’t retrieve data from a remote API like http://dev.domain.com. In Firefox + Firebug, you would see the following:

Error: uncaught exception: Permission denied to call method XMLHttpRequest.open

There is a hack for Firefox but that doesn’t help you with IE, Safari or Chrome. We started out this way but when it came time to deploy we found issues with Safari and Chrome.

These were things we could have detected much earlier in the development cycle had the Javascript developer been able to test in those browsers. It was a big mistake on our part to delay the cross-browser testing and it’s a testament to the stability of the Ext components that we didn’t have 10,000 other issues.

The Solution

If you’re developing with Apache, the answer is quite simple actually: use a reverse proxy. Apache’s mod_proxy will take a request for something like “/foo” and actually tunnel the request to some remote destination like “http://dev.domain.com/bar”. The end result is that your web browser thinks you’ve made a call to http://localhost/foo but in reality you’re sending and retrieving data from a remote server. Security implications solved!

I searched for a long time but never found an intersection between AJAX development, cross-domain xmlHttpRequest restrictions and Apache’s mod_proxy. It wasn’t until I thought, “hey, that might work” and started searching specifically for reverse proxy details did I turn up an example.

Apache Configuration

This is a pretty basic Apache feature – first you will need to load the required modules:

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule rewrite_module modules/mod_rewrite.so

Let’s assume that I want to access a file at http://dev.domain.com/remote/api.php. You would put all of the following into a <VirtualHost>:

# start mod_rewrite
RewriteEngine On

ProxyRequests Off
<Proxy>
	Order deny,allow
	Allow from all
</Proxy>

ProxyPass /apitest/ http://dev.domain.com/remote/api/
ProxyPassReverse /apitest/ http://dev.domain.com/remote/api/
RewriteRule ^/apitest/(.*)$ /remote/api/$1 [R]

Restart Apache and make a browser request to http://localhost/apitest/api.php and you should receive a response from the remote server at http://dev.domain.com/remote/api/api.php. The RewriteRule will pass along any query-string parameters too. Done!

If you use IIS instead of Apache, you should be able to do something similar with ISAPI_REWRITE to accomplish the same functionality. This is also applicable to other technologies like Adobe Flex or Flash which also have cross-domain restrictions.

The advantage over other solutions like a vanilla proxy server or server-side script that translates the request for you is that it requires few, if any, changes to your code. It’s also payload-agnostic so it will work with any number of remote services without care for the request or response format.

There’s one final tweak we could make so our development environment mirrors our staging and production servers. If the final endpoint for the Javascript will be:

http://dev.domain.com/service/foo?var=value

Then we could use the same relative URL “/service/foo?var=value” and make our reverse proxy mirror that structure:

ProxyPass /service/ http://dev.domain.com/service/
ProxyPassReverse /service/ http://dev.domain.com/service/ 

Now there is no change necessary in the Javascript; just make your request to “/service/foo?var=value” on either localhost or dev.domain.com and the browser will be properly routed to the right destination without running into any security restrictions!

SerializeJSON encodes numeric values as floats so 0 becomes 0.0, 1 becomes 1.0, and so on. The solution is to pass the combobox a string (‘0′) instead of a number (0). While JavaCast and other techniques failed, it is possible by putting a leading space on your numeric value:

<cfset records["someValue"] = ' 0' />
<cfreturn serializeJSON(records) />

The result is {“someValue”: ” 0″} which Javascript (or at least Ext’s combobox) handles just fine. Nice little trick to have in the toolbox when you need to treat numeric data like strings.

1. Extraneous whitespace being returned
2. Content-type was understood by Firefox, meaning it was potentially insecure
3. Keys were all being forced upper-case which is plain ugly.
4. Integers are being represented as floats which is a feature, not a bug (see comments at bottom)

To solve these problems, I used Coldspring’s aspect oriented programming (AOP) and wrote a custom around advice that I applied to my remote proxy to better control the JSON formatting for the client.

jsonAroundAdvice.cfc

The following Around Advice eliminates the built-in ?returnFormat=json support in a remote CFC in favor of more explicit conversion:

<cfcomponent output="false" name="jsonAroundAdvice" extends="coldspring.aop.MethodInterceptor">

<cffunction name="invokeMethod" access="public" returntype="any">
	<cfargument name="mi" type="coldspring.aop.MethodInvocation" required="true" />

	<cfset var record = structNew() />

	<cftry>
		<!--- just pass results straight through --->
		<cfset record = arguments.mi.proceed() />

		<cfcatch type="any">
			<cfset record["data"] = "Serialization failed" />
			<cfset record["result"] = false />
		</cfcatch>
	</cftry>

	<!--- control output, forcing json --->
	<cfset URL.returnFormat = "plain" />
	<cfheader name="Access-Control" value="allow <*>" />
	<cfcontent reset="true" type="application/json"><cfreturn serializeJson(record) /><cfabort />

</cffunction>
</cfcomponent>

Basically this code takes any results from the actual method that was called and creates a Javascript object with two keys, data and result, that are serialized and returned with a proper header. We set the URL.returnFormat = “plain” so we can override any parameter passed by the user to the method. Note that we can use the CF8 SerializeJSON method or we could use Epiphantastic’s CFJSON.cfc. Only the latter, in my experience, will solve the decimal formatting of integers (#4 in my list above).

Coldspring Configuration

To complete the example, this is the Coldspring configuration required to set up my remote proxy:

<bean id="jsonAroundAdvice" class="model.aop.jsonAroundAdvice" />
<bean id="jsonAdvisor" class="coldspring.aop.support.NamedMethodPointcutAdvisor">
	<property name="advice"><ref bean="jsonAroundAdvice" /></property>
	<property name="mappedNames"><value>*</value></property>
</bean>

<bean id="remoteFormService" class="coldspring.aop.framework.RemoteFactoryBean" lazy-init="false">
	<property name="target"><ref bean="formService" /></property>
	<property name="serviceName"><value>remoteFormService</value></property>
	<property name="relativePath"><value>/myMapping/myDirectory</value></property>
	<property name="beanFactoryName"><value>cs</value></property>
	<property name="interceptorNames">
		<list>
			<!-- run in reverse order; or think of first being "around" second being "around" third -->
			<value>jsonAdvisor</value>
			<value>authorizationAdvisor</value>
			<value>authenticationAdvisor</value>
		</list>
	</property>
	<property name="remoteMethodNames"><value>*</value></property>
</bean>	

Note that I have more than one around advice here. Coldspring evaluates them from the bottom up so jsonAdvisor is “around” authorizationAdvisor which is “around” authenticationAdvisor. I have them stacked like this so I can reuse authorization/authentication in other remote proxies as well.

Formatting

One thing I didn’t like about CF8’s SerializeJSON() is that it changes your data slightly (as compared to JSON.cfc). Take for example the following structure:

str.camelHumpName = "Some Value";
str.NumericValue = 52;

SerializeJSON translates that to:

{"CAMELHUMPNAME": "Some Value", "NUMERICVALUE": 52.0}

That’s kind of goofy although the case issue is consistent with how the structure functions treat your key names. Because CF is not case-sensitive, we can still refer to them with our normal mixed case. Not so in case-sensitive Javascript-land. You can get around the upper case keys by using a slightly different structure notation:

// maintains mixed-case key in json serialization
str["camelHumpName"] = "Some Value"; 

// when quoted, value remains an integer (52) rather than a float (52.0)
str["NumericValue"] = "52"; 

This structure produces the following JSON:

{"camelHumpName": "Some Value", "NumericValue": 52.0}

Mashup Controls

You might have noticed the line above that read:

<cfheader name="Access-Control" value="allow <*>" />

This is a new header used to better control XSS attacks that is understood by Firefox 3’s XHR implementation. You can control which web sites can and cannot request data using this header.

There we have it. A couple of tricks and tips for building AJAX applications using ColdSpring’s RemoteProxyBean and AOP!

Sorting alphanumeric data in numeric order

I have member numbers which can look like ‘A23423423′ or ‘2000-342′ or ‘220342BMW’ but I want to sort them in numeric order since the characters often refer to associate members or some sub-qualifier. It takes a pretty simple parser with a regular expression to accomplish it:

$.tablesorter.addParser({
id: 'memNumber',
is: function(s) {
return false;
},
format: function(s) {
return s.replace(/[^0-9]/g, "");
},
sorter: 'numeric'
});

Adspeed Parsers & Widgets

I also came across a recent post over at Adspeed.org that includes several parsers and widgets:

1. Parser for sorting values like “$1,300.50″
2. Parser for sorting values like “2 months ago”,”3 years ago” (actual timestamp hide in the comment)
3. Parser for sorting values like “SMALLER”,”SMALL” (actual text value hide in comment)
4. Widget to highlight a row when mouse hovers it
5. Widget to highlight a header when mouse hovers it
6. Widget to save/memorize sort order via AJAX

I particularly like the idea of embedding the sortable value in a comment and using that to sort. It gives you total freedom in how you display versus sort (and could work just as well as my custom member number parser above).

You can write your own parsers and widgets easily to extend TableSorter for your own requirements.

There are two things that I like about this plugin in particular:

1. Full support for keyboard input
2. Designed to handle a lot of data

I have been working with RIAs for a long time, trying to bridge the gap between the power of desktop applications and the distribution model of web applications. When trying to build data-heavy applications, we were regularly disappointed by either the lack of design for lots of data or the poor performance experienced once we exceeded a sample screen of data. I’m glad to see more emphasis on this type of performance at the requirements gathering phase.