Skip to content
This repository has been archived by the owner on Dec 14, 2018. It is now read-only.

Make HTML helper parameter names consistent #944

Closed
dougbu opened this issue Aug 6, 2014 · 3 comments
Closed

Make HTML helper parameter names consistent #944

dougbu opened this issue Aug 6, 2014 · 3 comments

Comments

@dougbu
Copy link
Member

dougbu commented Aug 6, 2014

The current MVC 6.0 parameter names are inconsistent between the HTML helper methods. This is a chance to clean up those inconsistencies. Fortunately I can only find a few shared parameters with multiple names. Unfortunately changing the first example below would introduce a small breaking change between MVC 5.2 and 6.0, affecting people using named parameters when calling these methods. (The parameter names look like they were carried over from MVC 5.2 but I didn't check carefully.)

For the string expression name parameters in IHtmlHelper:

  • @Html.CheckBox() and most others use the parameter "name"
  • @Html.DisplayName() and some others use the parameter "expression"
  • @Html.ValidationMessage() uses the parameter "modelName"

With the possible exception of @Html.Display() and @Html.Editor(), should name this parameter "name" everywhere. Making an exception for those two because they have multiple name-related parameters.

The other option would be to use "shortName" everywhere but for @Html.GenerateIdFromName(). That exception is the only one that takes a fully-qualified expression name. Everything else takes an expression name relative to the current model.

For the IHtmlHelper or IHtmlHelper<TModel> parameters of the extension methods:

  • @Html.CheckBox() and most others use the parameter "htmlHelper"
  • @Html.Display() and some others use the parameter "html"
  • @Html.ActionLink() uses the parameter "helper"

"htmlHelper" seems fine to use everywhere.

For the expression result type parameter:

  • @Html.HiddenFor() and most others use the type parameter name "TProperty"
  • @Html.DisplayFor() and a few less others use the type parameter name "TValue"

Though less-used, "TValue" is actually more correct. "TResult" might be better still.

@dougbu dougbu changed the title Make HTML helper parameter names consistent Muscle memory failure: Make HTML helper parameter names consistent Aug 13, 2014
@danroth27 danroth27 added this to the 6.0.0-rc1 milestone Sep 30, 2014
@yishaigalatzer yishaigalatzer changed the title Muscle memory failure: Make HTML helper parameter names consistent Make HTML helper parameter names consistent Sep 30, 2014
@yishaigalatzer yishaigalatzer modified the milestones: 6.0.0-beta3, 6.0.0-rc1 Jan 14, 2015
@dougbu
Copy link
Member Author

dougbu commented Feb 14, 2015

decided on the following:

  • name all string expression name and Expression<Func<TModel, TResult>> parameters "expression"
    • single special case is GenerateIdFromName(string fullName) since every other expression name is relative to the current ViewData,TemplateInfo.HtmlFieldPrefix value
  • name all this parameters of type IHtmlHelper or IHtmlHelper<TModel> "htmlHelper"
  • rename TProperty and TValue to TResult

dougbu added a commit that referenced this issue Feb 16, 2015
- #944
- name `string` expression name and `Expression<Func<TModel, TResult>>`
  parameters "expression"
 - single special case is `GenerateIdFromName(string fullName)` since every
   other expression name is relative to the current
   `ViewData,TemplateInfo.HtmlFieldPrefix` value
 - applied from `IHtmlHelper` and `IHtmlGenerator` on up
- name `IHtmlHelper` and `IHtmlHelper<TModel>` parameters "htmlHelper"
- rename `TProperty` and `TValue` type parameters to `TResult`

nits:
- clean up abbreviated names in `CachedExpressionCompiler`
- change `ObjectToDictionary()`'s parameter name to `value`
- use `nameof` more to make renaming (and refactoring) easier in the future
- rewrap parameters and arguments to avoid long lines and orphans
dougbu added a commit that referenced this issue Feb 16, 2015
- #944
- name `string` expression name and `Expression<Func<TModel, TResult>>`
  parameters "expression"
 - single special case is `GenerateIdFromName(string fullName)` since every
   other expression name is relative to the current
   `ViewData,TemplateInfo.HtmlFieldPrefix` value
 - applied from `IHtmlHelper` and `IHtmlGenerator` on up
- name `IHtmlHelper` and `IHtmlHelper<TModel>` parameters "htmlHelper"
- rename `TProperty` and `TValue` type parameters to `TResult`

nits:
- clean up abbreviated names in `CachedExpressionCompiler`
- change `ObjectToDictionary()`'s parameter name to `value`
- use `nameof` more to make renaming (and refactoring) easier in the future
- rewrap parameters and arguments to avoid long lines and orphans
dougbu added a commit that referenced this issue Feb 17, 2015
- #944
- name `string` expression name and `Expression<Func<TModel, TResult>>`
  parameters "expression"
 - single special case is `GenerateIdFromName(string fullName)` since every
   other expression name is relative to the current
   `ViewData,TemplateInfo.HtmlFieldPrefix` value
 - applied from `IHtmlHelper` and `IHtmlGenerator` on up
- name `IHtmlHelper` and `IHtmlHelper<TModel>` parameters "htmlHelper"
- rename `TProperty` and `TValue` type parameters to `TResult`

nits:
- clean up abbreviated names in `CachedExpressionCompiler`
- change `ObjectToDictionary()`'s parameter name to `value`
- use `nameof` more to make renaming (and refactoring) easier in the future
- rewrap parameters and arguments to avoid long lines and orphans
dougbu added a commit that referenced this issue Feb 18, 2015
- #944
- name `string` expression name and `Expression<Func<TModel, TResult>>`
  parameters "expression"
 - single special case is `GenerateIdFromName(string fullName)` since every
   other expression name is relative to the current
   `ViewData,TemplateInfo.HtmlFieldPrefix` value
 - applied from `IHtmlHelper` and `IHtmlGenerator` on up
- name `IHtmlHelper` and `IHtmlHelper<TModel>` parameters "htmlHelper"
- rename `TProperty` and `TValue` type parameters to `TResult`

nits:
- clean up abbreviated names in `CachedExpressionCompiler`
- change `ObjectToDictionary()`'s parameter name to `value`
- use `nameof` more to make renaming (and refactoring) easier in the future
- rewrap parameters and arguments to avoid long lines and orphans
@dougbu
Copy link
Member Author

dougbu commented Feb 18, 2015

Fixed in commits 8eb6327 and 966bfeb

@dougbu
Copy link
Member Author

dougbu commented Feb 18, 2015

Removed Task label so this minor breaking change shows up in the next release notes. Unlikely anyone is using named parameters here but just in case...

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants