redirect to

HAXE :: Web oriented universal language

2006-10-08T07:32:00.000-07:00

Introduction

haXe is a high-level object-oriented programming language mainly focused on helping programers develop Websites and Web applications. haXe has been designed to be easily portable across several platforms. The haXe compiler supports the following platforms :

JavaScript : you can generate a single .js file from a set of haXe classes. You can access browser DHTML API as well as crossbrowser APIs such as Xml, Date or XmlHttpRequest... haXe is one of the best available languages to develop middle and large scale AJAX Web Applications.

Flash : haXe can compile a SWF file for Flash Players 6 to 9. The language has great features and is at the same time both strict and dynamic. Using haXe increases productivity compared to ActionScript. All the Flash APIs are available unchanged in haXe so you will quickly get used to the language, and porting your existing code to haXe will be easy.

Neko : haXe can compile bytecode that runs on the Neko Virtual Machine. An haXe program can then be run into the Apache web server (using mod_neko). This allows you to develop the server-side of your website using haXe. haXe has access to all Neko libraries such as filesystem, network, databases... and much more. Since it can easily be extended with additional libraries, haXe can be used to develop full-fledged desktop applications.

haXe Features

The haXe Syntax is similar to the one used in Java/JavaScript/ActionScript, so it’s very easy to learn and get used to haXe. haXe can also integrate easily in your favorite editor or IDE.

The haXe Type System is strictly typed, enabling the compiler to detect most errors at compile-time. At the same time, it’s very different from classic strictly typed languages since you don’t have to write types everywhere in your program, thanks to type inference. It makes you feel like you are programming in a dynamically typed language while you are getting the security of a strictly typed language. The best of both worlds.

The haXe Standard Library, including Date, XML, data structures... is specified to behave the same across all platforms. This enables you to share and reuse code logic between different platforms without needing to rewrite the same thing again and again.

haXe is easily Extensible : you can add additional libraries and wrappers for platform-specific features. Thanks to conditional compilation you can have different implementation for a given API depending on the platform you want to compile to.

haXe has a Remoting library that provides cross platform serialization and RPC, enabling you to directly call methods between platforms. For example calls may be made between the client and the server or between different client modules. Everything is handled transparently.

haXe can be used to develop portable Desktop applications by using SWHX.

haXe is Open Source software and has an active and enthusiastic Community which supports the language by developing content and additional libraries.

Conclusion

haXe is a Toolbox for the web developer. Since the compiler has support for several platforms you can choose the most suitable one to get your job done without having to learn and use a new language everytime. Although using haXe on both the client and server simplifies things thereby boosting productivity, haXe may be used exclusively on the client or the server. You can use haXe where it makes sense for you.

Want to learn more ?

Read the haXe Documentation and have a look at the Language Reference. If you have any questions or remarks, don’t hesitate to join the haXe Community.

from : http://www.haxe.org/intro

Google Web Toolkit

2006-10-04T10:26:00.000-07:00

What is Google Web Toolkit?

Google Web Toolkit (GWT) is a Java development framework that lets you escape the matrix of technologies that make writing AJAX applications so difficult and error prone. With GWT, you can develop and debug AJAX applications in the Java language using the Java development tools of your choice. When you deploy your application to production, the GWT compiler to translates your Java application to browser-compliant JavaScript and HTML.

Here's the GWT development cycle:

Use your favorite Java IDE to write and debug an application in the Java language, using as many (or as few) GWT libraries as you find useful.
Use GWT's Java-to-JavaScript compiler to distill your application into a set of JavaScript and HTML files that you can serve with any web server.
Confirm that your application works in each browser that you want to support, which usually takes no additional work.

Why Translate Java Code to JavaScript?

Java technologies offer a productive development plaform, and with GWT, they can instantly become the basis of your AJAX development platform as well. Here are some of the benefits of developing with GWT:

You can use all of your favorite Java development tools (Eclipse, IntelliJ, JProfiler, JUnit) for AJAX development.
Static type checking in the Java language boosts productivity while reducing errors.
Common JavaScript errors (typos, type mismatches) are easily caught at compile time rather than by users at runtime.
Code prompting/completion is widely available.
Automated Java refactoring is pretty snazzy these days.
Java-based OO designs are easier to communicate and understand, thus making your AJAX code base more comprehensible with less documentation.

Using Google Web Toolkit

