Get ready for the mobile revolution
Serge Jespers (Adobe)
It was really good to really see HTML5 vs JavaScript vs Flash in the flesh, so to speak.
One theme was that now it's about more than the technology; it's about knowing where is the user using your application now - in the car, walking ... ? If the user is in car, for instance, the device might be in a holder away from their hands or sideways...
The idea here is that mobile devices should be a screwdriver, not a penknife - save that for the 'full fat' online or desktop version.
There was also some good practical advice on things like button size and resolution, such as being careful to place slider numbers so their not covered by a users finger/hand.
With Flash 10.1 multi-touch is now supported on some laptops as well as mobile,
and you can find out what device supports it at runtime, and enable gestures if supported.
There was a very cute demo using an Android phone as a Wii-style controller for a desktop 'Afterburner' style type 3d flight simulator.
On Android, Google is not a gatekeeper like Apple are, so you can just stick an application file on your website if you want. This is probably a killer feature for enterprises.
I asked about Flash 10 on my handset (the Nokia N900 which only has Flash 9 at the moment) 'as this was demo'ed at MAX' and Serge said as far as he knows it's 'still coming', which is awesome.
AJAX is the answer to everything and we never need to worry again and life is full of unicorns!
Ray Camden (FirstComp)
This was a refreshingly different, informal, audience engaging session.
Ray started out saying that "Spry made us love AJAX again" but JQuery is now the drug of choice, with most people in the room using that framework rather than ExtJS etc.
Other things I picked up were that data size is still important, because it's not enough to have the page load faster, if it's not usable until JavaScript has run and pulled down another megabyte of data.
Ray says AJAX lets you add features for fun, not because it's a good idea or good UX, so you must resist !
In summary Ray concludes 'life would be easier without users'.
It was great to be able to hear other peoples thoughts on these things.
SQL to HQL
John Whish (Crisp eBuisness)
This was a packed session ! I guess because it was annouced that morning that ColdFusion 9.0.1 lets you put HQL in CFQUERY, so it's interesting for more than just ORM. Or it may have been the 'Advanced' session later in the day.
So, John started of showing that HQL Queries objects, not tables, so that's what you get back.
He noted that SQL isn't dead- it's still better for complicated reports or populating initial data (apparently you can have ColdFusion run a bunch of insert SQL when it's ORM system starts up and (optionally) recreates all the tables).
It looks like HQL is case sensitive for object names but not properties names or keywords like FROM and WHERE. Odd, and bound to catch me out !
John demoed a HQL block returning an array of objects, and then used the built in function that converts this to a query, but no one could think of a good reason to do it.
One handy tip was that you must alias the object in FROM if you reference it in the SELECT, and it's case sensitive of course.
If you select specific properties you get an array of array which sucks and entitiesToQuery() can't help you either. There is a work around to use 'select new map(prop, prop,...' which then gets you an array of structs instead.
It seem SQL skills are very transferable because things like sort, group, and where comparisons are the same (or very nearly). You can Count() and Upper() etc. as well.
OrmExecuteQuery() takes named params for variables, but of course CFQUERY is more readable still because you can put CFQUERYPARAM's in.
If you delete in HQL, it returns the number of objects deleted, which is nice.
Other gotchas are if you don't define joins in the ORM CFC or the database, you can do in HQL instead but not if you need INNER or OUTER joins as they wont work.
But what is cool is you can just write 'article.artist.id = 12' ! Handily you then don't get an array or array of obj, you get an array of Article's, each of which has an artist property. You can lazy load in a variety of ways to stop this getting to expensive.
That's worth using HQL for even with the other stuff I reckon.