Arp 3: Initial plans revealed

I've posted my initial plans for the next version of ARP on the ARP Mailing List for feedback and comments.

Here is the general outline, detailing the vision. For the full piece, including sample code, please see my email to the list.

What is Arp?

Arp is a simple yet powerful structural framework for creating Rich Internet Applications (RIAs) on the Flash Platform. Simplicity and DRY (Don't Repeat Yourself) are Arp's core tenets. Arp aims to boost developer productivity with code generation and introspection and integration with major application servers and databases. Whenever possible, Arp uses established Software Design Patterns. These include core patterns such as Controller, Business Delegate and Value Object. Arp favors convention over configuration -- this means that it uses intelligent defaults and naming conventions whenever possible. The ultimate aim is to bring the start-up time of a new RIA project close to zero and encourage best practices, test-first development for RIAs on the Flash Platform.

What's New in Arp 3?

Full-stack framework:

Creating and working with RIAs on the Flash Platform is now a piece of cake with the integration of Ruby On Rails-type functionality.

Arp 3 supports cross-platform code generation developed in PHP [Using Cake? CakeAMFPHP?], ActiveRecord-type database introspection, etc. for quickly getting up and running with your RIAs. Server-side support for the following languages is provided based on Flash Remoting:

ActiveRecord-style introspection is supported for the following databases:DRY:

One of the core tenets of Arp is simplicity. Arp is even simpler in its third incarnation and has gone DRY (Don't Repeat Yourself). This means that your ARP3 applications will have less code and thus lower risk.

Convention over configuration:

As part of DRY, Arp 3 favors convention over configuration. This was also a cornerstone of Arp 2, but we take it further here with the introduction of Requests.

Requests:

When a form in the view needs to make a request that will require business logic to be executed, it creates a new Request instance. A request is a special event. It bundles the necessary data for the request to be carried along with the request itself and specifies optional success and failure handlers to be notified.

The success and failure handlers *only* carry out view logic. Unlike Arp 2, no data handling, storages, update, etc. is done there.

Custom Controllers are now optional:

For most applications you will not need to create custom controllers for your application or for external forms. The new, DRY Arp's base controller class, along with the introduction of Requests will handle all the hard work for you.

Explicit Commands are now optional:

The new base Controller class and Requests make the explicit declaration of Commands redundant for most cases. Of course, if you would rather implement explicit Commands (eg. to use as part of a Memento pattern to implement Undo/Redo), you can.

Business Delegates are now a central part of the framework:

At the very basic implementation, a Business Delegate includes a reference to a remote service to which Requests will be proxied.

If you would rather carry out business logic on the client side in response to a request, just implement the necessary method in the Business Delegate and it will get called in place of the remote service (if any).

In the most advanced, you can use a map to specify multiple remote services for methods and mix in local method implementations too.

Business Delegates have success and failure methods for remote methods. Only model updates and other business logic are carried out here. (The view is notified of model updates via the bindings and not through explicit invocation of a public method as in Arp 2. This does not remove the need for success and failure methods on the

view, which are used purely to implement view logic in response to the success/failure of a request.)

Data Binding and the Model:

The model is updated from the Business Delegate and data bindings on the View [based on Christophe's code] (along with custom formatter functions, etc.) carry out view updates automatically.

External Forms:

Easy workflow for using external forms and registering them and their controllers with the main application.

Shared Libraries:

Supports transparent use of shared libraries.

Integrated unit testing:

Arp 3 includes the open source ASUnit unit testing framework and advocates test-first development.

Integrated logging:

Arp 3 includes the open source LuminicBox logger for logging.

IDE support:

Support and documentation for creating Arp 3 projects is provided for the following IDEs:

* Eclipse * FlashDevelop <-- Do we need anything special? (No?) * SePY <-- Do we need anything special? (No?)

* Others????

Compatibility:

Works with Flash, Flex 1.5 and Flex 2, ActionScript 2 (AS2) *and* ActionScript 3 (AS3). Use the same workflow regardless of which technology you're using. Applications based on Arp 3 are very easy to port between these technologies. (Note: Since Flex 2 and AS3 are currently in Alpha, these features may change in the future in line with Adobe's code changes in future alphas, betas and releases.)

Comments