Functions as objects in Javascript

In Javascript, functions are objects.

That statement probably comes off a little underwhelming. Let's look at an example.

function addTheNumbers(num1, num2) {
    return num1 + num2;
}

function subtractTheNumbers(num1, num2) {
    return num1 - num2;
}

var func; 

func = addTheNumbers;
var result1 = func(1, 2); // 3

func = subtractTheNumbers;
var result2 = func(1, 2); // -1

We defined two different functions, one for adding and one for subtracting. Both take the same number of parameters. We then separately assign each of the functions to another variable, and then call that variable. You can point to any function just by using the name of that function as a variable.

For more information, check out our website.

Using a Windows Service as a Timer

BACKGROUND: Recently, I came across an issue with an MVC application I was developing. This application is composed of two sections: the Frontend and Backend. The Frontend contains all the visuals (what the user sees) and requests information from the Backend. The Backend fetches all the data from the database and sent it to the Frontend.

ISSUE: The communication between the Frontend and the Backend was being lost randomly. I was never able to witness it. We only knew it happened because the Frontend would display, but no data would be present.

RESOLUTION: I am going to create a windows service that is going to run on the machine hosting the Frontend project. This service will start a timer that will tick every x minutes (5 minutes for this application). On every tick, the Frontend will send a request to the Backend. If the request does NOT return "true" from the Backend, an error will be written to the log.

STEPS: *Using Visual Studio 2010 in .NET v.4

Step 1: Create a basic Windows Service Project and Setup Project

• http://msdn.microsoft.com/en-us/library/aa984464(v=vs.71).aspx
• You can ignore the OnContinue() action
• Tip - For step 7 under the section 'To create the installers for your service', I chose to use Local System instead of Local Service. Local Service was NOT working for me. I would get a permissions error when I attempted to start the service and it would not start.

Step 2: Install the service, Start the service and Verify that it is running by checking the log in the Event Viewer

Step 3: Uninstall the service

Step 4: Add the Timer to the Windows Service

• Add private System.Timers.Timer _timer = new System.Timers.Timer() to the top of the class
• Call SetupTimer() from the OnStart function

private void SetupTimer(){
   int interval = 300000; //default to 5 minutes
   this._timer.Interval = interval;
   this._timer.Elapsed += new System.Timers.ElapsedEventHandler(TimerElapsed);
   this._timer.Start();
}

• Create another function called TimerElapsed() in the same file

 
void TimerElapsed(object sender, System.Timers.ElapsedEventArgs e){
   eventLog1.WriteEntry("Communication check...");
   //Connect to a Backend function that returns true
   if (response)
     //Do nothing or write to log "success"
   else
     eventLog1.WriteEntry("Communication to Backend Failed",EventLogEntryType.Error);
     //EventLogEntryType.Error makes the entry get marked as an error in the Event Log
}

Step 5: Build the Windows Service Project

Step 6: Build the Setup Project

• Be sure the build these projects in the proper order!

Step 7: Install the service, Start the service and Verify that it is running by checking the log in the Event Viewer


For more information, visit our site: www.rippe.com/index.htm

Editor Templates 101

Editor templates are a great way to reduce duplicated code in your project. When you're writing an HTML form, a lot of your fields can be simple text boxes, but sometimes we want a bit more functionality. Instead of writing the same code over and over to customize our editors, we put all of that code in one location and refer to it from inside our view.

I'd like to note that there are many different ways to use editor templates -- I'm just going to focus on a couple basic ways in this post.

Let's consider a view that contains a form:

@model MvcApplication.Models.Document

<h2>Create</h2>

