DomAPI version 4.5 has a new lower price and a simplified licensing plan.
In a nutshell, there are now 2 license types, 'Free' and 'Pro'. Both types can be used on commercial sites, in any capacity, with no restrictions. The benefits of the pro version include:
Access to unobfuscated source code
Access to hourly beta builds
Permission to alter the source code
Permission to remove branding and 'splash' items
Permission to bundle the library with applications
If you purchased a DomAPI 4.0 license, you automatically are upgraded to 4.5. If you have a 3.x license, or purchased a 3.x to 4.x upgrade, you will need to obtain a new 4.5 license. DomAPI 4.5 Professional licences are currently priced at only $49 USD.
The latest public release of DomAPI contains all the fixes an additions that have been made to DomAPI v4.0 since its original build nearly 2 years ago. These features were previously only available within the hourly beta builds, but now everyone can benefit from them.
Upgrading from 4.0 to 4.5 should be completely painless -- it is meant to be backwards compatible with your existing code.
Some of the major improvements include:
Complete support for IE7
Complete support for Firefox 2
Better memory leak protection in IE6/7
Plenty of little fixes and performance enhancements
I think that Firefox 3 and Safari 3 may end up tieing, and if you frame it as rendering engines, Webkit will probably beat Gecko as it is also being used by iPhone, AIR, Android, and Nokia (they use Gecko too).
The final, and most important, step is being worked on right now - a way to access native JSON encoding and decoding from web pages. How it'll be accessible is up to some debate (as having its naming conflict with an existing object would be a really bad thing). Regardless, there should be something within the browser by the time the Firefox 3 betas wrap-up.
Last week we posted about Jaxer which offers an approach of turtles all the way down where JavaScript is used on the client and the server.
Then, I got to interview Steve Yegge. Last year, Steve posted about Rhino on Rails, his port of Ruby on Rails to the JavaScript language on the Rhino runtime.
What can't you do since JavaScript doesn't have the same meta programming facilities?
Rails = a group of Active*, so did you re-implement everything?
What do you gain out of having JavaScript all the way down?
Does it actually make sense to have jjs? Server side JavaScript generating client side JavaScript? Argh!
What is the state of Rhino?
Will Rhino support JavaScript 2?
And of course, the big questions:
When do I get to see it!
I happen to be in Seattle at the Google offices, so I was able to ask all of these questions and more. Steve was a fantastic host, and I really enjoyed chatting with him.
This is the kind of video I want to explore at Google. We have many great developers working on cool technology. I want to get them on camera, participating with the community when I can. Sometimes we can talk about products and APIs, but sometimes we will talk about fun ideas and projects that we are working on such as Rhino on Rails.
Anyway, give it a watch and let me know what you think:
Adobe Dreamweaver isn't know for it's JavaScript support let alone coding help for the popular JavaScript libraries and frameworks. Up to now, developers and designers who've used DW for their client-side work have been left out of the fun of other IDEs such as Eclipse and Komodo . That's all changed now that to a couple new extensions for Dreamweaver have been built. Chris Charlton, Community Manager for RMI, has created extensions for Dreamweaver versions 6-9 (MX-CS3) that offer support for jQuery 1.2 and Prototype 1.6 development.
The jQuery API extension seems to be the farthest along offering code completion, code hints, code coloring, and a bunch of snippets that early beta users liked. The Prototype API extension only has basic code completion but is due for an update in the next few weeks to offer extended code hints. The code hints appear when editing a JS document and XTND.us has a short video of an extension in use. The demo video and downloads are freely available at http://xtnd.us. We use these tools every day and help train people... it's time the tools get better.
He's also planning on incorporating support for other libs and I'm sure would love some support in making this happen. So all you MooTools and YUI developers, get on the horse and help Chris out.
AJAX-captcha validation example (based on http://psyrens.com/captcha/)
Support for "remote" ajax-validation. In other words: Remote validation is now possible and very easy to use.
Added highlight and unhighlight options, by default toggles errorClass on element, allows custom highlighting
Added valid() plugin method for easy programmatic checking of forms and fields without the need to use the validator API
Added rules() plguin method to read and write rules for an element (currently read only)
Replaced regex for email method, thanks to the contribution by Scott Gonzalez, see http://projects.scottsplayground.com/email_address_validation/
Restructured event architecture to rely solely on delegation, both improving performance, and ease-of-use for the developer (requires jquery.delegate.js)
Added feature to merge min + max into and range and minlength + maxlength into rangelength
Added support for dynamic rule parameters, allowing to specify a function as a parameter eg. for minlength, called when validating the element
Allow to specify null or an empty string as a message to display nothing
Rules overhaul: Now supports combination of rules-option, metadata, classes (new) and attributes (new), see rules() for details
Added remember-the-milk-demo (thanks RTM team for the permission!)
Added marketo-demo (thanks Glen Lipka!)
One of the best features of this release is the remote validation via Ajax. This is extremely easy to implement with the code being as simple as this:
If you enter an email address, the validation plugin sends a request to the server with a parameter “email” and the value you entered. The server-side code can do it's magic and send back the appropriate response based on the user input.
Adding client-side validation to a form can significantly improve the usability of that form, making it much easier for users to fill them out successfully. But pure client-side validation has severe limits where necessary information is available only on the server. Ajax helps to bridge the gap, but synchronizing validation on form submit isn’t exactly an easy task. The validation plugin makes it as simple as pure client-side validation. All you need to do is to specify a rule “remote” for a field and provide a parameter that points to a server-side resource that handles the validation.
To see the plugin in action, Jörn has created some demos using styling from Marketo.com and Remember the Milk. You can see some screenshots below.
Brian Dillard of Agile Ajax has a review of Billy Hoffman's new book "Ajax Security". If you've not picked this book up, you really need to. It's received rave reviews and is quickly becoming the must-have security book for client-side development. As Brian can attest:
The book itself, of course, documents dozens more specific security vulnerabilities - as well as best practices for protecting your application against them. I said it before, and I'll say it again: "Ajax Security" is required reading for any professional software engineer.
Be sure to read Brian's review and be sure to get the book.
Adobe AIR, the platform that lets you create desktop apps using web technologies, continues to garner attention. With Beta 3 just recently released and a host of companies coming out with new apps, AIR is building up a ton of steam just prior to it's official v1.0 release.
We’ve heard this request right from the start “Is there something like Firebug, that lets me monitor the assets in my application?” The answer to that question is now a resounding, YES! The AIR Introspector is designed to let you interact deeply with every aspect of your application.
Mind you that this is a BIG plus to AIR development which hasn't benefited from having the ubiquitous FireBug to help during tough debugging sessions.
Some features included are:
Point at a user interface element and be able to see and edit the markup and DOM properties.
An interactive console that lets you access references, adjust values and execute JavaScript code.
Lists links, images, CSS and JavaScript assets loaded into your application.
Provides for viewing the original markup and the current markup.
Viewer for XHR objects including their properties and headers.
Search for matching text in the source code of your application.
Also, Aptana just updated the Studio IDE to support AIR Beta 3. While developing AIR in other editors is perfectly fine, Aptana really has done the best job of integrating support into their IDE making it substantially easier to build AIR apps. This is just pure speculation but I wouldn't doubt that a big player, like Adobe, scoops up Aptana in 2008.
Nasdaq and the American Cancer Society are among several large organizations eyeing the Adobe runtime as a way to bridge the traditional gap between Web and desktop applications.
Using Adobe's Flex and AIR, the Nasdaq created an application that can "can provide a replay of the quotes at the time of a trade -- and associated prices on different markets -- in seconds".
The software runs on the desktop, relieving servers of a good deal of data-intensive processing, he noted. "We saw the ability to process the data halfway on our servers and have it in as small a package as possible. Then when someone requires a replay of the market, we send a small packet of data to desktop," he said.
The American Cancer Society has been using AIR since early beta and has continued to build new apps regularly. Their recent initiative was a desktop application to assist users in determining when it was appropriate to schedule mammograms:
Another new Cancer Society application allows users to enter demographic information and receive suggestions about scheduling tests such as a mammogram, he said. The group hopes that providing such reminders on desktop systems will be more effective in prompting users about their treatment needs than forcing them to frequently visit a Web site, Pellegrini added.
They're also creating a Flex/AIR-based portal for physicians that will allow the doctors to access Cancer Society's information via the web or in an offline mode.
The offline synchronization capabilities of AIR are especially attractive to many companies as more and more employees are working remotely and may not have immediate access to the web. The inclusion of the SQLLite DB into the AIR runtime seems to have really piqued the interest of IT departments interested in providing the desktop experience without having to retrain their staff in traditional desktop tools such as C# or VB.Net.
Challenges Ahead
AIR is not in the clear though as very strong technologies from both Microsoft (SilverLight/.Net) and Mozilla (XULRunner) are serious challengers to the desktop space and could bite into AIR's pie. The biggest advantage that AIR has, though, is Flash Player 9's near 97% penetration rate. In addition, rumor has it that Adobe will issue an update to the Flash player that would include the AIR runtime making it a highly desirable target for building new applications. We'll have to see if the rumor holds true.
For now, though, AIR is certainly showing a lot of promise and seems to have gotten past the "evaluation" stage. Once v1.0 is officially released (rumored to be sometime soon), the number of AIR applications will undoubtedly rise. I also envision an opportunity for developers to benefit financially from selling desktop applications that seamlessly tie into the web.
This should be interesting.
Update: Adobe's Rob Christensen has sent me an update letting me know that Adobe has no plans at this time to bundle AIR with the Flash Player. One of the primary goals of the Flash Player is to keep the download size as small o that they can continue adding powerful features like h.264. Thanks for the update Rob.
Bill Orcutt just announced the first beta release of Lily, an open source, Mozilla based visual programming environment written in Javascript. Lily is a very neat way of building an application by connecting modules which handle the intricacies of working with data, animation and sound. It's a testament to the power of JavaScript:
I'm happy to announce the first beta release of Lily, an open source, Mozilla based visual programming environment written in Javascript. Lily is a modular framework that allows you to wire together Javascript library components graphically. Currently there are Lily modules that wrap components from the YUI, JQuery & Scriptaculous libraries. There are also modules that provide access to the file system, browser storage, network & graphics. Lily programs can be saved as standalone XULRunner applications or as Firefox addons.
Lily currently has over 180 modules which allow you to take advantage of different libraries and services including jQuery, YUI, Google Maps and Amazon.
Bob has provided some demo links to get a feel for some of what Lily can do:
Michael Morrison, author of Head First JavaScript, has written a piece for CIO magazine titled You Used JavaScript to Write WHAT? which is part of a series of articles on when to use a particular language or platform.
It is always interesting to see what the CXO folks are reading wrt our beloved Web :)
The other side of the coin is the mentality of viewing a Web application as a program, as opposed to a page. In this scenario, the application is utterly dependent on the active functionality made possible by JavaScript, which means it's okay to forego users who lack JavaScript support. Google has embraced this philosophy in several marquee products, two of which are extremely popular: Gmail and Google Maps. Both applications make extensive use of Ajax (JavaScript), and neither apologizes to users who can't run them due to a lack of JavaScript. If this article had been written just a few short years ago, I might have used an e-mail application as the ridiculous example of when not to use JavaScript, instead of Halo. But Gmail has pushed through that barrier.
Even if JavaScript-powered, web-based e-mail ultimately takes hold, surely there are other stand-alone applications that will just never make sense in Web form. Two such applications that come to mind are video and photo editing. Similar to games, these are such media-intensive applications that they just can't make sense in JavaScript, right? Yet Adobe has already released Premiere Express for online video editing and is putting the finishing touches on Photoshop Express for Web-based photo editing. What's interesting about these applications is that they aren't technically built in JavaScript; they're built in ActionScript, a close cousin of JavaScript used in Adobe's Flex development environment. But the ActionScript in these applications is compiled, so the net effect is more akin to a native application. Adobe may be foreshadowing the future of Web scripting to some degree, at least in terms of building more feature-rich applications. And in doing so, they're forcing us to rethink just what is possible with scripting languages.
I don't know about you, but the idea of ordering food online has had promise, but often falls flat. When I lived in Boulder I would order from The Sink, but they would call you back and confirm the order, which kinda defeated the point.
If you don't get a call back though, then you wonder... "hmm is someone on the other end of this web site thing? Are they REALLY going to bring my food!"
Dominos has done the right thing. They give you feedback, but not in the annoying way. After you put in an order online you can watch the entire process, so you feel like you know exactly what is happening without talking to a person until the doorbell rings:
He also has his own widgets such as Proto.IPS an unobtrusive in-place-select widget that mimics the Gmail chat ability to drop down and select, or type in your own new content.
, Library
