Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/lukebayes/beansoncheeseontoast

It's like Ruby on Rails, but with ActionScript and beans and cheese and toast...
https://github.com/lukebayes/beansoncheeseontoast

Last synced: 3 months ago
JSON representation

It's like Ruby on Rails, but with ActionScript and beans and cheese and toast...

Awesome Lists containing this project

README 

        
h1. 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_.



h1. Guiding Principles



The fundamental principles that guide this architecture are as follows:



h3. _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.



h3. 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.



h3. 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":http://en.wikipedia.org/wiki/Type_system#Controversy is as good a place to start as any.



h1. The Roadmap



h3. 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.



h3. 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.



h3. 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.