You can use GWT's set of UI components (called Widgets) to construct the UI elements that make up your AJAX application. Like traditional UI frameworks, Widgets are combined in Panels that determine the layout of the widgets contained within them. This is a complete GWT application that displays a button with a click handler:

public class Hello implements EntryPoint {
  public void onModuleLoad() {
    Button b = new Button("Click me", new ClickListener() {
      public void onClick(Widget sender) {
        Window.alert("Hello, AJAX");
      }
    });
    RootPanel.get().add(b);
  }
}

GWT supports a variety of built-in Widgets that are useful for AJAX applications, including hierachical trees, tab bars, menu bars, and modal dialog boxes. GWT also has built-in support for remote procedure calls and other more sophisticated web application features. See the complete list of features for more information.

Debugging and Deploying GWT Applications

GWT applications can be run in two modes:

Hosted mode - In hosted mode, your application is run as Java bytecode within the Java Virtual Machine (JVM). You will typically spend most of your development time in hosted mode because running in the JVM means you can take advantage of Java's debugging facilities and remain within an IDE like Eclipse.
Web mode - In web mode, your application is run as pure JavaScript and HTML, compiled from your original Java source code with the GWT Java-to-JavaScript compiler. When you deploy your GWT applications to production, you deploy this JavaScript and HTML to your web servers, so end users will only see the web mode version of your application.

To support hosted mode, GWT ships with a special web browser with hooks into the JVM. See the GWT architecture diagram below for more information.

For a step-by-step installation and usage guide, please see the Getting Started Guide.

Google Web Toolkit Architecture

GWT has four major components: a Java-to-JavaScript compiler, a "hosted" web browser, and two Java class libraries:

The components, from bottom to top, are:

GWT Java-to-JavaScript Compiler

The GWT Java-to-JavaScript compiler translates the Java programming language to the JavaScript programming language. You use the GWT compiler to run your GWT applications in web mode.
GWT Hosted Web Browser

The GWT Hosted Web Browser lets you run and execute your GWT applications in hosted mode, where your code runs as Java in the Java Virtual Machine without compiling to JavaScript. To accomplish this, the GWT browser embeds a special browser control (an Internet Explorer control on Windows or a Gecko/Mozilla control on Linux) with hooks into the JVM.
JRE emulation library

GWT contains JavaScript implementations of the most widely used classes in the Java standard class library, including most of the java.lang package classes and a subset of the java.util package classes. The rest of the Java standard library isn't supported natively within GWT. For example, packages like java.io don't apply to web applications since they access the network and local file system.
GWT Web UI class library

The GWT web UI class library is a set of custom interfaces and classes that let your create web browser "widgets," like buttons, text boxes, images, and text. This is the core user interface library used to create GWT applications. GWT ships with the complete source code for the library under an open source license.

For a step-by-step installation and usage guide, please see the Getting Started Guide.

How Well Does It Work?

We're biased, but we think it works pretty darn well. The primary metrics we use to evaluate GWT's effectiveness relative to traditional AJAX development are:

Compiler-generated JavaScript size

A typical, full-featured GWT application will require the user to download about 100K of cacheable JavaScript, which is in line with most hand-written AJAX applications.
End-user performance

GWT applications are almost always as fast as hand-written JavaScript. The GWT compiler avoids adding any wrappers around any functionality that is implemented natively in the browser.
Development time

With so little time spent debugging problems in individual web browsers, you can spend much more of your time on application functionality. Development time efficiency is our favorite part of GWT.

Try it out for yourself, and let us know what you think.

Google Web Toolkit Features

Dynamic, reusable UI components

Create a Widget by compositing other Widgets. Lay out Widgets automatically in Panels. Send your Widget to other developers in a JAR file.
Really simple RPC

To communicate from your web application to your web server, you just need to define serializable Java classes for your request and response. In production, GWT automatically serializes the request and deserializes the response from the server. GWT's RPC mechanism can even handle polymorphic class hierarchies, and you can throw exceptions across the wire.
Browser history management

No, AJAX applications don't need to break the browser's back button. GWT lets you make your site more usable by easily adding state to the browser's back button history.
Real debugging

In production, your code is compiled to JavaScript, but at development time it runs in the Java virtual machine. That means when your code performs an action like handling a mouse event, you get full-featured Java debugging, with exceptions and the advanced debugging features of IDEs like Eclipse.
Browser compatible

Your GWT applications automatically support IE, Firefox, Mozilla, Safari, and Opera with no browser detection or special-casing within your code in most cases.
JUnit integration

