Call: +1 (917) 460-0063 - Or - +1 (876) 630-3807

Our Idea of a Inner Html Tag Action Link MVC HTML Extension

Date: June 16, 2013 Author: Curtis Category: Coding Comments: 4

A Inner Html Tag Action Link MVC HTML Extension

In my early days of  using Asp.Net MVC, I use to complain "why didn't they created an Html helper, out-of-the-box that supports inserting one Html tag inside of another. It seems so logical, why didn't Microsoft think of this?

Because I am a Microsoft advocate, I decided that Microsoft had think to themselves: "Hey! If we should give them everything that they would ever need, they would stop thinking for themselves, and the elite few of the human race (Computer Developers), would become lazy and star to die off."

Well right you are again Microsoft; preserve the elite few. After all, it is us who will have to carry the human race forward on our backs. Don't make it any more difficult for any of us by allowing us to become lazy.

So realizing this, I had resolve that i would figure it, and write my own. I started out by first creating what I called a InnerHtmlActionLink extension (A pretty cool name isn't it   🙂 ).

Voila! Here it is:

using System.Web.Mvc;
using System.Web.Mvc.Html;
namespace Helpers
    public static class ActionLinkExtensions
        public static MvcHtmlString InnerHtmlTagActionLink(this HtmlHelper htmlHelper, string innerHtmlTagName,
                                                           string actionName, object routeValues, object htmlAttributes,
                                                           object innerHtmlHtmlAttributes = null)
            return InnerHtmlTagActionLink(htmlHelper, innerHtmlTagName, "", actionName, routeValues, htmlAttributes,

        public static MvcHtmlString InnerHtmlTagActionLink(this HtmlHelper htmlHelper, string innerHtmlTagName,
                                                           string linkText, string actionName, object routeValues,
                                                           object htmlAttributes, object innerHtmlHtmlAttributes = null)
            // generate a normal link using the regular MVC HTML helper
            var linkHtml =
                htmlHelper.ActionLink(linkText: " ", actionName: actionName, routeValues: routeValues,
                                      htmlAttributes: htmlAttributes).ToHtmlString();

            // build the new inner tag
            var tag = new TagBuilder(innerHtmlTagName);

            // if attributes were supplied apply them
            if (innerHtmlHtmlAttributes != null)
                tag.MergeAttributes(HtmlHelper.AnonymousObjectToHtmlAttributes(innerHtmlHtmlAttributes), true);

            // set the link text to inside of the inner tag

            // insert the inner tag into the anchor tag
            linkHtml = linkHtml.Insert(linkHtml.Length - 4, tag.ToString());

            return new MvcHtmlString(linkHtml);
  1. Date: January 11, 2014
    Author: Denroy

    I would also add controlerName as a parameter to InnerHtmlTagActionLink. [Reply]

    • Date: January 13, 2014
      Author: Curtis

      The routeValues parameter would handle controller name part of the tag generation. Or may be I am not fully understanding what you are saying. Please elaborate. [Reply]

  2. Date: April 22, 2014
    Author: Wasia

    , mostly indpnendeet and there really is no reason not to use RenderAction for such usage IMVHO anyway, but I think you'd agree.What I don't get is the claim that calling RenderAction does not retain all the business logic in the controllers . It seems to me to be quite the opposite. The view reaches a point where it *can't* simply render the data it was given; basically, it lacks the data (as in my example the game page has no concept of what a user is, but the avatar partial view does). At this point it gives up and calls a *controller* to do the work for it fetch the necessary data, and even choose the nested view to use to display it.All the business logic is still encapsulated inside controllers. True, the name of the nested control is hard-wired into the view, but then *something* has to be hard-wired there (in your example, the name was latestPosts lets call it the widget name ).It seems to me that the *real* question is not whether the logic is in the view or the controller, but *which* controller it resides in. Using RenderAction, the logic is distributed it resides in the ControlFactory, of course, and also inside the actions of the concrete controls. Using PartialRequest or sub-controllers, (some) logic is concentrated in the top-level controller.So first, I would have liked to see the issue presented in this way. It makes a hell of a lot more sense phrased in these terms than saying RenderAction mixes business logic in the view , which clearly (IMO) it does not. Unless I am missing something really basic that is Having re-phrased the issue I would like to see some compelling example of why the complexity of *another* mapping layer is justified.It seems to me that if you want to concentrate your logic in the top-level controller, go ahead, and as a result pass a larger model to the view to render as it sees fit (using RenderPartial for modularity).If, on the other hand, you want to distribute your logic, well that's what RenderAction already does for you, placing it in each of the invoked controllers. And you can mess with the ControllFactory to flexibly map names to concrete implementation if you need to.Perhaps there is a large class of applications for which there is a middle ground that justifies PartialRequest or even (shudder) sub-controllers, but I can't think of any example off the top of my head. Is this one of the cases where you need to have a large application to justify the architecture? I tend to be suspicious of these P.S. You are right of course about RenderPartial and user controls I am still a bit unclear about the difference between an ascx and an aspx-without-master-page in the context of the MVC framework. Like I said, I'm a new comer to this framework. [Reply]

  3. Date: April 22, 2014
    Author: Dadan

    I am a newbie to the MVC fmrweaork, so perhaps I am missing something obvious here. It was my understanding that the controller's responsibility was to (1) fetch the necessary model and (2) decide on which view to render. The view then simply formats the data given to it in the model.If that is the case, I fail to understand the problem with RenderAction. Sure, it specifies a specific controller name. That seems reasonable; if I want to have some logic deciding what needs to be done at this point of the view, a controller seems like the right place to put it in.How is that different from using a specific controller name as a target of a route? Also, supposing this is a problem, wouldn't using one of the numerous IoC fmrweaorks solve the problem anyway?One possible benefit I can imagine is that it makes it harder to unit-test the view. But wouldn't that be solved with a simple mock ControlFactory that returns canned responses to any RenderAction requests? Surely that would be simpler than sub-controllers or even PartialRender?My team is now seriously entering into using MVC and we need to decide whether we should use (MVC) user controls vs. RenderPartial, and RenderAction vs. PartialRequest vs. SubControllers. I am tending towards using RenderPartial for simple HTML refactoring and RenderAction wherever there is actual logic involved, as the simplest solution (albeit in the futures namespace). But I am nervous that I am missing some deep problem with RenderAction that will bite us once we have large amounts of code.I googled around and while I found plenty of references to the debate and disagreement and how RenderAction breaks separation of concerns . I couldn't find any place that explains the actual problem in clear terms. I looked at SubControllers and PartialRequest and I still don't get what exactly they are trying to solve.Perhaps I am being dense, but He who is not willing to appear stupid in public, shall never reach enlightenment . What am I missing? [Reply]

Leave a Reply

Your email address will not be published. Required fields are marked *