Display Placeholder

By Ryan at October 21, 2009 10:55
Filed Under: Development

Whilst playing with MVC 2, I came upon the need to display an element that I could later replace as the result of an AJAX callback.  Starting with the DisplayFor<> HtmlHelper extension, I found that it simply outputs the given value as a string, with no way to later replace it.  I could create a custom display template, but I wanted more fine-grained control.

So, I decided that needed some way to create a display element wrapped in a <span> tag.  With a <span> tag and an id, I would be able to display the model-bound data, but later replace it as the result of a AJAX callback.

This is what I came up with:

   1:  /// <summary>
   2:  /// Creates a placeholder element displaying the value given by <paramref name="display"/>.
   3:  /// </summary>
   4:  /// <typeparam name="TModel">The type of the model.</typeparam>
   5:  /// <typeparam name="TValue">The type of the value.</typeparam>
   6:  /// <param name="html">The HtmlHelper being extended.</param>
   7:  /// <param name="display">The property from the model to display.</param>
   8:  /// <returns>An <see cref="MvcHtmlString"/> containing the display value wrapped in a &lt;span&gt; tag</returns>
   9:  public static MvcHtmlString PlaceholderFor<TModel, TValue>( this HtmlHelper<TModel> html, Expression<Func<TModel, TValue>> display ) {
  10:   
  11:     return PlaceholderFor( html, display, null );
  12:  }
  13:   
  14:  /// <summary>
  15:  /// Creates a placeholder element displaying the value given by <paramref name="display"/>.
  16:  /// </summary>
  17:  /// <typeparam name="TModel">The type of the model.</typeparam>
  18:  /// <typeparam name="TValue">The type of the value.</typeparam>
  19:  /// <param name="html">The HtmlHelper being extended.</param>
  20:  /// <param name="display">The property from the model to display.</param>
  21:  /// <param name="htmlAttributes">The HTML attributes.</param>
  22:  /// <returns>An <see cref="MvcHtmlString"/> containing the display value wrapped in a &lt;span&gt; tag</returns>
  23:  public static MvcHtmlString PlaceholderFor<TModel, TValue>( this HtmlHelper<TModel> html, Expression<Func<TModel, TValue>> display, IDictionary<string, object> htmlAttributes ) {
  24:   
  25:     ModelMetadata metaData = ModelMetadata.FromLambdaExpression( display, html.ViewData );
  26:     TagBuilder tag = new TagBuilder( "span" );
  27:     tag.GenerateId( metaData.PropertyName );
  28:     if( htmlAttributes != null ) {
  29:        tag.MergeAttributes( htmlAttributes );
  30:     }
  31:     tag.SetInnerText( Convert.ToString( metaData.Model, CultureInfo.CurrentCulture ) );
  32:     return MvcHtmlString.Create( tag.ToString( TagRenderMode.Normal ) );
  33:  }

ASP.NET WebForms vs MVC

By Ryan at October 06, 2009 08:23
Filed Under: Development

This is from an email that I sent out trying to elaborate on why I chose MVC over WebForms for my latest side project.

I wanted to come back to the discussion we had yesterday about the differences between MVC and WebForms.  I don't dislike WebForms, they have their place, I just feel that they are more suited to a form-centric, "business application"-type web application.  I suppose this is because WebForms do a good job of collecting data in a simple way; public websites need to provide a more rich user experience (to meet current user expectations) that seems to be difficult to achieve out-of-the-box with WebForms.

I see WebForms as a component-based model, where MVC is an object-oriented model.  As such, we've seen the ViewState in WebForms require lots of work-arounds in the [our legacy code], for example, because as soon as you try to combine the object-oriented world with the component/event-driven world, there's a mismatch.

Now, as I see it, the decision to use MVC will mean that we lose

  • Drag-and-drop page construction
    • As we've seen, you lose that pretty fast as soon as you do anything half-complicated. 
  • ViewState, but, as we've seen, this has caused problems and required work-arounds in the past.
    • We don't lose statefulness, just the viewstate and the goofy generated IDs
  • Solid componentization
    • There are components and reusable UI elements in MVC, but not a solid as WebForms
  • The abstraction of HTML and CSS
    • Sorry, you'll need to know HTML and CSS, but I'd argue that you SHOULD know HTML and CSS if you want to call yourself a web developer (unless you only want to ever work with webforms, only in .NET - why would you limit yourself?)


On the flip-side, we'll gain:

  • More consistent object-oriented development
    • Better testability (find a bug, fix it once, and have a test to make sure it never shows up again, BDD)
    • Better decoupling/separation of concerns
  • More control over presentation
    • More granular control over markup
    • Better statefulness (using client-side javascript and AJAX)
  • More marketable skills
    • Knowledge of another Microsoft framework
    • Better knowledge of what good HTML looks like
    • Better understanding of CSS
    • Better understanding of the DOM
    • Better understanding of cross-browser compatibility
    • Better knowledge of how HTTP actually works ;)

Lastly, since you've made me do it, remember those Telerik controls that we used for [the last revision of our .NET app]?  Yeah, they'd work with MVC too:

http://www.telerik.com/products/aspnet-ajax.aspx

Microsoft ASP.NET MVC - ready
With RadControls you no longer have to stick with simplistic UIs in your MVC Views. Telerik UI controls support Microsoft MVC and allow you to combine the testability and separation of concerns of the emerging technology with the richness of traditional ASP.NET server controls. See demo or visit our MVC Forums

Hopefully this has convinced any skeptics that the decision to ASP.NET MVC is a good one.

Building a New Site

By Ryan at October 05, 2009 21:00
Filed Under: Development

I working on building a new website in my spare time.  I've decided to use this opportunity to play with ASP.NET MVC.  I put together a long list of pros and cons for ASP.NET WebForms versus MVC; perhaps I'll post it.

 

Anyway, when I started laying the groundwork, I went with the RTM version of MVC (v.1), but I was too compelled by the upcoming of features of v2 that I decided it makes sense to throw caution to the wind and lay down the UI framework with it.

 

I haven't had a chance to really dig into the MVC framework; thus far it's been all backend code.  Every now and again, you've got to start an application from scratch to make sure your you're keeping your skillset fresh.  The hardest part of being a developer is creating something from scratch.  After the initial creation, it's just a matter of plugging in functionality and fixing bugs.

 

I will try to treat the blog like a journal for my adventures with MVC, and any website launches that may, or may not, be on the horizon.

About Me

thumbnail I'm a software developer currently employed by Pearson (PSO/PSON)* where I work with, my passion, .NET.  I have (close to) two decades of programming experience and I'm constantly trying to learn new languages, technologies, practices, etc.

 

Disclaimer

* Emerle.net is owned and operated by Ryan Emerle. The views expressed on this blog are his personal opinion and do not necessarily reflect the views of his employer or clients.

The same holds true for comments posted to Emerle.net; they are the comment posters' personal opinion and do not necessarily reflect Ryan Emerle's views or the views of Ryan's employer or clients.