GWT's direct integration with JUnit lets you unit test both in a debugger and in a browser...and you can even unit test asynchronous RPCs.
Internationalization

Easily create efficient internationalized applications and libraries.
Interoperability and fine-grained control

If GWT's class library doesn't meet your needs, you can mix handwritten JavaScript in your Java source code using our JavaScript Native Interface (JSNI).

For a step-by-step installation and usage guide, please see the Getting Started Guide.

from: http://code.google.com/webtoolkit/overview.html

Ruby

2006-10-02T00:56:00.000-07:00

About Ruby

Wondering why Ruby is so popular? Its fans call it a beautiful, artful language. And yet, they say it’s handy and practical. What gives?

The Ideals of Ruby’s Creator

Ruby is a language of careful balance. Its creator, Yukihiro “matz” Matsumoto, blended parts of his favorite languages (Perl, Smalltalk, Eiffel, Ada, and Lisp) to form a new language that balanced functional programming with imperative programming.

He has often said that he is “trying to make Ruby natural, not simple,” in a way that mirrors life.

Building on this, he adds:

Ruby is simple in appearance, but is very complex inside, just like our human body¹.

About Ruby’s Growth

Since its public release in 1995, Ruby has drawn devoted coders worldwide. In 2006, Ruby achieved mass acceptance. With active user groups formed in the world’s major cities and Ruby-related conferences filled to capacity.

Ruby-Talk, the primary mailing list for discussion of the Ruby language has climbed to an average of 200 messages per day.

The TIOBE index, which measures the growth of programming languages, ranks Ruby as #13 among programming languages worldwide. Citing its growth, they predict, “Chances are that Ruby will enter the top 10 within half a year.” Much of the growth is attributed to the popularity of software written in Ruby, particularly the Ruby on Rails web framework².

Ruby is also totally free. Not only free of charge, but also free to use, copy, modify, and distribute.

Seeing Everything as an Object

Initially, Matz looked at other languages to find an ideal syntax. Recalling his search, he said, “I wanted a scripting language that was more powerful than Perl, and more object-oriented than Python³.”

In Ruby, everything is an object. Every bit of information and code can be given their own properties and actions. Object-oriented programming calls properties by the name instance variables and actions are known as methods. Ruby’s pure object-oriented approach is most commonly demonstrated by a bit of code which applies an action to a number.

5.times { print "We *love* Ruby -- it's outrageous!" }

In many languages, numbers and other primitive types are not objects. Ruby follows the influence of the Smalltalk language by giving methods and instance variables to all of its types. This eases one’s use of Ruby, since rules applying to objects apply to all of Ruby.

Ruby’s Flexibility

Ruby is seen as a flexible language, since it allows its users to freely alter its parts. Essential parts of Ruby can be removed or redefined, at will. Existing parts can be added upon. Ruby tries not to restrict the coder.

For example, addition is performed with the plus (+) operator. But, if you’d rather use the readable word plus, you could add such a method to Ruby’s builtin Numeric class.

class Numeric
 def plus(x)
   self.+(x)
 end
end

y = 5.plus 6
# y is now equal to 11

Ruby’s operators are syntactic sugar for methods. You can redefine them as well.

Blocks, a Truly Expressive Feature

Ruby’s block are also seen as a source of great flexibility. A programmer can attach a closure to any method, describing how that method should act. The closure is called a block and has become one of the most popular features for newcomers to Ruby from other imperative languages like PHP or Visual Basic.

Blocks are insipired by functional languages. Matz said, “in Ruby closures, I wanted to respect the Lisp culture⁴.”

search_engines =
 %w[Google Yahoo MSN].map do |engine|
   "http://www." + engine.downcase + ".com"
 end

In the above code, the block is described inside the do ... end construct. The map method applies the block to the provided list of words. Many other methods in Ruby leave a hole open for a coder to write their own block to fill in the details of what that method should do.

Ruby and the Mixin

Unlike many object-oriented languages, Ruby features single inheritance only, on purpose. But Ruby knows the concept of modules (called Categories in Objective-C). Modules are collections of methods.

Classes can mixin a module and receive all its methods for free. For example, any class which implements the each method can mixin the Enumerable module, which adds a pile of methods that use each for looping.

class MyArray
 include Enumerable
end

Generally, Rubyists see this as a much clearer way than multiple inheritance, which is complex and can be too restrictive.

