Thoughts on life, liberty, and information technology

Using MonoRail ViewComponents with the Spark view engine

Although I was able to find some documentation and samples (mostly through the unit tests) of how to use a ViewComponent with the Spark view engine, details were sketchy, so I’ll share some quick tips to those who are scratching their heads as I was.

Using a block ViewComponent

Support for block view components is pretty evident in Spark, as shown in the following example, which illustrates the use of the AuthenticatedContent view component.


	
		This content is shown when the user is logged in.
	
	
		This content is shown when the user is NOT logged in.
	

Using the CaptureFor ViewComponent

The CaptureFor component is one useful way to allow a sub-view to “inject” data into a layout. I use this all the time to allow a rescue page to change the page title when an error occurs.

On your layout page, you inject the page title as you normally would (so a controller can inject it via the property bag).

ComputerSims Baseball: $!{ViewData["PageTitle"]}

In the view, the CaptureFor component is called as an HTML tag.

An unexpected error has occurred

Calling a ViewComponent with view and static data

This is one that perplexed me. I have a custom menu component (called MenuComponent) which accepts a name parameter. I tried calling it like this:


Unfortunately, that threw an error: “The name ‘mainmenu’ does not exist in the current context“. Fortunately, Spark exceptions are easy to read (you can see the C# code it generates and thus find the error). Apparently, in the above example, “mainmenu” was expected to be a variable in the view page and was not being treated as static text. To use static text, you put single quotes inside the double quotes.


Problem solved. I can’t say it’s the preferred way based on my experience thus far (I’d prefer requiring ${mainmenu} for variable injection), but since I’m new to this, I won’t criticize much.

2 responses to “Using MonoRail ViewComponents with the Spark view engine”

  1. Louis DeJardin Avatar
    Louis DeJardin

    I’m glad you like what you’ve seen so far.

    I agree – the parameter value being a code expression makes sense on paper but feels wrong when you use it. There are some places where an attribute holding code seems more natural, like each=”” and if=””, but in others it seems backwards to put quotes around what seems like a string already.

    Also in the capturefor case consider using {content name=”etc”}…{/content} and {use content=”etc”/} – I found the capturefor in monorail and nvelocity so convenient it was built it into Spark as a core feature.

    Like

  2. brian Avatar
    brian

    Thanks for taking the time to comment — and for sharing the “capturefor” tip.

    As I get more time to tinker, I’ll be sure to share more feedback (and maybe a few patches)… 😉

    Like

Leave a comment