If we are going to have a weather forecasting site, it will probably need to have a model that covers different types of possible weather. Such a model might start as follows:

namespace FSharpBook.Models
type SkyType =
   | Sunny
   | Overcast
   | PartlyCloudy
   | Snow
   | Rain
   | Hurricane
   | Zombies                            

SkyType is a discriminated union that represents different types of weather that are possible. Others may be added, but this is a good initial list that allows a developer to know whether a parka is needed. Others could be added (that is, PartlySunny, Showers, and so on), but the current set should be enough for a really simple site.

Of course, it is not enough just to give an indication of temperature, knowing just because it is sunny, it does not mean that a coat isn't needed. Without a temperature, it could be sunny, but a bone chilling −30 degrees outside! It would also be useful to know the location of our forecast, in case the user entered Paris, but got Paris, Texas instead of Paris, France. The following is added to the same file, ForecastModel.fs:

type Forecast = { Location:string; AverageTemperature:double; Skies:SkyType }

To implement a simple forecast model as asked for in the user story, a simple record type with a Location, AverageTemperature, and Skies — will determine whether it will be wet and how cold or hot it will be.

Of course, something is needed that will provide a means to get a forecast. For that, a repository should be created from which forecast information can be obtained.

It isn't just what the model does, but it is also what the model does not do. It is not doing any work to retrieve actual forecast data from outside sources — that is a concern for the repository. Nor does it care about how anything is rendered — that is a concern for the view — not the model. The only things that belong in the model are considerations about how it is going to internally represent weather, and any behavior that might be added. For example, behavior can be added to Forecast that allows it to return something that specifies what kind of attire should be worn. Assume the following choices of attire the user might be interested in wearing:

type Attire =
  | Bikini
  | Normal
  | LightJacket

| Coat
  | Raincoat
  | Parka
  | BodyArmor                                    

The definition for Attire is a discriminated union, much like the definition for SkyType. Given the above attire, it would be useful to add behavior to specify what kind of attire should be worn in different weather conditions. Such a specification may look like this:

type Forecast with
  member forecast.ToAttire() =
    match forecast.AverageTemperature,forecast.Skies with
      | temp,sky when temp > 75.0 && sky = Sunny || sky = PartlyCloudy -> Bikini
      | temp,sky when temp > 65.0 && sky = Sunny || sky = PartlyCloudy -> Normal
      | temp,sky when
          temp > 45.0 && sky = Sunny || sky = PartlyCloudy -> LightJacket
      | _,Rain -> Raincoat
      | temp when temp < 20.0 -> Parka
      | _,Hurricane -> Coat
      | _,Snow -> Parka
      | _,Zombies -> BodyArmor
      | _ -> Coat //when in doubt, wear a coat...
                                                              

A conversion from a Forecast to Attire is based on mapping the appropriate AverageTemperature and Skies combinations to the appropriate Attire. So in a case where there are temperatures over 75 and at least PartlyCloudy skies, the recommendation will be Bikini. There are various other recommendations, including BodyArmor in the event of Zombies.

Note the reopening the Forecast type later on in the model definition, in this case, to add new behavior. This is not that uncommon in F#, as frequently, a method needs to be added that uses a type that was not known earlier because of sequential evaluation. (Remember, types can't be used prior to being defined.)

For a simple website that models a weather forecast and attire recommendations, this is certainly a good model to start with. With this in place, the next phase is to move on to implementation of a repository from where a forecast can be retrieved.

A repository is generally considered a source for information that can be used to populate a domain. In many applications, a repository can take the form of a relational database, such as Postgres, MS SQL Server, or Oracle. CouchDB, MongoDB, db4o, among others, are also great candidates for repositories.

Whatever technology is chosen, the domain objects should never have a need to be aware of it. That is, they should be persistence ignoranant. This is especially important given the increasing rate of innovation in the world of storage and the increasing likelihood you may want to swap out, say, a SQL Server repository at some point for one based on a technology more oriented toward the cloud in the future.

In this case, however, there is no need for traditional data storage. The simple "Forecast'R" site merely uses various Yahoo APIs to gather weather and location information. The signature for the repository method is as follows:

