Over my head

A bunch of dairy farmers want to increase milk yield so they hire a physicist (who they are told understands all things and can model anything) who spends a year studying cows, their diet, yields, and slowly understanding everything there is to know about dairy farming.

After a year he gathers the farmers together to present his findings and starts his lecture by drawing a circle on a blackboard and saying "Imagine a perfectly spherical cow..."

I wonder how many companies are today scrambling to fix hard coded VAT values in their ecommerce apps.

Hands up.

Gordon Brown doesnt know what he's done :)

I'm looking at building a couple of apps (outside of my day job) that will help my brother with his job. The first application will need a rich desktop like interface and so I'm investigating my options.

• Build upon the application framework I've built - this is MVP based which means its highly testable and has good seperation of concerns. It supports templatable views, binding, observers, code generation (via ruby) and is based upon dojo so has access to all the lovely widgets that dojo provides.
• Use an existing framework.

So before I make a decision, I need to research the existing frameworks and define my requirements.

1. I want an application framework. A framework that lets me build applications rather than add nice effects to my web pages.
2. The framework should abstract away the concepts of html, css and the browser.
3. I'm not designing a web page, so for me its perfectly acceptable for my application to look like a windows app or a OS X app. In fact this is desirable since it should mean that my brother will instantly know how to use the application.
4. The framework should not be closed source or depend on a browser pluggin.

So I'm not using:

• Flex (4),
• sliverlight (4),
• extjs (4),
• scriptaculous (1),
• moo tools (1)
• dojo(1)

Note that I have marked each technlogy with a number which refers to my requirements defined above. So, this leaves me with:

• Sproutcore
• Cappucino
• Open laszloa
• 1 million other RIA framworks I'm unaware of.

So now I've reduced my area of research down to 3 frameworks. This post will become part of a series which I will investigate these 3 frameworks. The series will serve mainly as a scratch pad, but hopefully may help others.

This remainder of this blog post will discuss my initial thoughts on Sproutcore based upon a few hours reading around and mucking around with code.

Sproutcore Pros.

You write your application prodiminantly in JavaScript.

I dont have to learn an new language!

The framework is based upon MVC.

I like this pattern, I've used it a few times and developed frameworks based upon it. Its simple and usually only the views are difficult to test. I'll talk about views, controllers and models in more detail later. For a good definition of MVC, read this wikipedia article

Its backed by a big boy (Apple)

This means its probably going to be around for a while and should have some money pumped into its development. Apple have in the past branched existing open source projects, invested and changed the licence on the branch. I dont think this will happen here.

Gem

Its installed as a gem and I can generate my application stub, controllers etc at the command line.

Models - Binding and Observing

Sproutcore uses a similar approach to binding model properties to controllers, models and UI as Cocoa bindings.
Its easy to "mark" a function as an observer of a property on any given object.
In order to notifiy an observer of a change to any of your models properties, you are required to get and set property values on the model via two inherited methods, get and set.
To get a property "title" on a model called myModel, I code: myModel.get("title").
To set a property value I call myModel.set("title", "new value here").
This may seem annoying at first since, quite rightly, you will realise that you could just code myModel.title="new value here".
However, the set method is not just setting the properties new value, its also informing all observers that the value has changed.

This is incredibly powerful since, for example, views can be kept synchronised with any model they are observing.

Views

