Dynamic Variables Assignment?
In JS, I ran into a problem where I needed to create a shortcut string, and then turn that string’s value into a reference to a different object.
So for example, I create a string called ‘oliver’ under the variable shortcut like so:
var shortcut = 'oliver';
Then I have a bunch of other code in my framework, and to access any of it, I would write something like:
FRAMEWORK.doSomething();
I wanted the framework’s name space to be preserved (so that I could easily upgrade/update it without affecting any code), but I wanted to be able to use my shortcut handle to access the framework, such that writing the following would work as well:
oliver.doSomething();
This led me to the use of eval to run a js command in js itself to get the assignment/reference working properly like so:
eval(shortcut+' = FRAMEWORK');
This worked really well and met exactly what I was trying to do, but I’m always hesitant to use eval. I’ve heard terrible things about it’s security and performance (although most ajax is based on this function). I’ll look into it and update the post if I find anything, but for the mean while, this has helped me do what I was trying to. It allows me to write really general client side framework code that can then be extended easily into a new namespace without any conflicts. Very powerful stuff.
When I search for it on google, it didn’t come up right away. My search terms (hopefully writing this in the post will help someone else) were: dynamic javascript variable assignment.
ps. The picture is supposed to represent a ’shortcut’. not the best fit I don’t mind saying.
Update: window[name] = reference is the winner. I don’t know why it escaped me before. This should prevent the use of eval and will allow you to dynamically create variables in the window scope.
Mootools caveat #2: noCache in new Request() is your friend
Reading the docs is really worth it’s weight in gold. Namely, noCache option/parameter for a new Request (aka. Ajax for mootools) object really does make all the difference in the world.
“noCache – (boolean; defaults to false) If true, appends a unique noCache value to the request to prevent caching. (IE has a bad habit of caching ajax request values. Including this script and setting the noCache value to true will prevent it from caching. The server should ignore the noCache value.)”
I was having a problem with ajax being ‘retrieved’ by IE, but not actually making a hit in my access log. I was baffled, and figured it was a caching issue, but confused since safari/FF were working fine.
For those of you out there, be aware of this. My specific problem was actually based on a call to something like:
http://www.website.com/controller/action/
Now I can make that exact url call and have it return a bunch of html; but for the framework I’m working in, adding a header of AC:true (short form for ‘Ajax Call’) will change the output (namely, to a JSON object instead of pure html). It seems IE was caching the request since the page had been requested without the header, and then returning it every time.
Damn you IE!!!!! I understand <link /> and <script /> and <img />’s being cached, but XHR’s? Come on. They’re based on actions (eg. click events, mouse overs, key combinations), not default behaviors of a page load (ordinarily).
Mootools caveat: event.target is not extended by $
This took me wayt too long to discover:
When using event.target via mootools event handlers, I figured out, after way too much testing, that event.target is NOT extended via $, and therefore doesn’t have accessors like .get(’tag’) and default’s for the $ (dollar sign extension).
I wasn’t sure if this was note worthy of a post, but I reckon I’ll fill this up with enough keywords that it’ll hopefully show up in the SERP’s for mootools event trigger target source, etc.
We shall see.
Script/Asset abuse: this is getting ridiculous!
Frameworks like YUI, JQuery, Mootools, Dojo, etc., are arguably the best thing to have happened to JavaScript in 10 years. I remember when I first learned about their existence. I was coding my own animation script (functional, not OO, and definitely not efficient) that didn’t do anything fancy; just scrolled up and down. I remember then hearing about dojo, and thinking I’d wasted so much time.
Then what I did, was go around to all the different frameworks. I don’t even think JQuery existed in it’s current incarnation at that point (December of 2005), and I looked around at as many as I could (dojo, mootools, and a few others that have since become relics). This post though, isn’t about the greatness of these frameworks; rather it’s about the terrible abuse.
With any new technology, there will be people who embrace it for ease of use and creating a new standard, and then there will be those who completely abuse it. The screen shot below is a perfect example of that (click it for the full size):
If you can’t see what I have a problem with, then you need to leave this post right now. For everyone else, this is an absolute joke. This is for a travel promotion site called StudentCity. My count of javascript assets: 20 (excluding any dynamically load ajax/jsonp requests). My count of css assets: 11.
These tallies were retrieved via after the DOM had been rendered, so they may not match up perfectly with the source, but I assure you they’re accurate.
If you visit this site, you’re not going to notice too much. A few swfs, a bit of animation, and a few non-css related hover effects. In no way, should this account for the number of requests for just js/css assets. It doesn’t make sense, and is terrible programming/development. I understand that in many projects, control is sometimes non-existent. You need to conform to someone elses demands, some other developers tendencies, or some other designers inexperience. But for the firm who developed this site, if anyone had taken a look at the source after it had been finished, a huge red flag should have gone up.
Concatenating files is easy; minimizing requests is easy, and a faster client side render time will actually make you money, for a relatively low cost (maybe 2 hours). This speaks to what frameworks are doing these days.
JS frameworks, and even php/server side ones like CakePHP and CodeIgniter (ones I’m working with now) are leading to a generation of websites and applications that were developed by people who have very little idea what they’re doing. I don’t think it’s much different than the age of Frontpage/Dreamweaver/GoLive developed sites, but it’s certainly not something that you should be paying for it you’re working with a development firm. It’s annoying as a developer to see this, and probably a do-or-die thing if I were to be working with or hiring another developer to work with me.
JSONP vs JSON: amazing for API’s
I was doing some search and found http://ajaxian.com/archives/jsonp-json-with-padding as well as http://ajaxpatterns.org/On-Demand_Javascript
My reason for searching was I was trying to understand why some developers use the term JSONP vs JSON. JSONP standards for JSON with padding. The padding is supposed to give the JSON a little more flexibility. Let me try to convey in my own words the benefit.
JSON is a great storage format for browser community (and even further than that, db storage, but that’s for another post). The problem is, with AJAX (terrible name considering XML is hardly ever used; standing for Asynchronous JavaScript and XML), the method for deploying techniques is no longer just the XHR object. It can now be deployed via dynamically written <script /> or <link /> tags. You can write to the browser something like:
<script type=”text/javascript”>
[{'wtf':'yo'}]
</script>
This is a json object, and while I use the format exclusively for ajax calls that use XHR, cross domain requests using the <script /> and <link /> tags are becoming more and more common. It’s one of the easiest ways to get by the cross domain restrictions set up by browsers (which I think is being alleviated in the next ECMA/JavaScript release, btw), but the issue with just spitting back JSON is it doesn’t do anything. Ya, it gets added to the dom (sort of), but it’s not even assigned to anyone; my object [{'wtf';'yo'}] exists, but is basically in limbo. This is JSONP’s territory now.
Let’s say that JSON string is accessible via olivernassar.com/wtf-yo/
As it stands right now, it’d be spitting out JSON, but if we modified the API to accept a uri such as:
olivernassar.com/wtf-yo/?callback=doSomething
And returned:
doSomething([{'wtf':'yo'}]);
That’s is JSONP. You can imagine all the possibilities. I’ve been using it for some time via google/yahoo/facebook API calls, but I never knew the name. I sort of assumed it was a technique that didn’t have a name, just a reason. But I suppose client side development needs a name for everything. Too many techniques to keep track of otherwise.
I’m not sure the usefulness of JSONP will be felt by man. If you’re developing, like most people, internal systems that aren’t meant for outside usage (eg. api’s) then you can get away with JSON responses via XHR, but the second you cross into the territory of allowing other people access your data via a client side or server side/xml api, JSONP becomes really flexible and powerful, yet easy to implement.