Honest Illusion : monorail, C#

Portable Areas for Castle Monorail, Part 2

James — Thu, 01 Apr 2010 23:15:00 GMT

In our last episode, we discussed the PortableAreaController base class, which makes it simple to create a portable area using Monorail. In this installment, we put that class to use.

For the purposes of this example, the controller isn’t going to do anything useful – I’m not even going to bother with code in the actions. The different actions will display different views so you can see the effect, and I’m hoping you’ll just trust that you can put real code in the action methods.

[Layout("default","patest")]
public class PATest : PortableAreaController
{
    public void Page1()
    {         }
    public void Page2()
    {         }
    public void Page3()
    {         }
}

That’s our minimalistic example. If it looks a lot like an ordinary Monorail controller, that’s the idea. “PATest” is the name of the controller, which in the case of a Portable Area, is the name of the entire feature, so it’s be something like CoolWiki or MyForum.

The Action methods are identical to what you’d have in a normal controller. In fact, everything in the portable controller is just like it would be if this were a intrinsic part of a website.

The rest is just about putting the pieces together in the assembly.

Individual files (images, css files etc) should be placed in the root level of the project. When referencing then in a view, just added “.rails” to the end ( <img src=”${siteRoot}/PATest/autolist.png.rails” />)

View templates should be in a folder named after the controller, and layouts in a “layouts” folder --- just as if the root level was the website’s “Views” folder. You don;t have to do anything special to get Monorail to find them – that is handled for you by the base class.

All those files (not the CS files obviously) should have their Build Action set to Embedded Resource.

Note that when a view template is needed, Monorail will first look for a physical file in the website’s Views files, and failing there, search in the assembly. This allows the end user to override the embedded view templates with their own. In the example I’ve uploaded to the CastleContrib SVN repository, I’ve locally overridden Page2.

The same holds for layouts, which I’ve put to use in the example. I assumed that most sites will have a default layout for the site (which I further assumed is called “default”). The controller uses that layout and adds it’s own child layout. (The project should also define a simple default layout as just “${childContent}” just in case the website it’s being used in doesn’t define one.)

The PortableAreaController base class has been added to the ViewComponent project in the CastleContrib SVN repository. (Yes, I know it’s not a ViewComponent, but I didn’t want to create a whole new branch -- particularly not for just one file-- and ViewComponents were the closest available existing project). The PATest example shown here is a separate project under that branch, with the resulting Castle.MonoRail.PortableAreaExample.dll assembly added to the ViewComponent.TestSite project. Note that that assembly is the only file added to the website to enable this functionality, and the only other change was to add a reference to it into the web.config.

Share this post: Email it! | bookmark it! | digg it! | reddit!

Portable Areas for Castle Monorail

James — Thu, 01 Apr 2010 23:09:59 GMT

Recently I had read a blogger comparing Castle Monorail with ASP.NET MVC. He chose ASP.NET mainly because it supported Portable Areas while Monorail did not. As a supporter of Monorail, I was very offended by this, and decided to correct the problem. The first step… finding out exactly what a “portable area” was.

A Portable Area is a piece of functionality, with all pieces bundled up into a single assembly, which can be just “dropped into” an existing website. Think of a forum or a wiki. The idea is basically, I could just add wiki.dll to my site, and suddenly www.mysite.com/wiki just works.

Now, having a controller and its actions together in a single assembly is a basic design principle of Monorail (and essentially all of MVC design), so that part was done before I even began. The rest was a bit trickier.

I would have to store – and retrieve at the right times, the view template files, and all other associated files – images, style sheets, script files, etc.

Storing the files was in itself trivial -- .NET has a means built right it. The file just need to be added to the project as embedded resources. In Visual Studio, on the file’s property panel, set the “Build Action” to “Embedded Resource”.

