About me

My name is Marko Markovic and I am a software developer, a musician and a researcher. I am intrigued by algorithms and new techniques and I want to improve my software development skills.

While working on different projects I like to document what I have learned. A new technique, a new algorithm, solution to a problem or a tool. The reason I am writing this blog is to help out other people in their programming endeavors and also I write so I won't forget.

If you are interested to find out more about me visit markomarks.com

Sunday, May 26, 2013

MVC Editor Template Checklist

Howdy y'all.

Today's topic is are the MVC Editor templates. I won't be going in what they are and what do they do now, this will be just a checklist to remind you if you have done everything you should, before freaking out why don't they work, bind correctly, post null and etc.

Editor templates on small projects can work OK, but on a larger scale project they can cause some serious headaches. If anyone notices that I missed something or maybe wrong please let me know in the comment section bellow.


Some of these steps may seem mundane, but just because of that they are easy to forget.
  1. Object class for the EditorTemplate:
    • Properties - Make sure that the properties in the object class have the public get and set methods. Also, check if all the properties that you need on post are included in the EditorTemplate object class.
    • Constructor - Empty constructor is required in each object class and inside of that constructor you should put any additional instantiations of the child objects.

      If there is an EditorTemplate object inside of a another EditorTemplate, make sure that you have instantiated that object in parent empty constructor.

      Also, if you are using list of EditorTemplate objects make sure you have instantiated the list in the parent constructor.
  2. EditorTemplate Views:
    • Non-Rendered Properties - Any properties you will need on the post controller method, the View needs to have them. If you don't want to display/render them, put them as hidden fields (hiddenfor, <input> and similar).

      An example of that would be an int ID of the product. User doesn't need to see it, but you will need it for identification of the product so you can insert/update the item in the database.

      Additionally, make sure that at least on of the properties in the EditorTemplate class object is displayed, edited or similar on the view via the EditorFor, DisplayFor, LabelFor, HiddenFor or similar Html helper method. Not using the helper method could result in null objects when doing a form post.

    • Looping - If you have a list of editor template objects in the parent view that you need to present, don't ever, I mean ever use foreach loops. Use for loops with indexers and when you are using editorfor use the list[index] for using the editor template.

      There is a possibility of passing the list itself to editorfor method call but if you want additional handling while iterating you will probably use for loop.

      Example of the looping, the list property is a list of Objects that are used in EditorTemplates
      
      
      for(int i=0; i < Model.list.Count; i++)
      {
         @Html.EditorFor(m => m.list[i])
      }
      
      
      Also try to avoid double looping of the same EditorTemplate object list. The object binder tends to get confused with it, at work I got a null object just because I have tried to loop the same list twice. If you need multiple looping on the view, maybe putting the logic of creating the list in the code behind will help. It helped me :).
    • Inside Loop Logic - On the view you cannot temper much with the EditorTemplate object in the list, meaning you cannot assign an item of the list to a new variable, do some calculations with that variable, display it and expect those changes to be included on the post method. Your new variable will exist on the rendered view but it will be lost as soon as you post the form. When you post, the editor template object will be destroyed and recreated again. During the binding process, it will rebind the properties of the object with the new and updated data.

      Try to include as much logic as you can before rendering the data. If additional logic is on the view itself, you will need to work with the original item, meaning you have to access it the long way with list indexers.

      Example of it would be: list[index].subList[subIndex].Property = newValue;
Hope this one was really useful as it is for me. 
Don't loose your heads,
Until next time

No comments:

Post a Comment

Blog Archive