Tuesday, December 16, 2008

Announcing JumpShip 4.0

JumpShip 4.0 has been released. The new version, although not significantly different from the last, takes a slight philosophical departure from the last. And since it was a significant enough change to possibly break compatibility with older version, I've decided to call it a new major revision.

The most significant change in JumpShip 4.0 is that, now the framework actively discourages the use of Singleton that have become widely popular in other frameworks. Although JumpShip has always touted it's diminished use of Singletons and therefore it's advantage when using it a an application framework or a component framework, the framework itself has never taken an opinion on the use of the Singleton pattern and in face included a few Singletons itself.

There has been a recent backlash against the Singleton pattern in the design pattern world ( See the post on http://www.as3dp.com, Scott Densmore's post, or Miško Hevery's thoughts ). The Singleton has been used as a substitue for global variables ( you know, those things good programmers never use ), and have all of the drawbacks of globals. They can be very convenient but make your code hard to read, hard to test, and hard to debug.

For all these reasons, the latest version of JumpShip has removed ( almost ) all of the Singletons in the Framework. The one exception being the JSRuntimeEnvironment class which is used to make your application behave slightly differently ( logging, throwing errors, etc. ) in a development environment than it does in a production environment ( stability at all costs ).

Eliminating Singletons meant eliminating some classes from the framework, namely the service locator classes, and changing others, JSApplicationState and JSRailsGatewayBase, so that they do not have Singleton implementations.

This has effected the Rails Gateway classes the most and hopefully made the easier to use. You now no longer need to extend JSRailsGatewayBase in order to use it. Instead of having to define a service locator in the implementation, you simply pass in the base path of your Rails app when you create a new JSRailsGatewayBase instance.

The JSApplicationState class is also no longer a Singleton which means you can have as many different state objects as you want.

The other big change in JumpShip 4.0 is that now the JSDataRecord class recognizes when another JSDataRecord instance has been added as an attribute and will automatically listen for data binding events, rebroadcasting them upward if one is received. This allows multi-dimensional data structures that maintain data binding all the way down the tree. Although, JumpShip still encourages flat data structures, there may be occasions when you need data binding for multi-dimensional data.

Finally, JumpShip 4.0 includes improved documentation and a few bug fixes for potential memory leaks.

8 comments:

Anonymous said...

Jamie, there's a difference between "it's" and "its". it's = "it is".

http://en.wiktionary.org/wiki/it's

http://en.wiktionary.org/wiki/its

See usage notes under "its":

http://en.wiktionary.org/wiki/its#Usage_notes

Unknown said...

Hi, I'm interested in using this framework to develop a Flash CMS application. However, I do have a couple of questions. Jamie, if you read this comment, could you contact me at cyborgk [at] gmail.com ??? Thanks!

~David Powers

JumpShip said...

David,

Do you mind sharing your questions here so others might also benefit from the discussion?

Jamie

Unknown said...

Hi,

In general, I am looking for any examples of an actual application or 'real-life' code created with JumpShip that I could study.

Additionally, am I correct in thinking that there is typically only a single Controller class in an application?

Thanks,
~David

JumpShip said...

David,

There have been a lot of requests for more examples and I'm working on some right now ( coming soon I promise ).

As far as your controller question... One of the unique things about JumpShip is that it encourages multiple controllers. Whereas most other frameworks tend to make controllers singletons, or at least map their events through a singleton ( global ) event dispatcher, JumpShip controllers are not singletons and require you to register event dispatchers.

So long story short, there is no reason why you cannot have multiple controllers, each responsible for a particular piece of functionality in your application. In fact, I would encourage it.

Jamie

Unknown said...

Came across JumpShip while searching for frameworks. I am interested in the rails connector and no singletons design. How're those examples coming along? :)

JumpShip said...

John:

Please take a look at the docs page as well as the examples that are included in the framework download. Those should provide you with enough to get Rails connected an working with JumpShip.

I'm currently working on a twitter clone example.. stay tuned.

Anonymous said...

Really nice and impressive blog i found today.