cazmockett.com

The Why and Which of JavaScript Libraries

John Resig took us through various scenarios when you write JavaScript:

• Plug & Play:
  Drop in a widget, little or no JavaScript knowledge required, just customise some options and go - no flexibility
• Some assembly required:
  Write common utilities, use pre-made code to distance yourself from browser bugs - flexible, until you hit a browser bug
• Down and dirty:
  Write all code from scratch, deal directly with bugs, quirksmode can save your life - eccessively flexible - almost too flexible
• Use JavaScript library:
  Makes JavaScript bearable, gets the job done fast, simplifies cross-browser support - easily customisable

John then did a comparison between the various JavaScript libraries, including jQuery, Prototype, YUI and Dojo, which are commonly in use. A developer survey showed that jQuery and Prototype were used by around 32% of developers; YUI was 22% and others around 14%.

John’s full slides give much more detail of each library’s strengths.

John’s presentation: slides (slideshare) | audio (mp3)

Professional Front-End Engineering

Nate Koechley

Nate began by giving us a bit of historical context to the way Yahoo! has evolved over the years.

He then covered topics such as Yahoo’s server architecture, graded browser support [see below], progressive enhancement, unobtrusive JavaScript etc.

He suggests we all have an interesting set of decisions to make regarding front-end design:

1. Do what is standard
   if impossible, then
2. Do what is common
   if impossible, then
3. Do what it takes

Then we get on to:

1. Do what is simple
   +
2. Do what is flexible & progressive
   +
3. Do what is open

This is in order to satisfy the multiple audiences for any website: Users, Developers, Machines.

At Yahoo!, they focus on 8 specific areas:

1. HTML
2. CSS
3. JavaScript
4. Accessibility
5. Internationalisation
6. Performance
7. Infrastructre & Process
8. Tooling

They use tools such as JSLint to check code for quality, and adopt the idioms it promotes to improve their code. Also, unit testing with YUI Test.

There’s much more detail in his slides (see below).

Nate’s presentation: slides (blog/slideshare) | audio (mp3)

Getting Your Hands Dirty With HTML5

James Graham / Lachlan Hunt

What can you do with it now, what in the future?

Intro
Next iteration of HTML spec. Long overdue for overhaul. What are we trying to achieve? Do things you can’t do now without JS, for instance. Working on HTML and XHTML together. Authors can choose which is most appropriate for them.

Design Principles

• Compatability - Browsers must remain compatible with existing content, old sites MUST still work.
• Degrade gracefully - make new features work in, or at least not break, new browsers.
• Don’t reinvent the wheel - fix what we already have, don’t reinvent it from scratch.
• Pave the cowpath - consider Use Cases - look what authors already do and improve where neccessary.c.f. Microformat Date/Time pattern.
• Evolution, not revolution - make incremental improvements. Can’t discard existing content and start fresh.
• Solve real problems - ensure work is relevent to web developers. Identify the problems first, then find solutions.
• Priority of Constituencies - have to prioritise the needs of:
  Users, authors, implementers, spec writers, theoretical purity
• Secure by design - protect end users from malicious intent
• Separation of Concerns - Separate presentation, structure, semantics where doing so provides real benefits. <b> and <i> are still in the spec.
• DOM Consistency - minimize differences between HTML and XHTML, allow scripts to work now.
• Avoid needless complexity - authors won’t use something complex if they don’t understand it
• Well-defined Behaviour - 97% of web has syntax errors! Define precisely what browers must do with all possibly bad input.
• Handle Errors - authors make mistakes all the time, the spec must define how browsers handle the errors.
• Media independence - make sure pages work on different media, devices and platforms.
• Support World Languages - support pages in any language, bi-directional text etc
• Accessibility - provide for the needs of users with disabilities. Built-in preferred over add-on accessibility, where possible.

When can we start using HTML5?
As soon as the browsers start implementing the features. FF3, IE8 support some of the spec.

What can I do with it?
Common elements of a blog - header, main nav, article, sidebar, footer. So we get:

<header> element - for site-wide header, not H1. Title/subtitle etc.
<nav> element - screenreaders could jump straight to it easily
<article> element - for the main body
<aside> element - for sidebar etc, pullquotes.
<footer> element - for copyright info

These can add more consistency than using <div>s and variable class names.

<section> elements can be nested - each of which has H1 - without worrying about correct nesting of H1, H2 elements.

<time> - for posted date of blog item. Attribute has machine-readable timestamp, tag wraps human-readable content.
<figure> - represents image(or table etc)+caption, <legend> nested inside to associate it together.
<caption> not used for reasons of backwards compatibility.
<meter> - attributes shows rating of content - the bar is drawn by the browser not meant as a graphic. Eg, content of element is 3/5, the bar is drawn by the user agent. Also progress bars
<progress> for dynamic (ajax) apps.
<video> - native video support in browsers, DOM APIs for providing custom interfaces, no more dependance on Flash. Browser provides the controls etc. Casual authors can quickly cope with video files.
<canvas> - dynamically draw graphics and text, graphics-oriented DOM APIs.

