T4MVC does not support DisplayTemplates and EditorTemplates

Question

I've noticed this when I used the following in my view:

<% Html.RenderPartial(MVC.Shared.Views.EditorTemplates.ClientOnDocuments); %>

The line above returns just the name of the view, so in this case ClientOnDocuments. The default view engine then kicks in and tries to find ClientOnDocuments.ascx in the current view's folder and in the Shared folder but not in DisplayTemplates and EditorTemplates folder.

Since I've gone pretty far with my use of T4MVC I don't want to dump it or mix different styles of referencing views (for instance, the above works if we provide the path to the template).

The reason lies in this code that T4MVC generates:

    public class ViewNames {
    ...
        public readonly string FirmHeader = "~/Views/Shared/FirmHeader.ascx";
        public readonly string PostsSelector = "~/Views/Shared/PostsSelector.ascx";
        static readonly _DisplayTemplates s_DisplayTemplates = new _DisplayTemplates();
        public _DisplayTemplates DisplayTemplates { get { return s_DisplayTemplates; } }
        public partial class _DisplayTemplates{
            public readonly string ClientOnDocuments = "ClientOnDocuments";
            public readonly string DateTime = "DateTime";
        }
        static readonly _EditorTemplates s_EditorTemplates = new _EditorTemplates();
        public _EditorTemplates EditorTemplates { get { return s_EditorTemplates; } }
        public partial class _EditorTemplates{
            public readonly string ClientOnDocuments = "ClientOnDocuments";
            public readonly string DateTime = "DateTime";
            public readonly string PostCode = "PostCode";
        }

You can see that with the view contained in Shared root everything is fine but apparently it doesn't handle subfolders well.

I know I could change the T4MVC template file but would actually like a response from David Ebbo on whether he is going to change/correct this.

Hopefully he follows SO, at least I saw him here in December.

what would be even better is to have two classes: ViewNames (which would contain only the names of the views) and ViewPaths, which would contain the paths, that way we get access to both strongly typed names and paths. — mare, Feb 02 '11 at 01:06

score 4 · Accepted Answer · answered Feb 02 '11 at 23:59

Interestingly, this different behavior was put in deliberately after another user ran into issues. Look for this in the T4MVC.settings.t4:

// Views in DisplayTemplates and EditorTemplates folders shouldn't be fully qualifed as it breaks
// the templated helper code
readonly string[]  NonQualifiedViewFolders = new string[] {
  "DisplayTemplates",
  "EditorTemplates"
};

So normally, sub folders get full paths, but only those two don't.

I think the difference was that that user was calling DisplayFor/EditorFor to render those, while you are calling RenderPartial.

In any case, since this is in the settings file and not the main template, you can simply change the list if you don't want that behavior, i.e.

readonly string[]  NonQualifiedViewFolders = new string[] { };

Hope this helps! :)

So using this lets you refer to the path of the view via T4MVC but then DisplayFor/EditorFor would then not be able to find the views, right? Too bad, as there's one DisplayTemplates view that I'm using both via DisplayFor and in a PartialViewResult (in different contexts). I suppose I'll have to write out the qualified path as a string in the controller if I want to continue using DisplayFor. — adamjford, Feb 15 '11 at 15:25
For DisplayTemplates and EditorTemplates, could we not just have new properties one for the full path and the other for the as expected behaviour? — PBo, Oct 01 '17 at 20:07

T4MVC does not support DisplayTemplates and EditorTemplates

1 Answers1