You are viewing a read-only archive of the Blogs.Harvard network. Learn more.

Avoiding Page Reloads

December 4, 2012 — JaZahn

My applications are part of a framework (LMS) that load a billion extra items on each page load.

To get around it I wanted to do that silly “twitter thing”. They’re the ones who get credited with it because for years normals were baffled by their url changing.

http://www.adequatelygood.com/2011/2/Thoughts-on-the-Hashbang

Additionally, if you’re interested in why the bang(!) is necessary, it’s not. It’s just to tell google to index the page. Otherwise they assume it’s just an anchor link.

https://developers.google.com/webmasters/ajax-crawling/

So I spent the last few hours changing all links in one of my current applications to do a “hashbang” sort of call instead of loading new pages. This significantly increased speed when using our clunky LMS.

This was especially annoying because our LMS forces changes with <a> tags.

What made this especially easy to implement was that I had already made all links go through a smarty plugin so altering all links in the application was just in one file and I could make those links specific to whatever authentication scheme / LMS the application is living in. So I just had to alter that plugin and the LMS specific layout and bam. The only thing that’s not covering is form submissions. But there are only a couple of those, so I’m not going to stress about that.

In continuing research obviously I had to investigate why twitter moved away from hashbangs.
http://engineering.twitter.com/2012/05/improving-performance-on-twittercom.html

The highlight of that being that with hashbangs, you have to go to the client and then back out, which reduces speed on the initial pageload. So twitter went a little fancier 6 months ago and used the history api’s PushState.

Implementing the hashbang urls was a very small amount of code, so I’m going to move forward with that for now, maybe next time I get a chance to do some research I’ll focus on converting that to PushStates.

Posted in ATG, Javascript, Quizmo. Tags: , , , . 2 Comments »

Using Smarty variables inside Javascript

May 28, 2012 — JaZahn

I looked for appropriate answers for this on the smarty site, and the resounding answer was escaping javascript’s {}s with {literal}’s

Smarty template vars and Javascript functions
How to use Javascript codes in template files?
Access Smarty value with javascript

They basically all say to do something like this:

// $question_ids_json = ["1","2","3","4","5"]
{literal}
<script>
$(document).ready(function(){
	var question_ids = {/literal}{$question_ids_json}{literal};
	
	alert(question_ids[0]);

});
</script>
{/literal}

So they want to put everything in a literal tag, and then basically escape that literal tag when smarty needs to be used.

I didn’t like this, so I put the value in a hidden input and then just retrieved that input in the javascript, thereby keeping the js clean of smarty shenanigans:

<input type="hidden" id="question_ids" value='{$question_ids_json}'/>

<script>
$(document).ready(function(){
	//var question_ids = {$question_ids_json};
	var question_ids = eval($('#question_ids').val());
	
	alert(question_ids[0]);


});
</script>

But this is just a matter of personal preference.

Posted in ATG, Javascript, PHP, Quizmo, Smarty. Tags: , , , , . 4 Comments »
«
»