Ruby’s Visual Appearance

While Ruby often uses very limited punctuation and usually prefers English keywords, some punctuation is used to decorate Ruby. Ruby needs no variable declarations. It uses simple naming conventions to denote the scope of variables.

var could be a local variable.
@var is an instance variable.
$var is a global variable.

These sigils enhance readability by allowing the programmer to easily identify the roles of each variable. It also becomes unnecessary to use a tiresome self. prepended to every instance member.

Beyond the Basics

Ruby has a wealth of other features, among which are the following:

Ruby has exception handling features, like Java or Python, to make it easy to handle errors.

Ruby features a true mark-and-sweep garbage collector for all Ruby objects. No need to maintain reference counts in extension libraries. As Matz says, “This is better for your health.”

Writing C extensions in Ruby is easier than in Perl or Python, with a very elegant API for calling Ruby from C. This includes calls for embedding Ruby in software, for use as a scripting language. A SWIG interface is also available.

Ruby can load extension libraries dynamically if an OS allows.

Ruby features OS independent threading. Thus, for all platforms on which Ruby runs, you also have multithreading, regardless of if the OS supports it or not, even on MS-DOS!

Ruby is highly portable: it is developed mostly on GNU/Linux, but works on many types of UNIX, Mac OS X, Windows 95/98/Me/NT/2000/XP, DOS, BeOS, OS/2, etc.

from: http://www.ruby-lang.org/en/about/

Prado

2006-09-27T10:39:00.000-07:00

PRADO is a component-based and event-driven framework
for rapid Web programming in PHP 5.
PRADO reconceptualizes Web application development in terms of components,
events and properties instead of procedures, URLs and query
parameters.

A PRADO component is a combination of a specification file (in XML), an HTML template and a PHP class. PRADO components are combined together to form larger components or complete PRADO pages.

Developing PRADO Web applications mainly involves instantiating prebuilt and application-specific component types, configuring them by setting their properties, responding to their events by writing handler functions, and composing them into application tasks.

PRADO provides the following benefits for Web application developers:

reusability - Codes following the PRADO component protocol are highly reusable. Everything in PRADO is a reusable component.

ease of use - Creating and using components are extremely easy. Usually they simply involve configuring component properties.

robustness - PRADO frees developers from writing boring, buggy code. They code in terms of objects, methods and properties, instead of URLs and query parameters. The latest PHP5 exception mechanism is exploited that enables line-precise error reporting.

performance - PRADO uses a cache technique to ensure the performance of applications based on it. The performance is in fact comparable to those based on commonly used template engines.

team integration - PRADO enables separation of content and presentation. Components, typically pages, have their content (logic) and presentation stored in different files.

from: http://www.xisc.com

PEAR - PHP Extension and Application Repository

2006-09-25T10:38:00.000-07:00

PEAR is a framework and distribution system for reusable PHP
components. More information about PEAR can be found in the
online manual and the FAQ.

If you are a first time user, you might be especially interested in the manual chapter "About PEAR".

Recent news about PEAR can be found here.

PEAR provides the above mentioned PHP components in the form of socalled "Packages". If you would like to download PEAR packages, you can browse the complete list here. Alternatively you can search for packages by some keywords using the search box above. Apart from simply downloading a package, PEAR also provides a command-line interface that can be used to automatically install packages. The manual describes this procedure in detail.
In case you need support for PEAR in general or a package in special, we have compiled a list of the available support resources.

from: http://pear.php.net

CakePHP

2006-09-24T06:17:00.000-07:00

What is CakePHP?
Cake is a rapid development framework for PHP which uses commonly known design patterns like ActiveRecord, Association Data Mapping, Front Controller and MVC. Our primary goal is to provide a structured framework that enables PHP users at all levels to rapidly develop robust web applications, without any loss to flexibility.

from: http://www.cakephp.org/

Ruby on Rails

2006-09-23T06:06:00.000-07:00

Ruby on Rails is an open-source web framework that's optimized for programmer happiness and sustainable productivity. It lets you write beautiful code by favoring convention over configuration

What's in the package?

Rails is a full-stack framework for developing database-backed web applications according to the Model-View-Control pattern. From the Ajax in the view, to the request and response in the controller, to the domain model wrapping the database, Rails gives you a pure-Ruby development environment. To go live, all you need to add is a database and a web server.

Who is already on Rails?

