Christopher Bennage : web

Render Action

Christopher Bennage — Mon, 30 Apr 2012 17:55:00 GMT

It’s common for a single web page to include data from many sources. Consider this screen shot from Project Silk. There are four separate items displayed.

The primary concern of the page is displaying a list of vehicles. However it also displays some statistics and a set of reminders. I labeled the stats and reminders as orthogonal because they are (in a sense) independent of the primary concern. Finally, there is the ambient data of the currently logged in user. I call this data ambient because we expect it to be present on all the pages in the application.

It’s a common practice in MVC-style applications to map a single controller action to a view. That is, it is the responsibility of a single action to produce everything that is needed to render a particular web page.

The difficulty with this approach is that other pages often need to render the same orthogonal data. Let’s examine the code for the action invoked by \vehicle\list.

public ActionResult List()
{
    AddCountryListToViewBag();

    var vehicles = Using<GetVehicleListForUser>()
        .Execute(CurrentUserId);

    var imminentReminders = Using<GetImminentRemindersForUser>()
        .Execute(CurrentUserId, DateTime.UtcNow);

    var statistics = Using<GetFleetSummaryStatistics>()
        .Execute(CurrentUserId);

    var model = new DashboardViewModel
                    {
                        User = CurrentUser,
                        VehicleListViewModel = new VehicleListViewModel(vehicles),
                        ImminentReminders = imminentReminders,
                        FleetSummaryStatistics = statistics
                    };

    return View(model);
}

Disregarding how you might feel about the Using<T> method to invoke commands and other such details, I want you to focus on the fact that the controller is composing a model. We generate a number of smaller viewmodels and then compose them into an instance of DashboardViewModel. The class DashboardViewModel only exists to tie together the four, otherwise independent data.

Personally, I prefer to avoid classes like DashboardViewModel and simply rely on dynamic typing in the view. However, others feel strongly about having IntelliSense support in the view.

Project Silk had separate actions just to serve up JSON:

public JsonResult JsonList()
    {
        var list = Using<GetVehicleListForUser>()
            .Execute(CurrentUserId)
            .Select(x => ToJsonVehicleViewModel(x))
            .ToList();

        return Json(list);
    }

You’ll notice that both JsonList and List use the same GetVehicleListForUser command for retrieving their data. JsonList also projected the data to a slightly different viewmodel.

Reducing the Code

While reevaluating this code for Project Liike, we decided to employ content negotiation. That is, we wanted a single endpoint, such as \vehicle\list, to return different representations of the data based upon a requested format. If the browser requested JSON, then \vehicle\list should return a list of the vehicles in JSON. If the browser requested markup, then the same endpoint should return HTML.

First, we needed to eliminate the differences between the JSON viewmodel and the HTML viewmodel. Without going deep into details, this wasn’t hard to do. In fact, it revealed that we had some presentation logic in the view that should not have been there. The real problem was that I wanted the action to look more like this:

public ActionResult List()
{
    var vehicles = Using<GetVehicleListForUser>()
        .Execute(CurrentUserId);

    return new ContentTypeAwareResult(vehicles);
}

Only, the view still needed the additional data of statistics and reminders. How should the view get it?

We decided to use RenderAction. RenderAction allows a view to invoke another action and render the results into the current view.

We needed to break out the other concerns into their own actions. For the sake of example, we’ll assume they are both on the VehicleController and named Reminders and Statistics. Each of these action would be responsible for getting a focused set of data. Then in the (imaginary) view for List we could invoke the actions like so:

// List.cshtml 
<ul>
@foreach (var vehicle in Model)
{
    <li>@vehicle.Name</li>
}
</ul>

<section role="reminders">
@{ Html.RenderAction( "Reminders", "Vehicle") }
</section>

<section role="statistics">
@{ Html.RenderAction( "Statistics", "Vehicle") }
</section>

Note that each action has it’s on associated view.

The value of using RenderAction is that we where able to create very simple actions on our controllers. We were also able to reuse the actions for rendering both markup and JSON.

A secondary benefit is the separation of concerns. For example, because we moved the responsibility of composition from the controller into the view, a designer could now revise the view for the \vehicle\list without needing to touch the code. They could remove any of the orthogonal concerns or even add new ones without introducing any breaking changes.

The Downside

There are a few caveats with this approach.

