At the moment, the Castle Project is actually host to a number of separate projects. Monorail and Active Record for example, work extremely well together but Monorail does not require Active Record; the same can be said for Windsor.

Previous releases of Castle have contained all of the child projects in one package. In future, this may not be the case. The Castle PMC have decided to split each project off, while still keeping them under the Castle banner. This has the immediate advantage than a Windsor release does not have to wait for a Monorail release, which is surely going to increase the mobility of Castle as a whole. While some sections may lag behind for a while, segments are free to move at their own speed.

It’s been a while since a full Castle release, and I feel that many developers wait for such releases before adopting a project. More frequent official versions of the Castle components could increase adoption and interest in the overall brand, which can only be a good thing.

I wanted to quickly spike an idea that I had last night, and while normally I’d use Monorail, I thought it was high time I took an interest in ASP.NET MVC. It took about ten minutes for me to stumble to a halt.
(more…)

I’m working with the awesome ExtJS framework again, creating an administrative interface to a huge amount of data. Each screen on this interface is basically a pageable grid with an editor window which pops up if you click a row. The grids can be sorted, and a separate filter area allows you to narrow down the items displayed on the grid in a manner unique to each screen.

The first time I wrote something like this using Monorail and ExtJS, I’d estimate that the javascript code was about 300 lines and the C# was maybe 150. Bear in mind that these screens, while differing due to the data being displayed, were essentially just CRUD interfaces. That means that to create a new screen, I’d be copying and pasting a lot of very similar code.

I’m sure you’ve been in this sitation before. If you’re really only going to be using this code in one or two places, there may be little value in making it a bit more generic. However, as soon as you break past that and find yourself copying and pasting the same code over and over, it’s a sure sign that you need to step back and pull out common functionality. That’ll provide three benefits:

1. Less code means less to maintain
2. It’s easier to create a new screen (copy/paste is never nice)
3. Code reuse means silly errors are more quickly caught

In my situation I first created an abstract CrudController class, which accepts a type parameter of the entity which you’re Creating, Reading, Updating and Deleting. Later I changed this class to CrudController to allow me to add search specifications in a generic way. This class contains all of the actions you’d expect for CRUD as well as some for writing out JSON strings.

In the ExtJS side of things, I was able to subclass the GridPanel component and have a component that would automatically have a PagingToolbar, a particular click handler, and other default settings. I was also able to tailor the arguments to reduce the amount of code I needed to write to create it. Here’s a simple example.

this.grid = new App.standardGrid({
	cm: new Ext.grid.ColumnModel([{
			header: 'Id',
			dataIndex: 'Id'
		}, {
			header: 'Created',
			dataIndex: 'CreatedOn',
			renderer: function(val) {
				return val.format('l d F Y');
			}
		}]),
	fields: [
				{name:'Id', type:'int'},
				{name:'CreatedOn', type:'date'}
			],
	url: '/admin/quote/getjsonlist.castle',
	edit: this.edit,
	scope: this
});

Secondly, I could create a subclassed Ext.Window which would give me a better reusable editor dialog. Here’s how I defined that:

App.window = Ext.extend(Ext.Window, {
	height: 500,
	width: 500,
	modal: true,
	resizable: false,
	draggable: false,
	closable: false,
	bodyStyle: 'background: #eee'
});

As you can see, this is just a matter of giving sane defaults for a modal window, but later I subclassed App.window itself to create App.formWindow which was much more powerful.

These three steps dramatically reduced the code required to create a new admin screen in my application. More importantly, I cut the amount of boilerplate code I was copying every time to zero, which meant the code I did have to write was all important stuff. Less wading through identikit javascript means I’m a much happier developer!

Mirvoda Sergey has announced NHAML for Monorail. Andrew Peters brough NHAML to ASP.NET MVC last year, and now us Monorail users can enjoy using a very different kind of templating engine to the others available for Monorail. Check out this HAML tutorial if you’d like to familiarise yourself. Thanks to Mirvoda Sergey!