namespace FSharpBook.Repositories
open System
open System.Xml.Linq
open FSharpBook.Models

type YahooForecastRepository() =
  static member GetForecastByLocation locationName =
                                                           

let yahooWhereOnEarthIds
  = YahooForecastRepository.GetWhereOnEarthIdsByLocation locationName

static member GetWhereOnEarthIdsByLocation locationName =
//visit http://developer.yahoo.com/geo/geoplanet/ to get your
//  own appId
  let appId = ""
  let yahooUrlLocationLookup
    = sprintf "http://where.yahooapis.com/v1/places.q('%s')?appid=%s"
        locationName appId
  let locationsDoc = yahooUrlLocationLookup |> XDocument.Load
  let yahooWhereOnEarthIds =
    locationsDoc.Descendants()
    |> Seq.filter (fun e -> e.Name.LocalName = "woeid" )
    |> Seq.map (fun e -> e.Value |> Int32.Parse )
  yahooWhereOnEarthIds
                                                               

http://where.yahooapis.com/v1/places.q('New Jersey')?appid=YourAppID

static member GetForecastByLocation locationName =
  let yahooWhereOnEarthIds
    = YahooForecastRepository.GetWhereOnEarthIdsByLocation locationName
  let getForecastDoc id =
    let yahooWeatherRSSUrl =
      sprintf "http://weather.yahooapis.com/forecastrss?w=%d" id
    yahooWeatherRSSUrl |> XDocument.Load
  let weatherDoc = yahooWhereOnEarthIds |> Seq.head |> getForecastDoc

                                                        

let firstLocationElement (elems:seq<XElement>) =
  elems |> Seq.filter ( fun(e) -> e.Name.LocalName = "location" ) |> Seq.head
let locationNameFromElement (elem:XElement) =
  XmlHelpers.getAttr elem "city"
    + ", " + XmlHelpers.getAttr elem "region"
    + ", " + XmlHelpers.getAttr elem "country"
let currentConditions (elems:seq<XElement>) =
  let findFirstConditionElement (elems:seq<XElement>) =
    elems |>
    Seq.filter (fun(e) -> e.Name.LocalName = "condition") |> Seq.head
  let forecastText
    = XmlHelpers.getAttr ( elems |> findFirstConditionElement) "text"
  forecastText |> YahooForecastRepository.ForecastTextToSkyType
let averageTemperatures (elems:seq<XElement>) =
  elems
    |> Seq.map (fun(e) -> e.Attributes())
    |> Seq.concat
    |> Seq.filter (
       fun(a) -> a.Name.LocalName = "low" || a.Name.LocalName = "high")
    |> Seq.map (fun(a) -> a.Value |> Double.Parse)
        |> Seq.average
                                                         

static member private ForecastTextToSkyType (text:string) =
  match text with
  | t when t.Contains "Partly Cloudy" -> SkyType.PartlyCloudy
  | t when t.Contains "Rain" -> SkyType.Rain
  | t when t.Contains "Snow" -> SkyType.Snow
  | t when t.Contains "Hurricane"
        || t.Contains "Tropical Storm" -> SkyType.Hurricane
  | t when t.Contains "Overcast" -> SkyType.Overcast
  | _ -> SkyType.Zombies
                                                          

static member GetForecastByLocation locationName =
  let yahooWhereOnEarthIds =