Offline Web Apps - offline caching APIs, local storage, SQL database.
Developer Tools - HTML5 conformance checker - exceeds the capabilities of traditional DTD bases validators. Gives more useful info.
Parsing HTML5 - libraries for python, ruby. off-the-shelf parser reduces reliance on RegExpr hacks.
The Community - diverse group of individuals and organisations. W3C, WHATWG trying to work together. Open to everyone.
How to Contribute - general feedback, develop tools, research, community participation.

• blog.whatwg.org
• forums.whatwg.org
• wiki.whatwg.org
• Mailing list and IRC.

Jeremy Keith’s lifestream was the first I saw online, where he’d aggregated together his many RSS feeds into one place. It shows the various sources ordered by time, and it can be quite interesting to follow along and see what sort of sources are most prevalent at any one time. I’d been meaning to have a play with something similar myself for some time, but wasn’t sure how to go about it. Then a couple of weekends ago, I went to BarCampLondon3 and Cristiano Betta did a great session on how to author your lifestream using Yahoo! Pipes. There’s bags more information about how to do it at his blog. Finally, I thought it was about time I had a play with it myself. The feeds I used were the following:

• My photographic blog
• My rubgymad blog
• My web design blog
• Stuff I post to Flickr
• My tweets from Twitter
• Stuff I’m reading via del.icio.us

I decided against using my Last.fm feed for the moment, as it would probably swamp all the other inputs (I listen to a lot of music while working, it’s one of the perks of working from home, no-one moans about your choice of songs!).

Having got the basic lifestream out of Pipes, I used Dreamweaver’s XSLT transform functionality to generate a list which would sit in my ASP.NET page. I wanted to use specific icons to show which feed each item was from. Cristiano was using a JSON output for his pipe, but mine is coming out as RSS, so the custom ID’s applied in the pipe weren’t getting through, since they’re not part of the RSS spec.

CSS3 attribute selectors are one option, but they don’t work in clunky browsers like IE6. So having also been at Simon Willison’s jQuery session at BarCampLondon3, I thought I’d have a play with with the library to see if I could do some neat DOM manipulation to add the correct class to each list item.

The Llifestream list is marked up thus: <ul id=”lifestream”>. I added some jQuery to insert the class for the list element, based on the attribute of the link it contains. That requires a parent element to be changed, based on it’s child’s attributes. Slightly tricky for a jQuery novice like myself. It took me a while but eventually I found the correct syntax:

$(document).ready(function() {
$(”#lifestream > li > a[@href^=http://twitter]“).parent(”li”).addClass(”twitter”);
});

The first line calls jQuery once the full DOM is loaded; line 2 (which looks rather horrible with text wrap, but bear with me) selects an anchor with the attribute which begins with “http://twitter”, but I wanted the class added to the parent LI, so hence the chaining of jQuery functions.

Now all I needed to do was to add a case for each link type to my new lifestreamclasses.js file and add a linke to it in the header of my lifestream page, and the proper stylings can be applied. I decided to keep them in a separate JS file for ease of maintenance. Once the pipe has mashed it all together and I’ve written the relevant styles into the stylesheet, the resulting RSS aggregated feed looks like this.

When I first started cutting my teeth on dynamic web site development, I was pleased that Dreamweaver has plenty of tools to help out. Because we used it at work for sites, I chose the ASP.NET/C# server model, and used Access as the database (perfectly adequate for the size and features of the sites I was building).

Now I’m beginning to get to grips with PHP/mySQL for development. That’s going well too. And having used mySQL for a while, I can see the advantages over Access. But what I’d really like to do is upsize a few of my Access databases to mySQL and have them connect to my existing .NET applications, without having to re-write the damned things.

The data migration tools available to s smooth job, and the data is sitting there, ready to go. But now I’ve hit a brick wall. How to tell Dreamweaver I want to use a mySQL database instead of access! So I began looking for the correct connection string, this was some help. I also downloaded MySQL ODBC 3.51 and installed it.

Then I set the web.config file entry to this (bold being the connection string given in the link above):

<add key=”MM_CONNECTION_STRING_connPortfolio” value=”Driver={MySQL ODBC 3.51 Driver};Server=localhost;Database=myDatabase;User=myUser;
Password=myPassword;Option=3;” />

I tried the TEST button and Dreamweaver connected successfully! But try running the site via the browser (or Dreamweaver Live Data View) and it falls over with an error:

System.ArgumentException: An OLE DB Provider was not specified in the ConnectionString. An example would be, ‘Provider=SQLOLEDB;’.
at System.Data.OleDb.OleDbConnectionString.ValidateParse()

So tried a different connection method, using Connector/Net 1.0.9 with this syntax in the web.config file - but got very similar results. Then I found this following in an Adobe Tech Note (my emphasis):

Do I have to use ODBC?
No. For ASP sites you can also connect to a database using OLEDB. For ASP.NET sites you must use OLEDB or the native ASP.NET SQL Server connector.

So it looks like it has to be OLEDB, but how to put the correct provider in the connection string? Nothing I’ve tried seems to work! Any clues? Has anybody actually got this combination to work?

• Dreamweaver 8
• ASP.NET/C# server model
• mySQL database