It looks like a lot of the people working on MonoRail has at least some RubyOnRails experiance, this means that there usualy a way for people coming from mostly WebForms background to map the concepts they know to the MonoRail lingo.

Just to set the record straight, MonoRail is runing on ASP.Net platform, no perl involved.

Here is a mostly random attempt to map some of those concepts, note that I am talking about views only here;

• Master Page
• Master Page with multiply content areas
• View State
• Page LifeCycle Events
• User Controls
• Server Controls

Feel free to add more subjects, and I'll try to answer them as well.

Master Pages:

Master Pages are a way to share a common look and feel between pages, without duplicating the HTML. In MonoRail speak, they are called layouts, and they are settable on a controller or action granularity (or directly through code, if that strikes your fancy).

Master Pages with multiply content areas:

But wait, you are using a master page that is filled with more than a single location (for instnace, the main content and a header). In MonoRail, the same functionality is provided using a main content area ( ${ChildOutput}, for instnace ) and the use of normal variables that are filled by the view using a capture for component, like this:

And in the layout:

The output of those will be:

View State:

View state doesn't exists, and good riddance. The web isn't stateful, the framework shouldn't lie to you and say that it is. When you need state, we have a powerful set helper classes that help provide you with the functionality that you desire.

Page LifeCycle Events:

They don't exist either, along with their complexity and the head aches that they bring. MonoRail has the following happening in a request: before filters, action, after filters, view rendering. And you usualy can ignore the filters.

User Controls:

Sometimes called partials, subviews, or macros in MonoRail speak (although each has a specific meaning), they provide the same functionality. A simple example of using one may be:

MonoRial's views can be easily embedded in an assembly, so it is trivial to take those from project to project without having to copy the sources themselves.

Server Controls

Those are called ViewComponents in MonoRail, and they provide a set of UI services for the application. Because in MonoRail the views are not working in a complex object hierarchy, it means that the view components are free to do a lot of interesting stuff that are harder to do in the WebForms model. Take for example the CaptureFor component, which output its content into a variable, which can later on be used by different parts of the views / layout.

No, no perl involved.