YahooForecastRepository.GetWhereOnEarthIdsByLocation locationName
    let getForecastDoc id =
      let yahooWeatherRSSUrl = sprintf
        "http://weather.yahooapis.com/forecastrss?w=%d" id
      yahooWeatherRSSUrl |> XDocument.Load
    let weatherDoc = yahooWhereOnEarthIds |> Seq.head |> getForecastDoc
    let firstLocationElement (elems:seq<XElement>) =
      elems |> Seq.filter ( fun(e) -> e.Name.LocalName = "location" ) |> Seq.head
    let locationNameFromElement (elem:XElement) =
      XmlHelpers.getAttr elem "city"
        + ", " + XmlHelpers.getAttr elem "region"
        + ", " + XmlHelpers.getAttr elem "country"
    let currentConditions (elems:seq<XElement>) =
      let findFirstConditionElement (elems:seq<XElement>) =
        elems |>
        Seq.filter (fun(e) -> e.Name.LocalName = "condition") |> Seq.head
      let forecastText =
        XmlHelpers.getAttr ( elems |> findFirstConditionElement) "text"
      forecastText |> YahooForecastRepository.ForecastTextToSkyType
    let averageTemperatures (elems:seq<XElement>) =
      elems
        |> Seq.collect (fun(e) -> e.Attributes())
        |> Seq.filter
        (fun(a) -> a.Name.LocalName = "low" || a.Name.LocalName = "high")
        |> Seq.map (fun(a) -> a.Value |> Double.Parse)
        |> Seq.average
    let convertDocToForecastModel (doc:XDocument) =
      {
        Location = doc.Descendants()
          |> firstLocationElement
          |> locationNameFromElement;
        AverageTemperature = doc.Descendants() |> averageTemperatures;
        Skies = doc.Descendants() |> currentConditions
      }
    weatherDoc |> convertDocToForecastModel
                                                            

When a domain is set up and a repository has been written that is capable of populating a domain, the next step is to implement a means to connect the domain to something more interesting. In the ASP.NET MVC framework that takes the form of a controller. The controller is, to put it simply, a means for a domain to be exposed to the outside world, typically a View somewhere.

A good way to think about a controller is to think about how a user somewhere may interact, logically, with the application. A simple site for viewing a forecast will definitely need an Index page, which likely has instructions on it, and perhaps a box where someone can enter a query. Certainly something will be needed to handle the query. It would probably also be a wise idea to have a page that shows a result somewhere — one that is preferably a result from the aforementioned query.

namespace FSharpBook.Controllers
open System.Web.Mvc
open FSharpBook.Models
open FSharpBook.Repositories
open System.Web.Routing

[<HandleError>]
type ForecastController() =
  inherit Controller()
                                       

member forecastController.Index() =
  forecastController.View()

The DoQuery Action

Of course, it would be useful to actually have some code that does something. The Submit action, the second written in this example, will perform that role.

When the form is submitted, be it by the Index page, or in theory, any other page that has a form that posts to the Submit action of the Forecast controller, something useful needs to be done with it. There are a couple of options. One naive approach many use is to simply do the work right on the submit action, returning a View that renders the forecast. Although this approach is simple, it causes the great annoyance of the type of message shown in Figure 21-1.

Figure 21.1. FIGURE 21-1

To get around this, the form processor is going to implement what is often called the PRG Pattern. PRG stands for Post, Redirect, and Get. This has a couple of advantages — one of which is that it gets away from having the browser complain that it is going to need to re-post the form. Another though, and probably more compelling than that, is that it allows separation of form processing from the view rendering that is the result of that processing. The code to implement a PRG pattern is actually quite simple:

member forecastController.Submit(locationQuery:string) =
  let rvd = new RouteValueDictionary()
  rvd.Add("locationQuery",locationQuery)
  forecastController.RedirectToAction("for","forecast",rvd)

A forecast controller always takes a locationQuery as a parameter. This may be a form field from some form that posted to this page, but how it looked on such a form does not really matter to the controller — the controller just needs to know that by the time this routine is called, something mapped it in properly. What is needed is to create a redirect to the controller and action that is actually going to render the result.

One technique to do that is to create a RouteValueDictionary object that has the parameter. The first two lines of the method that create the dictionary and add the item accomplish that goal. The third line is a call to RedirectToAction, a method on the Controller base class that knows how to redirect a new GET request based on an action, a controller name, and optionally, a RouteValueDictionary that holds the parameters.

member forecastController.For(locationQuery:string) =
  locationQuery
    |> YahooForecastRepository.GetForecastByLocation
    |> forecastController.View

It should be noted that the view is not quite ready for implementation. There are a couple of things that need to be done to have the domain objects render nicely in the views. The Attire and SkyType objects, although definitely in a nice form useful for the domain logic, do not have a reliable means to convert to strings. Of course, we could interrogate their type and push out a string based on that, but then there would still need to be a means to convert from something like "PartlyCloudy" to, say, "Partly Cloudy", or perhaps if the website needed to render in Spanish, "Parcialmente Nublado".

It would be bad practice to put such view-specific concerns in the same place as the main controller or model, so to keep the concerns separate, put these in a separate area of the project called ViewHelpers. The first new file will help us render various SkyType values:

module SkyTypeRenderer
open FSharpBook.Models

let ToWeatherString sky =
 match sky with
   | Sunny -> "Sunny"
   | Overcast -> "Overcast"
   | PartlyCloudy -> "Partly Cloudy"
   | Snow -> "Snow"
   | Rain -> "Rain"

| Hurricane -> "Hurricane"
   | Zombies -> "Oh NO! ZOMBIES!!!"
let ToImageFileName sky =
 match sky with
   | PartlyCloudy -> "PartlyCloudy"
   | Zombies -> "Zombies"
   | _ -> ToWeatherString sky
                                                

This first file allows us to do two view-specific things. It creates a string for each state of sky (to be rendered in a specific view), and it maps sky types to filenames, which again, are known when dealing with a specific view.

The second file will help map various Attire definitions to strings:

module AttireRenderer
open FSharpBook.Models

let ToAttireString attire =
  match attire with
    | Bikini -> "Bikini"
    | Normal -> "Normal"
    | LightJacket -> "Light Jacket"
    | Coat -> "Coat"
    | Raincoat -> "Raincoat"
    | Parka -> "Parka"
    | BodyArmor -> "Body Armor"
                                                      

Of course, what is being done here with these renderers, in a production system, would be best done with locale-specific resource files, so that when a system is internationalized, such internationalization is more easily done by swapping out the appropriate resource.

If everything has been done right, there should be almost no reason to have code, other than perhaps a few very trivial binding helpers, in the view. The Holy Grail in this kind of system is a view that lacks any code at all. That is, the view should consist of markup that is the province of the user interface designer, and anything that such a designer would have a hard time understanding should go in some other kind of component.

The example site has two views. It has the Index view that is rendered when the user goes to the default page, and the results view (For.aspx, in this case) that shows the result. The Index view (Index.aspx) is very simple:

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master"
Inherits="System.Web.Mvc.ViewPage" %>

<asp:Content ID="titleContent" ContentPlaceHolderID="TitleContent" runat="server">
    Forecastr - The simplest weather forecast system in the Universe!
</asp:Content>

<asp:Content ID="mainContent" ContentPlaceHolderID="MainContent" runat="server">
<div id="queryText">
<% using (Html.BeginForm("DoQuery","forecast", FormMethod.Post)) {%>
    I want to know the weather forecast for:
    <%= Html.TextBox("LocationQuery") %>
    <input type="submit" value="Get Forecast" />
<% } %>
</div>

</asp:Content>
                                                 

It is notable that what little code is here is written in C#, not F#. Although it may be possible to get markup to work in F#, doing so requires a lot of work with web.config files and certainly does not work easily out-of-the-box as of the time of writing. Given the intent is to minimize code in the view anyway, in this case, a decision is made to keep view-only code in C# — but do as little as possible.

The code that is here, frankly, does very little. Simple helpers are being used from the framework to generate some html code. Html.BeginForm is a framework helper function for spitting out form elements; Html.TextBox does the same for Input elements that represent text boxes. The only thing that really needs to be done here is to specify a controller that should be posted to, as well as an intended action. We could just as easily write:

<form action="/forecast/DoQuery" method="post">

Of course, the benefit received in using the helper is that it can provide some help in making sure the output is correct, because the preceding code might not be correct if we were in a situation that involved writing a site that ran from a virtual directory. That said, there may be cases where a designer will want more control over the output and will opt for writing the raw html. Given that the only responsibility of the html helper is to spit out appropriately formatted html, having an html designer hand-code it would not break the site.

The code for the Forecast view is a slightly bit more complex, but not horribly so:

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master"
Inherits="System.Web.Mvc.ViewPage" %>
<%@ Import Namespace="FSharpBook" %>
<%@ Import Namespace="FSharpBook.Models" %>

