Skip to content
It's like Ruby on Rails, but with ActionScript and beans and cheese and toast...
ActionScript Ruby
Find file
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.
ActionPack
examples/flex
.gitignore
README.textile

README.textile

Beans On Cheese On Toast

It’s like Ruby on Rails but with ActionScript – and Beans. and Cheese. and Toast.

OK – there aren’t actually Beans or Cheese or Toast, but it is essentially ActionScript on Rails – delicious stuff piled on top of a flexible platform.

Guiding Principles

The fundamental principles that guide this architecture are as follows:

State is bad

Rich client systems are all flawed in that they force the developer to manage complex, nested state when in most cases, all they really need to be interested in is routing user gestures to the appropriate behavior. With the right system in place, complex state can emerge, without necessarily being managed by implementors.

The observation is that stateless client/server systems that communicate over HTTP are able to have massive complexity emerge from simple, singular, comprehensible request/response processes.

The theory underlying this system, is that one may be able to replicate the same client/server architecture within the context of a single rich client in order to alleviate many of the problems associated with complex state.

Duplication is bad

We have systems and architectures in the Flash/Flex world today that relegate us to almost copy and paste implementations of one boilerplate after another. If the only difference between a multitude of classes are their names, I say our systems are badly broken. The computer is the appropriate tool for dealing with duplication, humans are not. Let’s help the computer manage boilerplate and duplicate behavior with better architectural trade offs.

Strong typing doesn’t deliver on it’s promises

While this opinion is certainly contentious in some circles, in this architecture, it will be treated as a given. The problems that strong typing attempts to solve are more appropriately solved with better, simpler architectures, and the problems that strong typing introduces are often worse than the cure. I’d rather not get into all the murky details of this debate here, so if you’re interested in hashing it out, Wikipedia is as good a place to start as any.

The Roadmap

First thing is routing

One of the fundamental almost hidden features of Ruby on Rails is its routing architecture. The ability to transform simple, human-readable strings or commands into complex, predictable responses without forcing the developer to spend long, tiresome hours writing tedious, fragile glue and wiring code, is nothing short of amazing. This seemingly simple implementation decision is really what makes working with a Rails application such a pleasure.

Second is modeling

Boilerplate, duplicate code is at best tiresome and worst, a fragile place where bugs sneak into an application. While the model layer of a rich client usually does not map exactly to the domain on the server, we should work to minimize the amount of boilerplate required in our client system.

Third is the services

There is always a contentious problem around getting data into and out of a rich client. Formats, processes, patterns. These decisions all come into play. Ideally, our rich client models will speak RESTful HTTP, and integrate most seamlessly with Rails, but also play well with other servers.

Something went wrong with that request. Please try again.