@using (Html.BeginForm()) {
    @Html.ValidationSummary(true)
    <fieldset>
        <legend>Document</legend>

        <div class="editor-label">
            @Html.LabelFor(model => model.Name)
        </div>
        <div class="editor-field">
            @Html.EditorFor(model => model.Name)
            @Html.ValidationMessageFor(model => model.Name)
        </div>

        <div class="editor-label">
            @Html.LabelFor(model => model.Author)
        </div>
        <div class="editor-field">
            @Html.EditorFor(model => model.Author)
            @Html.ValidationMessageFor(model => model.Author)
        </div>

        <div class="editor-label">
            @Html.LabelFor(model => model.FileType)
        </div>
        <div class="editor-field">
            @Html.EditorFor(model => model.FileType)
            @Html.ValidationMessageFor(model => model.FileType)
        </div>

        <div class="editor-label">
            @Html.LabelFor(model => model.DateUploaded)
        </div>
        <div class="editor-field">
            @Html.EditorFor(model => model.DateUploaded)
            @Html.ValidationMessageFor(model => model.DateUploaded)
        </div>

        <p>
            <input type="submit" value="Create" />
        </p>
    </fieldset>
}

<div>
    @Html.ActionLink("Back to List", "Index")
</div>

This is a standard view made using the "Create" template. It has taken all of the fields of our Document model and has stubbed out editors for them. Here is the controller action that backs it up:

public ViewResult Create()
{
    return View();
}

Very simple. When the view is rendered to the browser, we see simple text boxes for each field.

But what if we want to do more than that? Let's say we want to be able to pick up our DateUploaded field with javascript so we can throw on a datepicker. Ok, how about this:

<div class="editor-label">
    @Html.LabelFor(model => model.DateUploaded)
</div>
<div class="editor-field">
    <input id="DateUploaded" name="DateUploaded" data-datepicker="true" value="@Model.DateUploaded" />
    @Html.ValidationMessageFor(model => model.DateUploaded)
</div>

Would this work? Yes, we can pick up on the data-datepicker tag with javascript. But this is beyond dirty. We have just lost a lot of the functional advantages we get by using the EditorFor method on the HTML helper. Sure, this would work... but what if you change the name of the DateUploaded field? If we used the EditorFor, we would see a big nasty error message when we tried to load the view. But using the raw HTML, it's still valid. The http POST won't even fail. We just won't have our DateUploaded field populated. So, how do we accomplish this?

Let's take a look at the overloads for EditorFor.

EditorFor<TModel, TValue>(this HtmlHelper<TModel> helper, Expression<Func<TModel, TValue>> expression)

EditorFor<TModel, TValue>(this HtmlHelper<TModel> helper, Expression<Func<TModel, TValue>> expression, object additionalViewData)

EditorFor<TModel, TValue>(this HtmlHelper<TModel> helper, Expression<Func<TModel, TValue>> expression, string templateName)

...

(There are more but I cut them out for brevity). Look at the third one in the list. What is templateName? Specifying a value for templateName is the most straightforward way to use editor templates. When you provide a template name, MVC will look in a few different locations for a view with a name matching the value you provide as templateName. It's very similar to how calling View() in a controller action looks for a view with a name matching the action name. The view engine checks these locations in order:

1. ~/Areas/[AreaName]/Views/[ControllerName]/EditorTemplates/[TemplateName].cshtml
2. ~/Areas/[AreaName]/Views/Shared/EditorTemplates/[TemplateName].cshtml
3. ~/Views/[ControllerName]/EditorTemplates/[TemplateName].cshtml
4. ~/Views/Shared/EditorTemplates/[TemplateName].cshtml

So, let's modify our view code to look for an editor template named "DatePicker":

<div class="editor-label">
    @Html.LabelFor(model => model.DateUploaded)
</div>
<div class="editor-field">
    @Html.EditorFor(model => model.DateUploaded, "DatePicker")
    @Html.ValidationMessageFor(model => model.DateUploaded)
</div>

Perfect! Now we need to add a "DatePicker" partial view. But what do we put there? It's important to note that using this EditorFor overload is very similar to calling PartialView. Whatever editor template it finds, it will render that in place like a partial view. So, everything we put inside the DatePicker editor template is exactly what we get rendered. Let's try something simple to test.

@model DateTime?
@Html.TextBox("txtDatePicker")

We will save that as ~/Views/Shared/EditorTemplates/DatePicker.cshtml. Notice what we have declared as our model type. DateTime makes sense, but why nullable? Well, if we load our "Create" view with a null model (as is the case with our Create action), then it doesn't have a value for DateUploaded. We have to account for a null value in this case, even if the type on the model is not nullable. 

