Web Development

Free framework looks to simplify Ajax development

Spry is a client-side framework in the form of JavaScript libraries that you can use to enhance Web pages with Ajax-based functionality. Its main goal is to demystify Ajax for developers and designers with basic HTML/CSS skills.
The number of freely available frameworks for Web development is a bit overwhelming, and it can be hard to keep up with all of them. TechRepublic member araalie mentioned Adobe Spry in a comment about my article on Dojo, and I decided to check out the framework.

Given Adobe's size and Web development products, I am intrigued by the Spry framework for Ajax. Though it is still in a prerelease stage, this article examines the Spry framework and explores what it brings to the table.

Adobe Labs

Like most large companies, Adobe has a substantial research and development department. The Adobe Labs group is part of it. Adobe Labs is the source for early looks at emerging products and technologies from Adobe. There are a variety of downloads available on the Adobe Labs site, including the Spry framework for Ajax.

What is it?

Spry is a client-side framework in the form of JavaScript libraries that you can use to enhance Web pages with Ajax-based functionality. Its main goal is to demystify Ajax for developers and designers with basic HTML/CSS skills. While it has been developed by Adobe, it is tool agnostic, so you can easily use it with your favorite editor as well as Dreamweaver. The crux of the Spry framework is XML, so a little XML knowledge goes a long way in using its features.

Target audience

Adobe is focusing on less-technical persons, while many libraries like jQuery focus on Web developers to utilize and extend their library code. Adobe states that the Spry framework for Ajax is meant primarily for users who are Web design professionals or advanced nonprofessional Web designers. It is not intended as a full Web application framework for enterprise-level Web development. With that said, here's a look at getting and using it.

It is free

The Spry framework is currently at a prerelease version of 1.5. It is freely available from the Adobe Labs site; it does require registration with a valid e-mail address to complete the download. You download it in a single, compressed file. And, you can extract and install it to a directory on a Web server to be up and running in minutes.

As an example, I downloaded and installed it on a local development machine running Microsoft Internet Information Server (IIS) in the following directory:

c:inetpubwwwrootspry_p1_5_051707

Using this directory, the samples included with the download are easily accessed via the following local URL on the machine:

http://localhost/samples/index.html

Three easy pieces

Spry is made available for use in your applications via the BSD License. The framework includes three main sections of functionality: Data, Widgets, and Effects.

  • Data: The Data API includes various functions for working with XML-based data. Spry creates datasets by making calls to the XML data sources URLs. Datasets can be tied together in a master/detail relationship, as well as easily displayed by tying them to regions of a page.
  • Widgets: The Widget API allows you to tie together HTML, CSS, and JavaScript code for user interaction. The HTML defines its structure, CSS defines its presentation, and JavaScript defines its behavior, such as responding to user actions.
  • Effects: The Effects API provides the ability to easily apply visual enhancements to almost any element on an HTML page. The current iteration of the framework includes the following effects: fade, highlight, blind up/down, slide up/down, grow, shake, and squish. Spry uses the script.aculo.us library for some effects.

The APIs are available in the JavaScript library files installed with the framework. They are located in the includes subdirectory of the Spry installation.

Drawbacks

One of the most frustrating aspects of Web development is ensuring an application works in various browsers. This involves ensuring the application degrades gracefully to work in browsers with minimal capabilities, including a lack of JavaScript support. With JavaScript being a central player in the AJAX acronym, a lack of it means it just won't work.

This is where the application should be designed to work without Ajax, and the Spry framework has not been designed to gracefully degrade. In fact, it does not work if JavaScript is disabled in the browser; you must keep this in mind if you use Spry. The onus of graceful degradation rests with the developer. A good source of information on implementing such support in an application is available in the recently reviewed book entitled Simply JavaScript.

Another concern with the Spry framework is the use of nonstandard attributes for HTML elements like the DIV tag. This type of design can cause pages using such code to not function in certain browsers. Adobe says the current version of Spry has been tested with Firefox 1.5, Internet Explorer 6, Safari 2.0.3, and Netscape 7.2. You can find more details on this point and other issues in the Spry framework FAQ.

My impressions

I find the Spry library a bit more complex than expected given its target audience of the less-than-JavaScript-savvy Web designer community. While it is easy to create data sources based upon XML, using these data sources relied upon my JavaScript knowledge. I did like the various features of the toolkit, but it makes me wonder how much a person with limited JavaScript knowledge will able to accomplish with Spry.

Spry gives you another option

Once upon a time it was hard to locate JavaScript libraries that simplified incorporating Ajax functionality in a Web application, but now the number of freely available libraries is a bit overwhelming. The niche aspect of the Spry framework for Ajax is that Adobe is targeting Web designers who are less technical. The framework does provide cool and usable features via its data support, as well as widgets and effects.

Have you worked with the Adobe Spry framework or any other freely available JavaScript libraries? Share your experience and preferences with the Web development community.

Check out the Web Development Zone archive, and catch up on the most recent editions of Tony Patton's column.

Tony Patton began his professional career as an application developer earning Java, VB, Lotus, and XML certifications to bolster his knowledge.

---------------------------------------------------------------------------------------

Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Development Zone newsletter, delivered each Tuesday. Automatically subscribe today!

About

Tony Patton has worn many hats over his 15+ years in the IT industry while witnessing many technologies come and go. He currently focuses on .NET and Web Development while trying to grasp the many facets of supporting such technologies in a productio...

14 comments
Jaqui
Jaqui

is the insecurity of having any application logic run on the clientside. any javascript, flash or activex required website app is a SEVERE security risk and no PROFESSIONAL would do that to their clients. AJAX requires javascript, therefore AJAX is a severe security risk.

