I spent several hours Saturday poking around in Facebook’s new Hiphop PHP source code compiler. I haven’t successfully built the program yet, but after taking some time to review the source code I’m very optimistic.
I would have a build already, but I tried to build the tool on a virtual server with 256Megs of ram. The only problem is that one of the source code files is 1.8 MB of text. The compiler footprint would balloon up to 800 Megs and swap thrash for a while before ultimately running out of memory when it tried to compile it. I’m going to build a 2Gig VM soon and that should be plenty of RAM to get it to build successfully.
The cardinal rule of web development is never trust user supplied data to be safe. A surprising number of developers don’t take this seriously when inserting into a database. An even larger group incorrectly trust their raw data for output. This opens upon the browser to what are called injection attacks.
Usually following these two techniques religiously is enough to secure your application from injection attacks. However, I ran into an interesting problem the other day that requires a third type of escaping.
I noticed today that the jQuery UI folks have gone about correcting the problems with the 1.6 release candidates. They’ve chosen to tie UI version 1.6 to jQuery 1.2 and create a new UI 1.7 to work with jQuery 1.3. I think this is a great idea. Between the CSS changes in the new UI version and the UI tools that were already leveraging new jQuery 1.3 functionallity it was obvious that 1.6 would not work in both jQuery 1.2.6 and 1.3.
I notice tonight that the UI homepage shows jQuery 1.3 next to UI 1.6rc6 and jQuery 1.2.6 next to UI 1.5.3. It would have been nice if the renumbered 1.6rc6 to 1.7rc1, but I’m at least glad that the site makes it clear what will work with what.
Over at Human Services HQ we’ve stabilized around jQuery 1.3, jQuery UI 1.6rc6, a third party autocomplete, and thickbox. The only change I had to make to get jQuery UI to allow a calendar inside the thickbox was to add a z-index to the calendar div. Since then it has been smooth sailing.
A lot of pain recently with jQuery UI. They are transitioning to a major new version: 1.6. First, off there is no official jQuery UI release for compatibility with jQuery 1.3. That’s fine, jQuery 1.3 is very new. It would have been nice if they could have released a UI version at the same time, but that’s their prerrogative. Normally I would have just waited for things to settle down anyway.
Unfortunately, one of my projects had the distinction of being one of the few production sites running a jQuery UI 1.6 release candidate. We needed it to fix a problem with the jQuery UI 1.5.3 sortable. It had a bug with nesting inside of a scrollable div that has been fixed in jQuery UI 1.6. So we’ve been watching 1.6 move towards a full release and it has been a bit painful.
We needed to add an autocomplete control to our site. So we looked into it and were horrified to learn that there are basically 4 different versions, all inter-related, all with terrible documentation. What’s worse some of the UI 1.6 release candidates included an autocomplete with a different API convention, but now in 1.6rc6 that autocomplete is gone. I found this out the hard way because generating an earlier rc my page magically broke. It turned out that if you downloaded the complete rc you got the autocomplete. If you built one there was no option for the autocomplete, and they would leave it out.
After I got that fixed I discovered that merely using the new JS wasn’t going to work as jQuery 1.6 needs new corresponding 1.6 css. So now I have to roll a new theme.
Now that I’ve worked with jQuery I refuse to work without it so I’ll have to ride this out, but it has been a painful week for me to see jQuery UI folks stumbling.
End result will hopefully be this:
a third party autocomplete (I can’t remember which of the 4, we’re using.)
Update:The above mentioned combination is working for the most part. Now we’re having a problem where the popup for the date control is showing up behind a thickbox control we’re using. Hopefully I can find a CSS fix to make it work.
When I started my latest project a friend of mine asked me to look into using jQuery. I had played with MooTools a couple years ago and was mildly impressed, and I figured jQuery would be more of the same.
Boy was I wrong! For what I’m doing jQuery is way better than
MooTools is basically two things:
- A set of really nice UI widgets
jQuery is similar, but the approach is a lot different:
- A tool for grabbing a collection of DOM elements.
- A mechanism for manipulating the collection once you grab it.
- And if you use jQuery UI, a set of really nice UI widgets
The core of jQuery is a simple CSS-like syntax for grabbing a collection DOM elements from the page. It turns out that the ability to grab the DOM elements you need is actually a disproportionately large part of building a modern web app. Don’t believe me? Say you need to output a formatted table with even lines colored differently than odd lines. Tradionally, this would mean crafting a CSS class named “even” and then writing server side code to determine if we were outputting an odd row or an even row. If it is an even row then we would add a class=”even” to the tr tag. This would all be done inside of a big loop outputting the table rows.
$('table > tr:even').addClass('even')
Boom! No need to write any server side code just to add a CSS class to alternate the background color of a row.