Let's take a look at the HTML this generates:

<div class="editor-field">
    <input id="DateUploaded_txtDatePicker" name="DateUploaded.txtDatePicker" type="text" value="">
    <span class="field-validation-valid" data-valmsg-for="DateUploaded" data-valmsg-replace="true"></span>
</div>

Notice how it changed the name and id attributes? When you provide a name for an element inside an editor template, what you're really doing is supplying the name of the property you're using inside the editor template. Thus, you get DateUploaded.txtDatePicker. If DateUploaded was an object that had its own properties, this would be perfect. But in our case we just want a textbox that refers to itself. We can accomplish that by passing in an empty string for the name.

@model DateTime?
@Html.TextBox("")

This may seem strange at first, but the truth is we don't actually need to supply a name for our textbox. That name is picked up from the name of the property specified on our Create view.

<div class="editor-field">
    <input data-val="true" data-val-required="The DateUploaded field is required." id="DateUploaded" name="DateUploaded" type="text" value="">
    <span class="field-validation-valid" data-valmsg-for="DateUploaded" data-valmsg-replace="true"></span>
</div>

This looks much better, and we've even picked up on the validation attributes. One thing we're not picking up on is the value of the field. You can't tell in the above HTML because we're using a null model, but even if we had a value, it would not get rendered because we're just spitting out a blank textbox right now. Let's fill in the value parameter by using the ViewData object:

@model DateTime?
@Html.TextBox("", ViewData.TemplateInfo.FormattedModelValue)

By this point, we now have a correctly functioning textbox that will be populated with a value from the model, and will submit the correctly named field. So it functions exactly as it did before we started with this editor template nonsense, minus a few CSS classes. Given this, is there even a point to making a custom editor template? If you stop now, then no. But let's tweak our editor template code just a bit further:

@model DateTime?
@Html.TextBox("", string.Format("{0:MM/dd/yyyy}", ViewData.TemplateInfo.FormattedModelValue), new { data_datepicker = true })

Now we've got something. Instead of just using the FormattedModelValue, we're calling string.Format to show the date portion of the DateTime. Since we don't care about the time for DateUploaded, we don't need to see it. We also have included an anonymous object, setting data_datepicker to true. For this overload of the TextBox method, the third parameter is an object that will be used to set attributes on the HTML element that gets generated. Here is the HTML output:

<div class="editor-field">
    <input data-datepicker="True" data-val="true" data-val-required="The DateUploaded field is required." id="DateUploaded" name="DateUploaded" type="text" value="">
    <span class="field-validation-valid" data-valmsg-for="DateUploaded" data-valmsg-replace="true"></span>
</div>