Everyone from startups to non-profits to enterprise organizations are using Rails. Rails is all about infrastructure so it's a great fit for practically any type of web application Be it software for collaboration, community, e-commerce, content management, statistics, management, you name it. Examples:

Basecamp: Project management. The original Rails app by 37signals.	Campfire: Group chat for biz. Pushing the limits of Ajax in Rails.
43things: Achieve your goals in life.	ODEO: Record and share audio.
Shopify: E-commerce made easy.	Fluxiom: Digital asset management.
Strongspace: Secure file hosting.	Typo: Put your weblog on Rails.
See more applications

What else do I need?

Rails works with a wealth of web servers and databases. For web server, we recommend Apache or lighttpd, running either FastCGI or SCGI, or Mongrel. For database, you can use MySQL, PostgreSQL, SQLite, Oracle, SQL Server, DB2, or Firebird. Just about any operating system will do, but we recommend a 'nix-based one for deployment.

If you need hosting, TextDrive is the official Ruby on Rails host, offering fantastic plans with a knowledgeable staff. Whether you need shared or dedicated hosting, these guys are experts in Ruby on Rails. For alternatives, see the wiki for a full list of Rails web hosts.

from: http://www.rubyonrails.org

Spry framework for Ajax

2006-09-21T11:00:00.000-07:00

The Spry framework for Ajax is a JavaScript library for web designers that provides functionality that allows designers to build pages that provide a richer experience for their users. It is designed to bring Ajax to the web design community who can benefit from Ajax, but are not well served by other frameworks.

The first release of the Spry framework was a preview of the data capabilities that enable designers to incorporate XML data into their HTML documents using HTML, CSS, and a minimal amount of JavaScript, without the need for refreshing the entire page. The Spry framework is HTML-centric, and easy to implement for users with basic knowledge of HTML, CSS and JavaScript. The framework was designed such that the markup is simple and the JavaScript is minimal. The Spry framework can be used by anyone who is authoring for the web in their tool of choice.

This is the 4th pre-release of Spry. In this release, we are introducing Spry Effects: javascript behaviors that provide animation and color effects for page elements.

This is just the start of the project. We're releasing a preview build now so that you have plenty of time to give us feedback on what’s working for you, and what isn't. Your feedback and participation is important to us as we build out the framework.

Download and Discuss

Get prerelease 1.3 of Spry framework now

Discuss Spry in the Labs forums

To see what is possible using Spry, check out our Demos that show the Spry framework in action.

Photo Gallery—An XML-based photo gallery.
Product Table—An interactive data grid displaying XML-based data.
RSS Reader—An RSS reader showing how multiple XML files can be used to build a rich interface.
Effects Demo—A series of sample effects.

from: http://labs.adobe.com/technologies/spry/

Ajax: A New Approach to Web Applications

2006-09-20T21:21:00.000-07:00

If anything about current interaction design can be called “glamorous,” it’s creating Web applications. After all, when was the last time you heard someone rave about the interaction design of a product that wasn’t on the Web? (Okay, besides the iPod.) All the cool, innovative new projects are online.

Despite this, Web interaction designers can’t help but feel a little envious of our colleagues who create desktop software. Desktop applications have a richness and responsiveness that has seemed out of reach on the Web. The same simplicity that enabled the Web’s rapid proliferation also creates a gap between the experiences we can provide and the experiences users can get from a desktop application.

That gap is closing. Take a look at Google Suggest. Watch the way the suggested terms update as you type, almost instantly. Now look at Google Maps. Zoom in. Use your cursor to grab the map and scroll around a bit. Again, everything happens almost instantly, with no waiting for pages to reload.

Google Suggest and Google Maps are two examples of a new approach to web applications that we at Adaptive Path have been calling Ajax. The name is shorthand for Asynchronous JavaScript + XML, and it represents a fundamental shift in what’s possible on the Web.

Defining Ajax

Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:

standards-based presentation using XHTML and CSS;
dynamic display and interaction using the Document Object Model;
data interchange and manipulation using XML and XSLT;
asynchronous data retrieval using XMLHttpRequest;
and JavaScript binding everything together.

The classic web application model works like this: Most user actions in the interface trigger an HTTP request back to a web server. The server does some processing — retrieving data, crunching numbers, talking to various legacy systems — and then returns an HTML page to the client. It’s a model adapted from the Web’s original use as a hypertext medium, but as fans of The Elements of User Experience know, what makes the Web good for hypertext doesn’t necessarily make it good for software applications.