Now that the files were in the assembly, we had to get them out of it. For views, which I had assumed were going to be the most trouble, this turned out to be simple, with the plumbing for it was already built into the Monorail framework. Apparently, someone had planned for portable areas, but never followed through. View templates are loaded by a class aptly called the FileAssemblyViewSourceLoader. It looks in the “Views” folder for the template, and failing there, looks among the embedded resources of the assemblies in its collection. However, nothing in the framework ever added an assembly to that collection, so this feature has always laid fallow.

The final feature was getting it to load a random file from the resources. Whenever I need to do something with a name not known in advance, a DefaultAction seems like the way to go.

With that, all the pieces were in place, I just had a wee bit of code to tie them all together. Defining a base class which a portable area could be derived from seemed the best approach.

  public class PortableAreaController : SmartDispatcherController

{

The first step was to override the Initialize() method, so that I could add this assembly to the list searched by FileAssemblyViewSourceLoader. The only trick here is we must make sure that the assembly is only added once, regardless of how many times the controller is initialized. And, while we are at it, we’ll also get the assembly name and a list of the resources and save them for later.

  private string[] resourceNames;
private string asmName;

public override void Initialize()
{
    base.Initialize();
    var asm = this.GetType().Assembly;
    resourceNames = asm.GetManifestResourceNames();
    asmName = asm.GetName().Name;
    var asminfo = new AssemblySourceInfo(asm, asmName.ToLower());
    if (!this.Context.Services.ViewSourceLoader.AssemblySources.Cast<AssemblySourceInfo>()
                            .Any(asi=>asi.AssemblyName==asminfo.AssemblyName))
        this.Context.Services.ViewSourceLoader.AddAssemblySource(asminfo);
}

Next is the DefaultAction. The idea here is that you request somefile.jpg.rails, and we pull somefile.jpg out of the resources, and stream it to the browser. In Monorail, a DefaultAction is a method which is called when no other method in the controller matches the action. In our DefaultAction, we’ll generate a resource name from the assembly name and the Action name. The Action is basically, the name of the “file” requested without the “.rails” extension, so if we ask for file “http://mysite.com/portable/myimage.gif.rails”, then the pseudo-file we are requesting is “myimage.gif.rails” which makes the Action “myimage.gif” which just happens to be the file we really want. The only tricky part here is the GetContentTypeFromExt() function. The problem is that there is a very simple way to do this --- which only works under Windows. Now, while the vast majority of web servers running Monorail are Windows based, Monorail is designed to also run under Mono (Linux). I couldn’t find a good portable way to handle this, so I just punted (check the source for dirty secrets).

[DefaultAction]
public void DefaultAction()
{
    string filename = asmName + "." + Action;
    var resourceName = resourceNames.FirstOrDefault(rn=> rn.Equals(filename,StringComparison.InvariantCultureIgnoreCase));
    if (resourceName!= null)
    {
        string ext = Path.GetExtension(filename);
        this.Response.ContentType = GetContentTypeFromExt(ext);

        Stream contents = this.GetType().Assembly.GetManifestResourceStream(resourceName);
        this.Response.BinaryWrite(contents);
        CancelView();
    }
}

This method is the controller’s Default action by virtue of the [DefaultAction] attribute. The name is arbitrary – DefaultAction just kept things simple.

And with that, everything you need to write a portable area in Monorail is neatly contained in a simple base class. Everything we’ve just gone over, you can now completely ignore.

Next, we discuss how you use this base class to write your own portable area.

Share this post: Email it! | bookmark it! | digg it! | reddit!

A ViewComponent extension for Castle MonoRail, Part II

James — Tue, 25 Aug 2009 00:44:00 GMT

This was intended to be a two-part article. It was just after I published the original article, I noticed that I’d left out a large part of ViewComponentEx. We continue…..

        protected bool RenderOptionalSection(string section) 
        protected bool RenderOptionalSection(string section, string defaultText)

Renders the named section of a block component – if the section is present. If not, it just silently returns. The second overload lets you provide some text to be rendered, if that section isn’t given:

RenderOptionalSection("tablestart", “<table>”)

Returns true if this section was rendered; false, if the section was present. This seems like a very simple method (and it is), but if your component has a number of different sections for styling (such as the SmartGridViewComponent, which has 18!), this can do wonders to streamline your code.