First, don’t confuse RenderAction with RenderPartial. RenderAction is for invoking a completely independent action, with its own view and model. RenderPartial is simply for renders a view based on a model passed to it (generally derived from the main viewmodel).

Secondly, avoid using RenderAction to render a form. It’s likely won’t work the way you’d expect.This means that any form rendering will need to occur in your primary view.

Thirdly, using RenderAction breaks the model-view-controller pattern. What I mean is that, in MVC, it’s assumed that the view does nothing more than render a model. Controllers invoke a view, and not vice versa. Using RenderAction breaks this rule. Personally, I have no problem breaking the rule when it results in code that is more simple and more easily maintained. Isn’t that the whole point of best practices anyway?

Comment on this post at dev.bennage.com

Mobile Development: Detecting Devices & Features

Christopher Bennage — Thu, 20 Oct 2011 17:50:00 GMT

Take this post cum granlis salis. I’m trying to figure this stuff out and I’m thinking out loud.

Background

Whenever a browser makes a request, it includes a string identifying itself to the server. We commonly refer to this as the user agent string. This string identifies the browser and the platform and the version and a great deal more such nonsense.

This sounds great in theory. We should be able to use this data to optimize what’s being sent to the (mobile) browser. However, there’s been something of a sordid history for user agent strings. In retrospect, we’ve realized that user agent sniffing is a tool that has often hurt more than it has helped.

We’ve learned to favor feature detection over browser detection (or device detection). Take a look at modernizr and haz.io for more on the that front. The success of feature detection has also resulted in a shift from server logic to client logic. We detect features on the client but we detect user agent strings on the server, before we send anything to the client.

How does all this play into the mobile web? One of the key mobile features we are interested in is screen size. Luckily for us, the W3C has blessed us with media queries. In a nutshell, media queries allow you to conditionally apply CSS based properties of the display device. This has given rise to something known as Responsive Web Design. Responsive Web Design is about having a single set of markup whose layout can respond to the device’s display capabilities. Unfortunately, there are a few rough edges with this approach.

Moving Backwards…

In the mobile world, client-side feature detection has a few drawbacks. It requires extra code to be sent to the browsers and it takes additional processing on the client. It’s also likely that you’ll end up sending more than is really needed (or that you’ll need to make additional requests).

One solution to this conundrum is to use the open source “database” called WURLF. You can query WURL with a user agent string and it will return a set of capabilities. I think of it as feature detection on the server. Though admittedly it’s a bit misleading to call it that.

This means your server can ask questions like “Does this client support HTML5? If no, what do they support?” before the first response is even sent.

WURLF has commercial support and a C# API. For ASP.NET developers, 51Degrees has an open source project called Foundation that is built on top of WURL. It uses an HttpModule to automatically query WURL and populate the Request.Browser. Setting up WURLF without Foundation takes a little bit more work, but not too much. Both are available on Nuget: WURL and 51Degrees.

What should you do?

I don’t think that there is a cut and dry answer at the moment. What you do depends heavily on your target audience. If you are targeting the North American market there’s a good chance you’ll be okay with a single set of markup, going with a responsive mobile-first design. In other words, there would be no need for something like WURLF.

However, you might need a very broad reach or you might be targeting a market heavy in feature phones or something else that’s very different from North America. In those cases, it is good to understand your options.

Comment on this post at dev.bennage.com

Being a New Kid on the Mobile Block

Christopher Bennage — Mon, 10 Oct 2011 23:38:00 GMT

The last few weeks I’ve been trying get a finger on the pulse of mobile web development. I wanted to identify the thought leaders, understand the big questions, and (perhaps mostly importantly) begin cataloging the practical considerations for building mobile experiences today.

Here’s where I’m at so far…

What is ‘the mobile web’?

The definition of mobile web is quickly evolving. Devices are varied and the distinctions are blurring. If you think it’s as simple as iOS, Android, and Windows then you’ll be surprised. (I do genuinely love my WP7). Personally, I think the distinction between mobile and desktop is fading more and more everyday. When I say mobile web I am talking about HTML-based applications and not applications that are built natively for their respective platforms. Of course, there is debate over native apps versus web apps: when is one appropriate over the over? etc, etc. This is a question when intend to address in Project Liike.

Who to follow?

I’ve been following a mishmash of people, and I must confess that my process of qualifying them has been some haphazard. I’m compiling a list on twitter. A number of folks on this list are signatories of future friend.ly.