Figure 1: The traditional model for web applications (left) compared to the Ajax model (right).

This approach makes a lot of technical sense, but it doesn’t make for a great user experience. While the server is doing its thing, what’s the user doing? That’s right, waiting. And at every step in a task, the user waits some more.

Obviously, if we were designing the Web from scratch for applications, we wouldn’t make users wait around. Once an interface is loaded, why should the user interaction come to a halt every time the application needs something from the server? In fact, why should the user see the application go to the server at all?

How Ajax is Different

An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary — an Ajax engine — between the user and the server. It seems like adding a layer to the application would make it less responsive, but the opposite is true.

Instead of loading a webpage, at the start of the session, the browser loads an Ajax engine — written in JavaScript and usually tucked away in a hidden frame. This engine is responsible for both rendering the interface the user sees and communicating with the server on the user’s behalf. The Ajax engine allows the user’s interaction with the application to happen asynchronously — independent of communication with the server. So the user is never staring at a blank browser window and an hourglass icon, waiting around for the server to do something.

Figure 2: The synchronous interaction pattern of a traditional web application (top) compared with the asynchronous pattern of an Ajax application (bottom).

Every user action that normally would generate an HTTP request takes the form of a JavaScript call to the Ajax engine instead. Any response to a user action that doesn’t require a trip back to the server — such as simple data validation, editing data in memory, and even some navigation — the engine handles on its own. If the engine needs something from the server in order to respond — if it’s submitting data for processing, loading additional interface code, or retrieving new data — the engine makes those requests asynchronously, usually using XML, without stalling a user’s interaction with the application.

Who’s Using Ajax

Google is making a huge investment in developing the Ajax approach. All of the major products Google has introduced over the last year — Orkut, Gmail, the latest beta version of Google Groups, Google Suggest, and Google Maps — are Ajax applications. (For more on the technical nuts and bolts of these Ajax implementations, check out these excellent analyses of Gmail, Google Suggest, and Google Maps.) Others are following suit: many of the features that people love in Flickr depend on Ajax, and Amazon’s A9.com search engine applies similar techniques.

These projects demonstrate that Ajax is not only technically sound, but also practical for real-world applications. This isn’t another technology that only works in a laboratory. And Ajax applications can be any size, from the very simple, single-function Google Suggest to the very complex and sophisticated Google Maps.

At Adaptive Path, we’ve been doing our own work with Ajax over the last several months, and we’re realizing we’ve only scratched the surface of the rich interaction and responsiveness that Ajax applications can provide. Ajax is an important development for Web applications, and its importance is only going to grow. And because there are so many developers out there who already know how to use these technologies, we expect to see many more organizations following Google’s lead in reaping the competitive advantage Ajax provides.

Moving Forward

The biggest challenges in creating Ajax applications are not technical. The core Ajax technologies are mature, stable, and well understood. Instead, the challenges are for the designers of these applications: to forget what we think we know about the limitations of the Web, and begin to imagine a wider, richer range of possibilities.

It’s going to be fun.

Ajax Q&A

March 13, 2005: Since we first published Jesse’s essay, we’ve received an enormous amount of correspondence from readers with questions about Ajax. In this Q&A, Jesse responds to some of the most common queries.

Q. Did Adaptive Path invent Ajax? Did Google? Did Adaptive Path help build Google’s Ajax applications?

A. Neither Adaptive Path nor Google invented Ajax. Google’s recent products are simply the highest-profile examples of Ajax applications. Adaptive Path was not involved in the development of Google’s Ajax applications, but we have been doing Ajax work for some of our other clients.

Q. Is Adaptive Path selling Ajax components or trademarking the name? Where can I download it?

A. Ajax isn’t something you can download. It’s an approach — a way of thinking about the architecture of web applications using certain technologies. Neither the Ajax name nor the approach are proprietary to Adaptive Path.

Q. Is Ajax just another name for XMLHttpRequest?

A. No. XMLHttpRequest is only part of the Ajax equation. XMLHttpRequest is the technical component that makes the asynchronous server communication possible; Ajax is our name for the overall approach described in the article, which relies not only on XMLHttpRequest, but on CSS, DOM, and other technologies.

Q. Why did you feel the need to give this a name?

A. I needed something shorter than “Asynchronous JavaScript+CSS+DOM+XMLHttpRequest” to use when discussing this approach with clients.

Q. Techniques for asynchronous server communication have been around for years. What makes Ajax a “new” approach?

