It seems like a MonoRail implementation of the UpdatePanel is fairly high for people coming to MonoRail from the WebForms world. I am doing a project that uses Update Panel fairly extensively, and I can see why, it is really nice way to add Ajax capabilities to your web form. I started to look into what it would take to implement it with MonoRail, and I came to two conclusions:

• The technical challanges on the server side are minor, on the client side it is more of an issue, but not hugely so.
• The default architecture for UI in MonoRail basically makes it a non applicable.

I guess that I should explain.

The Web Form architecture is constraining the page to mostly interact with the page using post backs. There is a whole mechanism at both client and server side that is used to make this happen, which is what the Update Panel plugs into. This means that programming concepts such as AutoPostBack=true are very common on the WebForms world, and a great deal of work is done on the same page.

MonoRail, on the other hand, doesn't place such constraints, and the default architecture for the UI is radically different. Instead of interacting mostly with the same page, mostly using postbacks, you tend to have a more relaxed model, where you usually talk to the controller, and that chooses one of several views to send your way.

When I say "talking to the controller", I mean issuing requests to the application, most often, Ajax seems to be the choice for that, but moving between actions and views using POST/GET is fairly common as well. While you could build the views to work in the same manner as Web Forms, I have hard time thinkning about good reasons why you would want to do that.

So, I hope we can agree that the default architecture between the two is hugely different. Now, let us go back to the update panel request. While the mechanics may not be the same, it is fairly common to want to replace part of your page. And it wouldn't be nice if MonoRail made it hard. Well, as it turn out, it doesn't.

In my MonoRail web cast, I have shown how it can be done, you have a piece of the UI that you want to replace using Ajax. Let us take Fowler's refactoring approach:

• You decide that you want to update a part of the UI dynamically.
• You extract that part into a separate view (mostly involving Cut&Paste)
• You call the new view from the old view
• You create a new method on the controller that would rendner the new view and return it.*
• On the UI, you create an Ajax.Updater element that would call the new method on the server (and automatically replace the part of the page with the returned result).

* There are several ways to do it, a new method is one, specifying different view for the same method is another, which I sometimes like more.