SnoopDougEDoug
SnoopDougEDoug

Are you claiming client-side scripting is a risk for the client or the server? If the former, then you should certainly make sure you trust the site to which you are connected; if the latter, you no worse exposure than any other access point. I've seen some of these so-called security risks, and they are no different than the ones that already exist for Web apps (SQL injection, x-site, ...). doug

Jaqui
Jaqui

for the client, and has nothing to do with the server, it's the risk of running any code from a remote location, since it can be corrupted in transmission. you want to guarantee no corruption, then 100% of any site using clientside must be ssl based. and, since the ssl certificates are based on pay $x and I'll tell everyone you are a great company to do business with, there is no trusted CA for SSL. remote hosted code is not to be trusted.

mattohare
mattohare

The third party can hire a new programmer that rolls out a new library with out testing it properly. And crash your website. Google, Yahoo and Microsoft have all 'helped' us in these ways. Code is like images. Copy it to local, test it locally, then use it. Third party releases a new version, copy to test, test it in the test box, then release it.

Justin James
Justin James

I am with Jacqui on that one... at the very least, using a library hosted elsewhere is pretty darned scary to me. OK, if they make an update I don't have to download it and reinstall it on my server... but on the flip side, if a hacker gets onto their server and makes their own updates to that library, I just put my users in harms way. It's one thing to dynamically link to a library, it is another thing entirely to dynamically link to a remote library. J.Ja

SnoopDoug
SnoopDoug

Then why did you say: "any clientside script exposes application logic, leaving the server / app vulnerable to exploits." in post 8? Security should always be a concern, regardless of your architecture. AJAX is inherently no more or less secure than any other client-server architecture. The main problem with AJAX is that it is so easy to create applications using the technology, that companies are more concerned with banging out cheap applications, written by pseudo-developers, with little regard for security. And anyone who runs remote code from an unknown source gets what they deserve. No wonder many companies filter out anything that even remotely looks like executable code. doug

gdaley
gdaley

That would pretty much rule out any client-server type of architecture as being insecure, then. Any system that has application logic of some sort running on the client side MUST ensure that the server does not trust the input that it receives from the client. But this is the same, regardless of whether you have any application logic running on the client or not.

keeleyt83
keeleyt83

I don't have a link for you, but if you are so inclined, a presentation was given at the black hat conference this year on how to hack ajax applications. Well, back to work now :)

Jaqui
Jaqui

any clientside script exposes application logic, leaving the server / app vulnerable to exploits.

araalie
araalie

Well, I have tried Dojo, and Spry like I commented on an earlier article. After trying out Spry for several days I found it too restrictive for the developer. For example, I could easily trap and handle events. So I went to Google again and found Extjs. Now this is pretty heavy but again it is for web applications. I have used it to construct sleek Admin functionality for a site admin while using jQuery on the real website. Ext is well thought out especially for datastores, grids, pagin stuff!! I love it. Check out Extjs, they should be releasing version 2 soon.

Justin James
Justin James

I've been less-than-impressed with most of the Web development stuff that has come out of Adobe. Go Live was pretty bad. A lot of their "easy to use for the non-techie" stuff relied on bad techniques like slicing an image of the page into a billion pieces and then using a super complex, fixed sized table that never seemed to work right in any browser. Hopefully, Spry is of a higher quality than those products, but "Adobe" and "Web Development" do not mix well in my mind. Now, "Adobe" and "image/video manipulation"... oh yes. I just wish Photoshop was within my personal computing budget. :) J.Ja

mattohare
mattohare

Acrobat seems to want to spray itself into about every corner of my system, and require a system restart with every upgrade. Their macromedia acquisitions seem to be getting the same way. Any more, if i can't do it in the browser (with out any plugins), I avoid it as much as I like to avoid mashups.

sfegette
sfegette

Hi, Tony- Thanks for the review. I wanted to point out a few issues I noted within, however: - Script.aculo.us is not used for Spry effects. There were some references in earlier versions of the Spry documentation (please let us know if they still are within) - mostly regarding interoperability - but only external dependency I'm aware of with Spry is that we're using Google's XPath library within the Spry Data framework. - As with any framework, you can use it for the forces of good or evil, depending on the implementation . As of Spry 1.5, we've added support for HTML datasets- allowing you to create Spry datasets out of any HTML list/table in the current page (or a relative page)- which allows you to build a static page/experience and then consume it into a dataset to allow progressively-enhanced Ajax applications (to address your comments re: graceful degradation). No JavaScript? The static HTML still displays correctly and as expected- with this approach you can scale up dynamic functionality as client browser capabilities permit. - You don't need to touch the JS layer to incorporate Spry datasets into regions of your page. The spry:region attribute identifies Spry-enabled regions in the page such as DIVs, tables and lists, the spry:repeat attribute enables looping/repeating of elements like list items, table rows, etc, and the syntax for data 'placeholders' within these dynamic regions is also completely outside the JS layer (examples: {variable}, {@variable} ). - Although you're absolutely correct- the framework is targeted towards visual designers and doesn't have a direct dependency on JS coding, it's also made to be very accessible to JavaScript coders from the other direction. You can (again, as of Spry 1.5) use the framework unobtrusively, attaching the Spry attributes at runtime, not to mention tweak the framework's functionality much more by going directly into the JS layer. Anyway, thanks for indulging my nitpicking (but hope it was interesting at least?)- appreciate the review! -Scott, Adobe Systems

aspatton
aspatton

Scott, I appreciate the feedback - nitpicking is always good.

Editor's Picks