1

We're building a dynamic complex form application. Because of it's complexity (a lot of inheritance and complex types), the names and id's that are generated are big (huge?).

Therefore we would like to modify the way MVC is generating the id and name attributes. I used reflector (and google / stackoverflow) to figure out where that's done:

  • Id's are generated using: ViewData.TemplateInfo.GetFullHtmlFieldId(...)
  • Names are generated using: ViewData.TemplateInfo.GetFullHtmlFieldName(...)

We are using the '...For' build in helper methods to generate labels, textboxes, validation messages, ...

  • Here is an example of a generated id: ZForm_Part_1__Repeater_0__RepeatingPart_0__ContactSelectList_0__PersonData_TelephoneAddress_Number_FormattedNumber
  • Here is an example of a generated name: ZForm.Part[1].Repeater[0].RepeatingPart[0].ContactSelectList[0].PersonData.TelephoneAddress.Number.FormattedNumber

Since the size and complexity of our forms this adds up to several tens of kilobytes for one form.
Why is it on 1 page? Because it's a requirement ;)

For now I see 2 options how we could change the way these id's are generated. I don't really any of them and was wondering if there's a cleaner way to do what we want?
Here are the options I see:

  1. Copy/paste the source of the necessary helper methods, including the private InputHelper(...) and modify the InputHelper to call our own version of GetFullHtmlFieldName (is this legal?)
  2. Write some kind of filter that would hack into the generated html and use some regexp kungfu to filter out all id and name attributes and tranform them to a shorter version.

The end result should generate names like this: 

Z.P[1].Rep[0].RP[0].CSL[0].PD.Tel.N.FormattedNumber

I hope I wrote enough details to understand the thing we're after.
Ideal would be if the name / id generating logic would be plugable.

Manu.

ps: It is similar as this question.

Community
  • 1
  • 1
TweeZz
  • 4,779
  • 5
  • 39
  • 53
  • Suggestion: I recently managed to do something like this by manually setting `ViewContext.ViewData.TemplateInfo.HtmlFieldPrefix` in a custom editor template; depending on how you go about things, this might work for you too? – Jordan Gray Nov 07 '12 at 11:43

2 Answers2

1

You could use view models which have class and property names matching those requirements. Because I suppose that even if you find a way to modify how those attributes are generate by HTML helpers you will also want to bind values back to some view models when the form is submitted. So in addition to this you will have to write custom model binders to handle this situation which might become quite a lot of a job.

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • Hi Darin, Thx for the (very) quick reply! We already have a custom model binder which is able to fill the complex object structure from the incoming http request. It is also already prepared to handle those 'shortnames'. In fact we have a quick prototype that uses the first possible solution I mentioned (copy pasting all the source code we need, including some internal methods from the framework). Is this legal? I hope someone could come up with a cleaner solution. – TweeZz May 16 '11 at 11:21
  • It is legal; it's open source, with a compatible license. – Simon Bartlett May 16 '11 at 11:43
  • I prefer adapting the framework source to our needs above having classes with unreadable names :) But I guess using your approach is another way to go.. – TweeZz May 16 '11 at 15:45
1

You could download the MVC source code (from http://aspnet.codeplex.com), make changes, compile, and reference the new assembly.

You'll probably want to change System.Web.Mvc.TemplateInfo, overriding the GetFullHtmlFieldId and GetFullHtmlFieldName methods

Simon Bartlett
  • 2,010
  • 14
  • 15
  • Although I'm not really in favor of doing that (because when a new release of MVC is made I will need to do it again), I'll mark this one as the answer. – TweeZz May 16 '11 at 15:40
  • I did look into whether there was an easier way of modifying the behaviour, but lots of the classes in MVC are either sealed or non-virtual. Also you'll be in the same position if you copy and paste loads of classes out from MVC - you'll have to maintain all of those. – Simon Bartlett May 17 '11 at 08:00