Notice the addition of the "data-datepicker" field. (aside: the view engine has converted our underscore to a hypen -- this is because hypens aren't allowed in identifiers in C#.) We can pick up on this in javascript and assign datepickers to our field:

$(function() {
    $("[data-datepicker]").datepicker();
});

As simple as that. If we add that javascript to our _Layout.cshtml file, it will show up on every single page. With our DatePicker editor template, we can now instantly attach a jQuery UI datepicker to an editor, simply by setting the template name parameter to "DatePicker".

For more information, check out our website.

Enhancing Your Entity Repositories

Using a repository pattern for data access gives you clear separation and abstraction in your data layer.  The basic idea of adding repositories for data access is illustrated nicely on MSDN:

In the case of an MVC application, your controllers fit into the "Client Business Logic" area, and your Database resides in the "Data Source" area.  What's left is the repository itself, here is a typical example generated using the MVC Scaffolding project.

namespace DataModel.Models
{
    public class PartyRepository : IPartyRepository
    {
        public IQueryable<Party> All
        {
            get { return _context.Parties; }
        }
        public IQueryable<Party> AllIncluding(params Expression<Func<Party, object>>[] includeProperties)
        {
            IQueryable<Party> query = _context.Parties;
            foreach (var includeProperty in includeProperties) {
                query = query.Include(includeProperty);
            }
            return query;
        }
        public Party Find(int id){ return _context.Parties.Find(id);}
       
  //Methods removed for brevity
    }
    public interface IPartyRepository : IDisposable
    {
        IQueryable<Party> All { get; }
        IQueryable<Party> AllIncluding(params Expression<Func<Party, object>>[] includeProperties);
        Party Find(int id);
        //Methods removed for brevity
    }
}

The repository itself abstracts the dirty work of dealing with the context, and provides a great element of re-usability in your application (you can inject a repository anywhere you like and it will use the same context code).  Here are some sample use cases for some of the above methods:

_repository.Find(id); //simple lookup
_repository.All; //get everything
_repository.AllIncluding(model => model.Property1, model => model.Property2); //Get all and include some navigation properties
_repository.AllIncluding(<insert ALL navigation properties>); //Full eager fetch

Simple enough, but this structure raises some concerns:

1. Specifying the navigation properties in your controller actions when using the repositories feels like a violation of your abstractions.  Dealing with relationships between data driven objects should stick to the data layer as much as possible.
2. There really isn't a good method to do a full eager fetch in this scenario.  You could provide all of the include properties but that creates a maintainability issue when you add a new navigation property and have to change every location you used the including options.

Our solution to this issue was a small and simple re-working of these methods, here is an example from another object:

namespace DataModel.Models
{
    public class DocumentRepository : IDocumentRepository
    {
        private readonly Expression<Func<Document, object>>[] _allIncludes =
            {
                d => d.Department,
                d => d.Organization,
                d => d.DocumentStatus,
                d => d.DocumentType,
                d => d.FavoriteUsers
            };
        public IQueryable<Document> All(params Expression<Func<Document, object>>[] includeProperties)
        {
            IQueryable<Document> query = _context.Documents;
            foreach (var includeProperty in includeProperties)
            {
                query = query.Include(includeProperty);
            }
            return query.Where(doc => doc.Organization.AccountId == accountId);
        }
        public IQueryable<Document> All(bool eager, params Expression<Func<Document, object>>[] includeProperties)
        {
            var includes = eager ? _allIncludes : includeProperties;
            return All(accountId, includes);
        }
        public Document Find(int id, params Expression<Func<Document, object>>[] includeProperties)
        {
            IQueryable<Document> query = _context.Documents;
            foreach (var includeProperty in includeProperties)
            {
                query = query.Include(includeProperty);
            }
            return query.SingleOrDefault(doc => doc.Id == id);
        }
        public Document Find(int id, bool eager, params Expression<Func<Document, object>>[] includeProperties)
        {
            var includes = eager ? _allIncludes : includeProperties;
            return Find(id, includes);
        }
  //Methods removed for brevity
    }
    public interface IDocumentRepository
    {
        IQueryable<Document> All(params Expression<Func<Document, object>>[] includeProperties);
        IQueryable<Document> All(bool eager = false, params Expression<Func<Document, object>>[] includeProperties);
        Document Find(int id, params Expression<Func<Document, object>>[] includeProperties);
        Document Find(int id, bool eager = false, params Expression<Func<Document, object>>[] includeProperties);
        //Methods removed for brevity
    }
}

We simply added an eager option and an overload for the Find and the All(converting it from property to method).  Here are the new use cases:

_repository.Find(id); //simple lookup
_repository.All(); //get everything - lazy loaded
_repository.All(model => model.Property1, model => model.Property2); //Get all and include some navigation properties
_repository.All(true); or the more readable: _repository.All(eager:true); //Full eager fetch

With this modification, controlling the type of fetch you want to do is much more clear, and if we add navigation properties to the model, we only need to update the allIncludes property in the repository, not everywhere the repository is used for eager fetching.  We also still preserved the ability to lazy load, as well as specify exactly the properties you want during a fetch.

A side effect though, is we have some strange edge cases that result, for example:

_repository.All(eager:true, model => model.Property1);

In this case, the provided property is ignored and all properties are fetched.  We chose to lay the blame for this sort of issue on the developer as there are easier ways to use the methods to achieve the desired result, whatever that may be.

All code examples taken from our next version of Contract Guardian.

For more information, check out our Web Site.