Opinionated Input Builders for ASP.Net MVC – Part 3 the source code.

Thank you for submitting this cool story - Trackback from DotNetShoutout

Pingback from  Opinionated Input Builders for ASP.Net MVC ??? Part 3 the source …

Thanks man!  Great stuff.  I love that you structured this in a way that it can easily be used across projects.  Wonderful.

Pingback from  Daily Links for Wednesday, June 10th, 2009

Part 1 – Overview Part 2 – the Labe l Part 3 – the Source Code Part 4 – the Partial View Part 5 – the

Pingback from  Opinionated Input Builders for ASP.Net MVC ??? Part 3 the source code. - Eric Hexter -

Pingback from  Opinionated Input Builders for ASP.Net MVC - Part 2 Html Layout for the Label - Eric Hexter -

Eric Hexter is continuing his multi - part series on Opinionated Input Builders . He’s on a role! They are expression-based, meaning they eliminate the need for most strings for Html Helpers in your views. Part 1 – Overview Part 2 – the Labe l Part 3

Pingback from  Opinionated Input Builders for ASP.Net MVC ??? Part 5 the Required input - Eric Hexter -

Pingback from  Daily Links for Thursday, June 11th, 2009

Part 1 – Overview Part 2 – the Labe l Part 3 – the Source Code Part 4 – the Partial View Part 5 – the

Part 1 – Overview Part 2 – the Labe l Part 3 – the Source Code Part 4 – the Partial View Part 5 – the

Part 1 – Overview Part 2 – the Labe l Part 3 – the Source Code Part 4 – the Partial View Part 5 – the

Hi Eric,

This looks great! I'd love to use it, but have encountered problem. (crash). Here's what I did:

1. Downloaded and compiled Input Builders v4

2. Added to my Input Builders project

3. Created a new view with just one field:

<%=Html.Input(m=>m.SearchString)%>

Now whenever the view is executed, I get a NullReferenceException in line 106 of InputBuilder\DefaultConventions.cs.

The problem seems to be line 181 of ReflectionHelper.cs :

var propertyInfo = ((MemberExpression)expressionToCheck).Member as PropertyInfo;

This cast fails. My reflection skills are not highly evolved to tell what is going wrong though. If you need any more info, please let me know.

Thanks,

Adrian

Thanks for the hint, the property was indded just a model field. It works fine now.

One other thing I noticed: Having an action method like this results in a crash:

       //

       // GET: /Search/

       [AcceptVerbs(HttpVerbs.Get)]

       public virtual ActionResult Index()

       {          

           return View();

       }

The model has to be explicitly intialized in the controller like this:

       //

       // GET: /Search/

       [AcceptVerbs(HttpVerbs.Get)]

       public virtual ActionResult Index()

       {

           return View(new ViewModel());

       }

If the model contains any child entities, these also have to be explicitly initalized before the view can be rendered. This is certainly not a big issue, but it differs from the standard Html helper implementation.

Also, I've tried converting one of my site's forms to your implementation and mostly worked fine, but there's one problem I don't know how to circumvent without altering your implemetation.

I usually have text inputs with a maximum and minimum size, for example:

<%= Html.TextBoxFor(m => m.User.Email, new { maxlength = 80,size=50 })%>

Maxlength could be retrieved by ModelPropertyFactory.Create from a StringLength attribute applied to the model property. But the field size cannot be guessed just by looking at the model. And I might also want to set a special class on the input field, which also does not seem to work with the current implementation.

I guess the only workaround is coding an override that allows me to attach arbitrary input field attribute like this:

<%=Html.Input(m=>m.SearchString, new { maxlength = 80,size=50 })%>

But I hate branching other people's code, especially since I assume you are going to further improve and update your implementation. Would you consider implementing this feature or adding it to your implementation if I implement it and send you the altered code?

Thanks,

Adrian

@Eric: You're right, the fluent syntax you propose is a bit safer than the syntax I had in mind since there would no way to misspell properties. It's a bit more overhead because it means creating an extension method for each property, but I would definitely prefer it.

I'd definitely prefer to have this in the view, because this gives me more flexibility. Also, specifying a strongly view-related property such as a CSS class with model attributes would feel a bit odd.

Oh, one thing I forgot: In the case of MaxLength, I would actually prefer Html.Input to figure this out by itself by looking at the StringLength attribute applied to the model property.

  Part 1 – Overview Part 2 – the Labe l Part 3 – the Source Code Part 4 – the Partial View Part

Pingback from  Summary 11.06.2009 – 02.07.2009 «  Bogdan Brinzarea’s blog

Pingback from  Opinionated Input Builders for ASP.Net MVC using partials ??? Part 1 - Eric Hexter -