Recently Plastiscenic has been asked to quote for a fairly large project, and if it comes off I’ll have the chance to work on it from the ground up, using whatever technologies I think are best suited.

(more…)

I’ve blogged before about the enabling features of Monorail and Active Record, part of the Castle stack. Another piece of software which is making my development life a pleasure is ExtJS – a collection of javascript goodies created by Jack Slocum and his team – and when these three things come together, watch that coding fly…. I’ve created a screencast in which I demonstrate how easy it is to build a paging, sorting, filtering, AJAX-powered grid using ExtJS and Castle, and you can watch it here. It’s 20 minutes long but filled with goodness – and a couple of hacks (forgive me . Don’t forget to check out all my past screencasts too.

UPDATE: As requested in the comments, you can MonorailExt1 VS Project directory of this.

Ayende quickly posted something called HotSwap, which is a little snippet of code which uses a FileWatcher, Windsor, and on-the-fly code recompilation to increase your productivity. With ASP.NET, building your code changes causes an appdomain restart, and you will typically have to wait a few seconds for the appdomain to come back up before the browser will display your changes. This basically means that when working with ASP.NET, there are no quick code changes – you always have that four second wait till you see the effects.

HotSwap resolves this by building your code for you when it detects a change. Using Windsor it can swap out the old assembly containing your code and replace it with a new dynamically created assembly containing your new code – all automatically. The key advantage of this is that it’s all done in-memory, and none of the DLL files in the bin directory change. This means that you won’t trigger an appdomain restart and your changes can be seen almost instantly!

I was really impressed and excited by this approach so I did a very quick screencast on the topic. I was using the Castle RC3 MSI, and created a project with Windsor integration enabled. This code only works for your controllers at the moment, but a lot of the time that’ll be where you need this kind of productivity boost.

Ayende – cheers for this, and I’m sorry if I pronounced your name wrong as I’ve only seen it written down!

UPDATE: I’ve uploaded the HotswapTest Project from the screencast. You’ll probably need the Castle RC3 MSI installed to build it.

This screencast takes a break from the theme of the past few in the series and examines two of the projects within Castle’s Contrib project – CodeGenerator and ActiveWriter.

http://colinramsay.co.uk/screencasts/5/

The Monday morning blues mean this cast is a little less fluent than the others, but I hope you find it useful. Read on for some of the code snippets used in the screencast. (more…)

In the fourth screencast in the series, Validation and Much More, I talk about how to add validation to your objects and how to show validation failures to the user. There’s more on FormHelper and I introduce the PropertyBag and Flash. This is a consolidation episode, where I take the work we’ve done so far and fill in some of the common blanks. It’s very much reliant on having seen the previous screencasts as I am using the same Visual Studio project throughout.

http://colinramsay.co.uk/screencasts/4/

One point of relevance: the use of ActiveRecord with Monorail is completely optional. I’ve used it here because I feel they integrate well, but if you’ve got another persistance framework which you’d prefer to use then that’s possible too!

This screencast shows many of the small but very useful aspects of Monorail, and shows off the awesome binding abilities of FormHelper. For the next screencast I plan on taking a break from the normal series and into the Contrib project to talk about ActiveWriter and the CodeGenerator, projects which can make working with Monorail even easier!

The third screencast in the series talks about the Databind attribute in Monorail, which allows you to bind values to objects. I also extend the example to use ActiveRecord, and save the databound object to a database.

http://colinramsay.co.uk/screencasts/3/

It begins to highlight some of the more advanced uses of Monorail, and introduces the Castle implementation of the Active Record pattern. In the next screencast, I’ll be consolidating on the topics I’ve covered so far and address some of the real work problems which Monorail can easily solve.

One point of relevance: the use of ActiveRecord with Monorail is completely optional. I’ve used it here because I feel they integrate well, but if you’ve got another persistance framework which you’d prefer to use then that’s possible too!

Don’t forget to watch Getting Started with Monorail and Using Monorail, the first two screencasts in the series.