A. What’s new is the prominent use of these techniques in real-world applications to change the fundamental interaction model of the Web. Ajax is taking hold now because these technologies and the industry’s understanding of how to deploy them most effectively have taken time to develop.

Q. Is Ajax a technology platform or is it an architectural style?

A. It’s both. Ajax is a set of technologies being used together in a particular way.

Q. What kinds of applications is Ajax best suited for?

A. We don’t know yet. Because this is a relatively new approach, our understanding of where Ajax can best be applied is still in its infancy. Sometimes the traditional web application model is the most appropriate solution to a problem.

Q. Does this mean Adaptive Path is anti-Flash?

A. Not at all. Macromedia is an Adaptive Path client, and we’ve long been supporters of Flash technology. As Ajax matures, we expect that sometimes Ajax will be the better solution to a particular problem, and sometimes Flash will be the better solution. We’re also interested in exploring ways the technologies can be mixed (as in the case of Flickr, which uses both).

Q. Does Ajax have significant accessibility or browser compatibility limitations? Do Ajax applications break the back button? Is Ajax compatible with REST? Are there security considerations with Ajax development? Can Ajax applications be made to work for users who have JavaScript turned off?

A. The answer to all of these questions is “maybe”. Many developers are already working on ways to address these concerns. We think there’s more work to be done to determine all the limitations of Ajax, and we expect the Ajax development community to uncover more issues like these along the way.

Q. Some of the Google examples you cite don’t use XML at all. Do I have to use XML and/or XSLT in an Ajax application?

A. No. XML is the most fully-developed means of getting data in and out of an Ajax client, but there’s no reason you couldn’t accomplish the same effects using a technology like JavaScript Object Notation or any similar means of structuring data for interchange.

Q. Are Ajax applications easier to develop than traditional web applications?

A. Not necessarily. Ajax applications inevitably involve running complex JavaScript code on the client. Making that complex code efficient and bug-free is not a task to be taken lightly, and better development tools and frameworks will be needed to help us meet that challenge.

Q. Do Ajax applications always deliver a better experience than traditional web applications?

A. Not necessarily. Ajax gives interaction designers more flexibility. However, the more power we have, the more caution we must use in exercising it. We must be careful to use Ajax to enhance the user experience of our applications, not degrade it.

Jesse James Garrett is the Director of User Experience Strategy and a founder of Adaptive Path. He is the author of the widely-referenced book The Elements of User Experience. Jesse’s other essays include The Nine Pillars of Successful Web Teams and Six Design Lessons From the Apple Store.

Form: http://www.adaptivepath.com/publications/essays/archives/000385.php

AMFPHP

2006-09-20T00:05:00.000-07:00

AMFPHP is an open-source Flash Remoting gateway. It’s fast, reliable, 100% free and open-source. Flash Remoting is a technology built into the Flash player core that enables sending data between the server and the client seemlessly. If you've built XML-based RIAs you know how much of a pain it can be to serialize the data, debug, and integrate into your application.With Flash Remoting, you can call remote methods from the Flash client and the arguments will end up in the native remote language, and will come back to Flash correctly typed, so there's no messing with serialization at all.

You also get to use the wonderful NetConnection debugger, which shows you exactly what's being sent between the client and server. Remoting uses AMF, a very lightweight binary format that cuts the bulk out of packets, meaning data exchange is a lot faster than with XML. All in all, Remoting is the way to go if you're looking to build robust, fast and secure Rich Internet Applications.

AMFPHP is a complete implementation of Remoting for PHP with tons of features built-in to make creating Remoting apps a whole lot simpler. A distinguishing feature of AMFPHP is the built-in service browser, which you can test out live here, which makes testing asynchronous apps and generating stub code a click away. You can read more about why AMFPHP and Remoting rock. Or read more about the AMFPHP project.

from: http://www.amfphp.org

Flash Remoting MX

2006-09-20T00:03:00.000-07:00

Macromedia Flash Remoting MX provides the connection between Macromedia Flash and your web application server, making it fast and easy to create Rich Internet Applications. With its powerful yet simple programming model, you can easily integrate rich Macromedia Flash content with applications built using Macromedia ColdFusion MX, Microsoft .NET, Java, and SOAP-based web services.

from: http://www.adobe.com/products/flashremoting/

Hello

2006-09-20T00:02:00.000-07:00

Hello

My first blog in real life.

Started :)