View templates are written as rhtml files using templating language called Erubis (ROR uses this, so I'm familiar with the syntax).

Controllers

These appear to be standard MVC controllers.

Sproutcore Cons

You write your application prodiminantly in JavaScript.

While the amount of css and html I've written so far within sproutcore is small, I'm not really abstracted away from the underlying technologies that the browser interprets.

Look

The widgets are UGLY in comparison to those generated by extjs and dojo! I expect this to change!

Documentation is scarce.

This isnt a massive deal, since I can just look at the sproutcore source, although a few more best practice tutorials would be helpful. This may be a problem for developers who are used to the quality of documenation usually associated with commercial frameworks or more establish opensource libraries such as dojo.

Real World apps

The only application I have found that it is available to the public thats built with Sproutcore is the demo photo viewer. This is quite slow and clunky and I hope it isnt a good representation of what can be achieved with Sproutcore. Its a poor show in comparison to 280 slides, a world real world application built with 280North's Cappucino

.

And so..

Now I'm going to actually start developing a simple application using sproutcore. I'll write a follow up to this post with opinions based upon 12 or more hours development time. Should provide me with a more informed opinion and I expect the cons list to fill up a little

Suppose I have an object instance called person, which has an instance method called yelp.

To call this method, in objective-j, I code:

[person yelp];

In most languages if person is null (or in this case nil) calling yelp would result in an exception being thrown.

Not in objective-j. The method* yelp isnt called.

Thats just wierd.

*Note that method calls are referred to as messages in objective-j.

My client has charged me with the task of building an application which solves a problem.

A warehouse management application perhaps.

So, I'm going to deliver the applications interface over the web because my client doesnt want to manage the installation and management of software across their 3,000,0000 warehouses.

Further they wont allow me to install 3rd party browser plugins - all I can rely on is HTML, CSS, JavaScript and HTTP.

So I cant use Flash or Silverlight.

Also, the .NET framework isnt available on the client machines. Java isnt either.

There goes ClickOnce and Java Web Start etc etc.

So what do I do?

Shit.

Recently I wrote a little MVP application framework on top of Dojo. It worked well. Nice seperation of concerns, testable etc etc.

Before that I wrote an MVC framework on top of the clientside Microsoft AJAX framework.
That worked okay too. The codes horrid.

I worked with extJS, but then they started to play with their licence...

Before that I wrote a.....

Infact for almost every major web application I've had to write an application framework on top of some other framework/library.

The underlying framework provided code that attempted to hide the fact that the different browsers were... different.

My framework would provide common services to the developer and enforce a development style for the team to work within. Literally an application framework.

The fact that I felt like I had to write an application framework was annoying in itself.

Why hasnt someone whose cleverer* than me done it? If they have done it, why dont I know about it?

Further, the underlying frameworks didnt completely abstract the differences between the browsers and they seemed focused on enabling developers to build small web 2.0 esq additions to their web pages rather than enabling me to build fully formed applications.

In each case, the project started well, however later down the line, browser related issues ALWAYS cropped up.

For example, IE6's piss poor JavaScript engine prevented me from building large DOMS.

The application in question used tabs, probably like the browser you're using. As more tabs were loaded, the app slowed down.

I solved this problem by disconnecting unfocused tabs from the DOM and re-attaching them when the tab was focussed. At this point my layout manager was told to redraw the layout to ensure that scaling had occured correctly.

So in each case I had to solve problems that werent in the business domain. In most cases these issues took up the majority of the time.

Desktop application development isnt generally like this. Sure ,there are still issues, but they often arent as frequent and as complex to solve.

I should be able to develop a web based application where the biggest problems I have to solve are in the business domain.

So, it is possible to write a large scale web base application, google and friends have proven this.

BUT..... its NOT trivial and the majority of the problems you have to solve are down to the platform (browser).

Also, if I'm building small web apps such as RSS feed readers, then I can do so quickly and easily. Dojo and ExtJs are all good enough to do this.

But as soon as you're handed a enterprise scale app your development cycle will probably begin to unravel.

Of course, you guys may be all geniuses and may solve these problems easily and quickly. If so, I havent met any of you :)

At the moment I'm investigating technologies in preperation for a technology referesh of a applications user interface.

Cappucino I'm told, is the solution to my problems.

* Most people are cleverer than me.

I've been involved in developing a AJAX framework which sits on top of the Microsoft AJAX libraries.

This contains a layout manager which manages the DOM, so for example if the user re sizes the browser window, the layout manager will manipulate the DOM to ensure the correct layout.

In most cases it merely sets the height and width styles on DOM elements and applies CSS classes.

When testing with IE6 my colleague noticed that any images managed by the layout manager (i.e. tab headers) were flickering and that resizing was generally slow.

I assumed that the layout manger was to blame. It wasn't directly.

All images associated with the layout manager are referenced in CSS classes to allow for "themes".

The layout manager will perform the following sequences of actions:

• Apply CSS to a DOM element - if the CSS references an image, your browser will request the file from the server
• Next, remove the CSS class from the DOM element...
• Then, if re-apply the same CSS class again to the previously mentioned DOM element - you would not expect the image to be requested again.

This is not the case for IE6.

Every time the layout manager was re-applying the same CSS class to the DOM, the associated resources were being re-requested.

We used fiddler to confirm this.

We added a expiry header to all the referenced images (IIS configuration) and now the layout manager runs *almost* as quickly in IE6 as it does in IE7.

Woot.

Background.
ViewState is a collection of data which enables a control/page etc to persist properties across postbacks.

Like a HashTable, the ViewState contains key value pairs.

The ViewState is represented across posts by a hidden form field.

The data stored within this hidden field is referred to as a StateBag.

TrackViewState

The ViewState object exposes a method called TrackViewState.

Only after this method is called upon the ViewState, are items stored within the ViewState marked as dirty when a keys value is changed.

New key value pairs will also be marked as dirty from this point.

TrackViewState and the page/control life cycle

TrackViewState is called during OnInit.

After this point, data in the StateBag is applied to the ViewState.

This means that if you modify the ViewState after OnInit, the data will be persisted in the StateBag and will be available after a subsequent postback.

However if you modify the ViewState before OnInit, or during OnInit your changes will NOT be stored in the StateBag.