Posts tagged JavaScript

This week has been one of tidying up loose ends. LUNA has had several minor HTML and typo fixes, and is currently undergoing a bit of JavaScript development wizardry to let users select their location during registration. JSON data from the server encodes how rooms, apartments and blocks are organised which is then extracted by the magic of jQuery into something usable. I’ve got the basics working (and the full thing if I generate a lot of unnecessary files), now it’s just a bit more work on extraction of arrays from within the JSON.

In other LUNA nonsense, working out which combination of technical features to use to let people provide feedback on Phase 2 changes (the compulsory anti-virus and anti-malware) is proving challenging and may lead to a new server being temporarily put together just for handling the feedback. I’m going to push for a LAMP stack, but since Lincoln is a Windows shop I’m not holding my breath.

Finally, balls are rolling on my posters project – a meeting for scoping and specification is booked where key parties can bang heads together until we get something reasonable before I begin doing hardcore implementation stuff.

Now, back to JSON.

During the saga of getting Print from My PC working, I had to build some pages to help people set the whole thing up. Predictably, this included clobbering some HTML and CSS around (and for the record, I still hate ASP with a burning passion).

Online Services already has an online ‘look’ which is visible on the Gateway, which seems to be used wherever possible. The trouble is, the entire layout and design is based on some very old HTML and CSS (and an inexplicable reliance on JavaScript, which I’ll ignore for now). Each individual subset of the online services provided by the University has a subtly different stylesheet and a different way of doing things, so for Print for My PC I decided to mostly scrap the existing code and start from scratch.

The result is visually almost identical, although in a few places it sports crisper lines and cleaner finishes. However, behind the scenes the CSS is smaller, faster, slicker, more standards compliant, provides better support for assistive technologies, makes greater use of flexible positioning and so on. There’s a ‘standard’ stylesheet to provide the unified look, and then an individual ‘tweaks’ stylesheet for some PFMPC specific colour adjustments. Finally, PFMPC makes use of some common JavaScript scripts to handle the nice lightbox effect for popup images.

Why am I blogging about this? Well, firstly this is a blog which in part aims to let you look behind the scenes at what’s happening. Secondly and most importantly, however, the code is specifically designed to be incredibly portable between various services. I envision there being yet another subdomain (sorry!) such as, which exists purely to store objects shared by all services. The stylesheets, the images, the scripts. The result once properly implemented would be ultimately beneficial – it would improve caching, reducing hits to services. It would enforce consistent appearance. Applying a code or styling fix would need to be done once and would be replicated to all services using it. Finally and most importantly, it would get people into the mindset of “data should only exist once” which is a key part of the Web 2.0 way.

Still, mindless code changes for such a minor improvement would be senseless. Which is why I’m going to suggest the following: create, add the resources to it, and when new services are created or services are updated make them use the common resources. It’ll be slow, but it’ll be worth it.