<asp:Content ID="titleContent" ContentPlaceHolderID="TitleContent" runat="server">
    <%
        var forecastModel = (Forecast) ViewData.Model;
    %>
    Forecast for <%= forecastModel.Location %>
</asp:Content>

<asp:Content ID="mainContent" ContentPlaceHolderID="MainContent" runat="server">

    <%
        var forecastModel = (Forecast) ViewData.Model;
    %>
    <table><tr>
    <td>

<div id="weatherIcon">
        <img src="../../Content/<%=
SkyTypeRenderer.ToImageFileName(forecastModel.Skies) %>.gif" alt="<%=
SkyTypeRenderer.ToWeatherString(forecastModel.Skies) %> Graphic" />
    </div>
    <div id="weatherText">
        <%= SkyTypeRenderer.ToWeatherString(forecastModel.Skies)%>
    </div>
    </td>
    <td>
    <div id="weatherIntroText">We are forecasting that the weather in <%=
forecastModel.Location %> will be:</div>
    <div id="averageTemperatureDisplay">
        <%= forecastModel.AverageTemperature %> degrees with <%=
SkyTypeRenderer.ToWeatherString(forecastModel.Skies)%>
    </div>
    Consider wearing <%= AttireRenderer.ToAttireString(forecastModel.ToAttire()) %>
    </td>
    </tr></table>
    <%= Html.ActionLink("Back to Index","Index","Forecast") %>
</asp:Content>
                                                      

Again, this is being done in C#, but doing so using the minimum of executable code. Starting with the title part of the page, it starts off with a user friendly title so that when the end user has multiple browser windows open, they will know which one is the Forecast page. ViewData.Model carries an object that represents the thing that the page should bind to. In this case, to make this work a strongly typed reference to the model is useful:

<%
     var forecastModel = (Forecast) ViewData.Model;
%>

This allows the following snippet that sets the title text to be written:

Forecast for <%= forecastModel.Location %>

The body of the page is a little more work. Note that each page content area, delimited by <asp:Content> tags, has independent scope, so it is necessary to put in a strongly typed declaration for forecastModel again:

<%
      var forecastModel = (Forecast) ViewData.Model;
%>

The first bit of code that is encountered is for the icon used to display the weather. The view helper has a routine to provide the name of a file. The page is going to leverage that to provide the html that will be used to show the image:

<div id="weatherIcon">
   <img src="../../Content/<%=
SkyTypeRenderer.ToImageFileName(forecastModel.Skies) %>.gif" alt="<%=
SkyTypeRenderer.ToWeatherString(forecastModel.Skies) %> Graphic" />
    </div>

In this case, the code is appending the string for the image file to the Content path and then adding .gif at the end. Like all good web citizens, the site provides alt text as well that leverages the ToWeatherString method that was written in the view helper so that the site has a text representation of the image as well.

The same code will be used to generate alt text for the weather headline:

<div id="weatherText">
   <%= SkyTypeRenderer.ToWeatherString(forecastModel.Skies)%>
</div>

Again, the page is using the SkyTypeRenderer to translate from a logical type of weather represented by forecastModel.Skies to the actual string the page should use for rendering.

The next couple sections follow the same pattern:

<div id="weatherIntroText">We are forecasting that the weather in <%=
forecastModel.Location %> will be:</div>
    <div id="averageTemperatureDisplay">
        <%= forecastModel.AverageTemperature %> degrees with <%=
SkyTypeRenderer.ToWeatherString(forecastModel.Skies)%>
    </div>
                                                             

The last section is where a clothing recommendation is made. Again, the logic is not terribly complex; just render the model:

Consider wearing <%= AttireRenderer.ToAttireString(forecastModel.ToAttire()) %>

If the view is much more complex than this, say, rendering a simple domain model, it might be advisable to write a ViewModel — and some classes to convert from the more complex domain to a ViewModel so that the chance of that complex logic getting added to the view is minimized. Code that goes in views tends to not be reused and tends to allow concerns that are not specific to a particular view to leak into views, leading to duplication and difficult maintenance.