Using Multiple WebForm Views with a Resource

In OpenRasta, you need to define your resources individually. A resource in OpenRasta is simply a class you create that handlers will deal with. Each resource may have any number of URIs, and any number of codecs. A codec is a piece of code responsible for rendering a resource’s representation, and this example uses the WebForms codec:

ResourceSpace.Has.ResourcesOfType<UserRegistration>()
    .AtUri("/registration")
    .HandledBy<UserHandler>()
    .RenderedByAspx("~/Views/User/New.aspx");

This defines a UserRegistration resource. It declares where to find it, what handler is responsible for its behaviour, and a page to render it.

In this scenario, whenever a user has successfully registered, it’s quite usual to return them to a page welcoming them to the world of splendour that you’ll provide them now that you have all their personal details. This welcome page usually contains the same information that you collected previously.

The initial (and in many scenarios, sane) reaction is to create a separate resource / handler / view couple to render the Thanks page. This is indeed accurate; the thing that I serve to the client is a document with a “Thank you” message, complete with blink tags.

Another point of view – and the one I usually favour – is to consider those various elements as different views on the same resource. From a ReST point of view, each of those views will be a resource in its own right, but from a programming perspective, OpenRasta will treat them as being the same entity against which to operate.

How do we define multiple views on a resource? The first piece of the puzzle is to use the capacity baked into the !WebForms view engine to store a list of multiple views. We can change the registration ever-so-slightly by using the generic notation for registering the view:

ResourceSpace.Has.ResourcesOfType<UserRegistration>()
    .AtUri("/registration")
    .HandledBy<UserHandler>()
    .TranscodedBy<WebFormsCodec>(new
    {
        index = "~/Views/User/New.aspx",
        thanks= "~/Views/User/Thanks.aspx"
    });

The registration looks very similar. The RenderedByAspx method you saw earlier is shorthand for the full notation using TranscodedBy<T> which lets you plug in many different codecs per resource. However, we aren’t finished yet.

The anonymous type itself defines view names (index and thanks) that will be passed to the !WebForms codec. By default, that codec always uses a view named index (or default) for the default view to select. The question is, how do we get the framework to choose those other views? There are two ways to accomplish this.

One approach is to use URI path segments. If I typed the URI http://localhost/registration;thanks the ’’’thanks’’’ part is called a path segment, and is always separated by a semi-colon. If you go and try that now on your OpenRasta website, it won’t work out of the box. You need to go and enable it by adding a UriDecorator.

ResourceSpace.Uses.UriDecorator<PathSegmentAsCodecParameterUriDecorator>();

URI decorators in OpenRasta are classes that lets you manipulate URIs before a request is processed. They are used for implementing various features, such as content negotiation via file extensions, localized URIs, and whatever else you may think of.

So, all is good, we can now go to /registration;thanks and see the Thanks.aspx page rendering a resource.

A different approach is to establish a separate URI for each view and assign a name which matches those provided to TranscodedBy<T>, as follows:

ResourceSpace.Has.ResourcesOfType<UserRegistration>()
    .AtUri("/registration").Named("index")
    .And.AtUri("/registration/thanks").Named("thanks")
    .HandledBy<UserHandler>()
    .TranscodedBy<WebFormsCodec>(new
    {
        index = "~/Views/User/New.aspx",
        thanks= "~/Views/User/Thanks.aspx"
    });

This example does not require the Uses statement to enable URI decorators. The codec will automatically choose the view according to the names based on the URI being accessed. However, the same resource and handler classes are used for all of the URIs. This is probably more in keeping with the REST architectural style.