        void RenderComponent<VC>(params string[] componentParams) where VC : ViewComponentEx, new();
        void RenderComponent<VC>(IDictionary componentParams) where VC : ViewComponentEx, new();
        void RenderComponent(ViewComponentEx component, params string[] componentParams); 
        void RenderComponent(ViewComponentEx component, IDictionary componentParams);

This implement, with a slightly different syntax, a technique originally devised by Joey Beninghove. The idea is to make a ViewComponent which is composite of several other VCs. The basic syntax is

 RenderComponent<LinkSubmitButtonComponent>("linkText=Search",
             string.Format("formToSubmit={0}", searchFormName));

However, the various overloads allow using an already exist component object, and/or an already built dictionary of options.

Also include in the source file is the class ViewComponentUsingSiteMap which, like ViewComponentEx, is an abstract base use for creating ViewComponents, but I’ll hold off discussing that until I ready to talk about the VCs the derive from it.

Share this post: Email it! | bookmark it! | digg it! | reddit!

A ViewComponent extension for Castle MonoRail

James — Mon, 24 Aug 2009 11:21:08 GMT

I’ve been rewriting my website, njtheater.com, (very slowly) as a Castle MonoRail application. Along the way, I’ve written a number of ViewComponent and other elements. Many of these were of general use, so I’ve added them to the CastleContib project, and documented them in the using.castleproject.org wiki.

Two problem there: First, some of the items I wrote don’t fit into an exist category in CastleContrib (There’s one for ViewComponents, which I’ve stick a filter into, but putting a Controller base class there seemed wrong). Second, CastleContrib & using.castleproject.org seem to be somewhat of a black hole. No one seems to look there for information about the Castle Project (which is kind of a shame, since that’s exactly it’s purpose).

On the other hand, blogs posts about Castle are turning up everywhere. We’ve even now got an aggregated blog feed specific to Castle. So, I figured, I start using my blog to talk about what I’ve written.

In fact, one article I discovered on that aggregator was Andy Pike’s “Integrating Gravatar with Castle MonoRail” inwhich he discusses a Helper object for Monorail which creates Gravatars for use’s email addresses. It was written last January. The only thing is, I’ve written (and added to CastleContrib) a Gravatar component three months earlier. That was going to be the topic of my first MonoRail blog post (and I will be my second), but first, I figure I should talk about the base class I once for all my ViewComponents, which I’ve given the rather imaginative name of ViewComponentEx.

ViewComponentEx derives from ViewComponent, and can be used as a “drop-in” replacement for it, as the base class for your ViewComponents. It provides a number of simple methods to help building ViewComponents.

void ConfirmSectionPresent(string section);

Throws an exception if the given section is not present.

string GetSectionText(string section);

Get the text of a section as a string.

string GetBodyText();

Get the text of the body of a block component (without section)

void RenderTextFormat(string format, params object[] args);

Renders the text, formatted. Just like String.Format()

string GetParamValue(string key, string defaultValue);

bool GetParamValue(string key, bool defaultValue);

E GetParamValue(string key, E defaultValue) where E : struct;

Gets a parameter value, with a default. Overloaded to handle string, boolean, or Enum value.

Castle.Core.Logging.ILogger Logger { get; set; }

A property for the system Logger. Automatically wired by Windsor, if active and a Logger is defined in the container. Default to NullLogger, otherwise.

string MakeUniqueId(string prefix);

Makes an unique id. The given prefix is prepended to the generated number. The ID isn't actually guaranteed to be unique (which would require using all 32 digits of the guid). But this produce ids sufficiently distinctive to generate multiple controls on a page.

Code available here: ViewComponentex.cs

Share this post: Email it! | bookmark it! | digg it! | reddit!