I suggest you ...

Allow us to provide an alternate name

Allow us to provide alternate names for input elements using DataAnotation for Model-Properties. Sample:

[AlternateNames(true, "un", "cn")]
public int UserName {get;set;}

So the DefaultModelBinder respects this attribute and searches for "UserName", if not found searches for "un" and finally for "cn".

Helpers like TextBoxFor<> should also consider this attribute. When the first boolean argument is true (force alternate name) the HtmlHelper should choose the first alternate name as the input name ("un") otherwise choose the property name.

This attribute would allow to use models for forms that are posting to pages that are using other technologies or minimize parameter names but keeping meaningful property names.
We are currently migrating from asp.net webforms and a custom presentation layer to mvc and do have to reimplement a lot of stuff in mvc 3 to keep compatibility between the technologies.

Thanks!
Jens

126 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Jens HofmannJens Hofmann shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    8 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Jens HofmannJens Hofmann commented  ·   ·  Flag as inappropriate

        @Daniel Roth: Multiple aliases are needed when you migrate a large web application to MVC. I did this 4 years ago and we had to support all the old parameters. When migrating legacy code, you often find pages having multiple parameters with the same meaning. Those alternatives are all supported for backward compatibility because parameters were renamed in the past and for old links to be supported, they were kept working.

        Yepp I know one could solve this partially using routes but this would end up in lots of routes, because a few of those "multiple" alternative parameters were global parameters uses in a high percentage of pages.

      • PeterPeter commented  ·   ·  Flag as inappropriate

        As a rule of thumb we should have control over everything that ends up in the final HTML, so please don't look for "use cases" that you could "solve"... just give us the control. You'll never be able to anticipate all the possible cases.

        Now, if you're just curious: one scenario is when the output of the form needs to be posted somewhere else. Or some third-party library expects the name to be DPN rather than DescriptivePropertyName.

      • Jens HofmannJens Hofmann commented  ·   ·  Flag as inappropriate

        @Jeffrey This does only solve half the problem. The most important part is to get the Helper-Methods (TextBoxFor.. and so on) to respect it during html name-attribute binding. And there is no existing hook usable to implement it. We implemented wrappers around the standard Helpers to solve the problem.

      Feedback and Knowledge Base