Other sources I’ve been paying attention to are:

A List Apart – “For people who make websites.”
Smashing Magainze – Lots of articles on design, web, and of course mobile.
Cloud Four – Many recent and thorough posts exploring some of the big questions in mobile.
Yiibu – They have a lot of interesting ideas, and they’ve done some impressive work for Nokia.

I’ve also been reading through Programming the Mobile Web by Maximiliano Firtman. The first few chapters are pretty scary for someone like myself who did not understand how diverse and scattered the mobile world is. (It’s also funny to see how much has changed since the book was published in 2010.)

Anything you’d recommend?

The state of things

Caveat: This is just Christopher’s brain dump. Consider it merely food for thought.

There are many compeling reasons for developing mobile web apps. Not to the complete exclusion of native apps, but maybe?
You need to understand your target market and the devices that it uses. Don’t make assumptions. You might be surprised.
The space is changing, standards are evolving, solutions are being formulated. However, if you need to you need build an app today, there is still plently of pragmatic advice.

One more thought: don’t jump to conclusions. You might read about something cool like Responsive Web Design, but such cool and innovative techniques can be deceptive. Research and testing is your friend.

Comment on this post at dev.bennage.com.

Restarting Node.js When Your Source Changes

Christopher Bennage — Tue, 09 Aug 2011 08:47:00 GMT

I’m lazy. I remember reading somewhere that that was a desirable trait to have in a developer. I’m not sure where though, and honestly it’s just too much effort to bingle it. This laziness came to the forefront recently as I was playing with Node.

In my last post, I showed you how to spin up a quick web app using Node. As I was playing with this app, I found that I had to restart Node every time I made a change to the source. This meant I had to switch to the console, stop the process, start the process and THEN refresh my page to see the effect of my change. Too much work I say.

So I wondered if Node had something built-in for monitoring changes to the file. I didn’t see anything useful from node.exe –help and researching it on the Web is just so tedious, so I decided to write my own solution.

Looking for Some Change

In .NET, there is a class System.IO.FileSystemWatcher. With an instance of this class you can monitor the files in a directory for changes. I set it up like this:

var watcher = new FileSystemWatcher();
watcher.Path = @"C:\node.js\stuff";
watcher.NotifyFilter = NotifyFilters.LastWrite | NotifyFilters.FileName;
watcher.Filter = "*.js";

watcher.Changed += Changed;
watcher.Created += Changed;
watcher.Deleted += Changed;
watcher.Renamed += Renamed;

// Begin watching
watcher.EnableRaisingEvents = true;

The NotifyFilter property allows you to specify the sort of changes you are interested in. You can check out the full list here. You’ll also notice that I used the Filter property to narrow it down just to js files.

Next, there are a number of events to wire to respond to changes. I reused the same handler as much as I could because I always want to do the same thing: restart Node. It’s also not entirely obvious how these events relate to NotifyFilter, but I didn’t dig too deep into that. (I’m lazy remember.)

It’s also important to set EnableRaisingEvents. If you don’t, then the (guess what) no event are raised.

Kill, Kill, Kill

Now whenever a significant change occurs, it’ll be time to restart Node. For this I used System.Diagnostics.Process. This is a bit of a tricky classs, with a number of not-so-obvious knobs to turn.

First, I’ll need to get a reference to the Node process. I noticed in Task Manager that the process name was “node”. So I used

Process.GetProcessesByName("node")

This returns an array of processes, and so I did this:

var matches = Process.GetProcessesByName("node");

matches.ToList().ForEach(match => {
    Console.WriteLine("attempting to close node.js [" + match.Id + "]");
    match.Kill();
    match.WaitForExit(300); // it shouldn’t take this long, we’re just being cautious
    Console.WriteLine("successfully closed");

Admittedly, this is hitting it with a hammer. It’s okay, because this is just a quick and dirty helper tool for me and not a production application.

After killing the process, I’ll want to start another one. Now, I don’t care for another console window to pop up each time I restart, instead I’d like to simply redirect the input and output to my little helper app. This can be a little tricky, and I had to do some experimentation to find the right combination in order keep things from hanging. If you find it misbehaving, I recommend searching StackOverflow. I found several useful questions there. One of the keys that came up more than once was capturing and closing the stream for the standard input.

var start = new ProcessStartInfo();
start.FileName = @"C:\node.js\node.exe";
start.UseShellExecute = false; // the starts the process directly, as opposed to going thu the shell
start.CreateNoWindow = true; // we don’t want a new window
start.RedirectStandardOutput = true;
start.RedirectStandardInput = true;
start.Arguments = Path.Combine(@"C:\node.js\stuff", @"server.js");

var node = new Process();
node.EnableRaisingEvents = true;
node.OutputDataReceived += OutputHandler;
node.StartInfo = start;
node.Start();

node.Refresh(); // refreshing the metadata stored in the instance of Process 
Console.WriteLine(node.ProcessName);
Console.WriteLine("[" + node.Id + "] node.exe started");

// close the input, we won't use it
var input = node.StandardInput;
input.Close();

// and now for the output
node.BeginOutputReadLine();

First we create an object that contains the configuration for starting an instance of Node. Notice that we are passing in the server.js file as an argument.

Also note that after starting the process, I call Refresh. I need to do this so that I’ll have the correct info to write out to the console. This data is not captured automatically.

Finally, I handled the redirection of the input and output.

The complete code for the app is available at https://gist.github.com/1108727.

Epilogue

This is very much a hack and I am not an expert on the proper usage of these classes. Please feel free to offer improvements.

Things I’d Like To Present

Christopher Bennage — Fri, 08 Jan 2010 11:32:00 GMT

In case you are not familiar with MIX, it is a conference from Microsoft focusing on the collaboration of design and development. Admittedly, the sessions tend to favor the developer, but there is always excellent design and UX content.

There was an open call for presentations this year and the community gets to choose which of the proposals will be selected. There are a number of excellent proposals and I encourage you to go check out the list and vote for the sessions that you are genuinely interested in. (Even if you won’t be attending, the sessions will be broadcast.)

Here are some sessions that I proposed for MIX10:

Cross Compiling Games for Silverlight & XNA

Our friend and Silverlight MVP, Bill Reiss, has created an incredible library that enables you to cross compile XNA games for Silverlight. The library is called SilverSprite and we feature it on Silver Arcade. (Wow, that’s a lot of ‘silvers’ in one paragraph.)

In this session, we’d write a simple game for XNA (discussing some of the basic of game dev along the way) and then port the game over to Silverlight.

This is an area where I wish I could spend more time. I love game development, but it’s always taking a back burner to other projects.
[vote for this]

LinqToSQL and EntityFramework Profilers: Case Study

If you aren’t already familiar with the UberProf suite of ORM profilers, you can read tales of the development on Ayende’s blog. Rob and I built the UI side of the application, and we learned a lot in the process. I’d like to do a talk were we discuss the challenges of the project, how we solved them, and what we did wrong.

Yes, NHProf will be included too. (I submitted a case study for it last year, and it didn’t get picked. I have to sneak it in).

A few interesting aspects:

we built this using MVVM, but well before Caliburn reached maturity.
the four separate apps (NHProf, EFProf, L2SProf, HProf) all use a single code base.
we’re about to port the project from WPF to Silverlight.

[vote for this]

Silver Arcade: Case Study

This is a presentation that Rob and I have made a couple of times. Most recently at the Orlando .NET Users Group. We walk through the actual code for Silver Arcade explaining the philosophy, design choices and mistakes we made along the way.

For MIX, we would focus more design and UX choices, such as the separation of the behaviors from the views. However, we like to have a lot of audience interaction and tend to follow where ever the questions led (especially those leading questions that Scott Densmore tends to ask).

Silver Arcade is also interesting because we deliberately used a number of newer hipper technologies; including Azure, ASP.NET MVC, jQuery, MEF, NHibernate and so on.
[vote for this]

Thanks!

Get Firebug

Christopher Bennage — Tue, 06 Mar 2007 22:23:00 GMT

If you are a Web developer, and you are not using Firebug, stop what you are doing and go install it immediately.

I first heard about Firebug on Rick Strahl's blog a couple of months ago, but in the flurry of work I promptly forgot it. A couple of days ago a friend was listing the reasons that why Firefox pwns IE and Firebug was the first.

Firebug is an add-on for Firefox. It allows you to inspect the details of the currently loaded page. You can visually inspect the DOM, execute JavaScript snippets on the fly, and more. I'm thoroughly impressed.

My feature du jour is the way it displays the CSS box model for the currently selected element.

I'm not going to repeat the list of features here, you can get that from the Firebug page. If you have not tried it, go check it out.