Location of HtmlHelper instantiation for ASP.NET MVC - asp.net

I am trying to debug a problem where HtmlHelper is null in extension methods. Oddly the debugger claims it's fully populated, however I consistently get null exceptions. I'm trying to figure out where HtmlHelper should being instantiated in an attempt to see where my problem may be.
Where should HtmlHelper be Instantiated?
Update: In particular I am trying to implement the extension found here, http://chriscavanagh.wordpress.com/2009/06/11/mvc-authorizedactionlink/, within a masterpage. The error occurs on the MVC template's HomeController.Index(). There are some 'plugins'/virtualpathing that may be causing the problem (trying to avoid this can of worms), but, code the code is essentially the same as found here: http://www.codeplex.com/unifico. However, I don't want to trouble anyone with the details of all of that.

The HtmlHelper is instantiated internally by ASP.NET MVC - it's not something you should generally need to worry about. Exactly where it gets instantiated depends on where you are using it.
The main place it gets instantiated is ViewPage's InitHelpers() method.
In ViewUserControls it gets created on-demand in the getter of the Html property.
In ViewMasterPages it just uses the ViewPage's Html property.

We've encountered this too (oddly, only on 1 of 3 machines), where we have a master page and the content page uses an HtmlHelper.DropDownList. What worked for us was adding using System.Web.Mvc to the master page's codebehind even though it was already in the content page's codebehind.

Related

Sitecore controller rendering causing StackOverflowException

I am trying to do a simple controller rendering with Sitecore 8 and for some reason it's producing a StackOverflowException on the line within the main layout markup that contains the reference to the placeholder it is to be rendered in. This seems to crash the worker process, but you can see the stack overflow on debugging the process:
Here is my very basic controller:
And here is my controller rendering definition:
Reproduction notes:
This is occurring in a vanilla Sitecore 8 installation (rev. 150427 -installed via SIM).
The MVC project is also vanilla -created with empty ASP.NET project, then NuGetting in MVC 5.1.
Web.config & Global added to project from the Sitecore site root in wwwroot.
FYI - everything is absolutely fine doing a view rendering - it's just controller renderings that seem to be causing a problem
So the problem was actually pretty simple in the end.
Returning a ViewResult when the view is intended as a partial view (which all Sitecore renderings will be) then you must set the layout property in the markup to null:
#{
Layout = null;
}
Otherwise MVC will try to wrap the layout file around it, which of course contains your Sitecore placeholder, which causes an infinite loop and crashes the worker process with a StackOverflowException.
So in the context of Sitecore, either return a PartialViewResult or return a ViewResult with the layout set as null.
I guess there is something missing in placeholder setting, could you check in path sitecore/layout/placeholder setting?
There should be a placeholder key which you are trying to use.
Hope this will help
Cheers!!
I think the issue can be with method View() being called without any parameters which can cause re-rendering the whole Sitecore page again.
Try to add parameter to View() like that:
return View("/Views/Courses/Index.cshtml");
Or whatever is the path of the view you want to return.
EDIT:
As #David Masters found, for some reason the issue is with calling View instead of PartialView method with the full path as a parameter. The correct code is:
return PartialView("/Views/Courses/Index.cshtml");

"WebMethod" attribute in the aspx and asmx files, difference?

I noticed in some code that [WebMethod] attribute is used in the code-behind file of an aspx page.
But as I remember it, this attribute is used to expose Web Service and it is often seen in asmx file.
So what's the difference between these 2 usages?
Thanks.
If that method is also static, you can call that method via javascript/ajax, without a full page postback.
Note that your ScriptManager needs to have the EnablePageMethods property set to true.
Webmethods in code behind are used for AJAX calls. If you are using jquery or similar and you need to implement an ajax functionality on your page then you will have to define you method with WebMethod attribute and have to make it public static. Then only it will work.
WebMethod's concept I feel has been taken from web services. Since asp.net didn't have any defined way of handling ajax requests to method of page behind, they have extended this feature to be used for code behind methods.
Keep a watch that being public static methods you may not be able to use your page class' internal properties here. so, you will need to deal with that.

Calling a method on an injected property (from an ASPX page)

I'm teaching myself Spring.NET and to see if I've got everything wired up properly, I'm trying to call a method on an object that I have tried to inject into an ASPX page (I know this isn't probably best practice)
This is in my aspx file (so I'm trying to call the 'orderDescription' getter on the orderService property of this aspx page)
[some html here]
<%= OrderService.orderDescription() %>
[some more html here]
In my Web.config, I've got this in my 'spring, objects' section
<object type="Default.aspx">
<property name="OrderService" ref="orderService"/>
</object>
When I run it, it tells me that I need an object instance before I can call a static method, i.e. it thinks I'm trying to call 'orderDescription' as a static method on OrderService. But Spring is supposed to have injected 'OrderService' as a property of my aspx page, so why can't I call it this way.
I know I'm missing something simple but I can't figure it out. Appreciate any tips
Thanks
Here's a summary of what you need to do to get this working. Originally I was going to say that "Default.aspx" wasn't the name of a class, but I guess spring.net must translate that for you. Did you put the SpringPageHandler configuration in your web.config? Also, do you actually have a property named OrderService defined on the class and of the appropriate type? I would expect that if you did, then you would actually get a NullReferenceException (another small note, you said OrderService.orderDescription() is trying to call the getter on the orderDescription property - but you put parenthesis like it is a method call (if it is just a property it should just be OrderService.orderDescription [no parenthesis])).

Can we call method that exist on aspx page through web service

Can we call a Method that exist on a aspx page through Web Services.
It is like Reflection that method exists in dll form , but is it possible to call method from Aspx page if yes then please tell me how is it?:confused:
The code-behind class in an ASPX page is just a class, so technically there is nothing stopping you from doing that. However, it strikes me as a really bad idea from code design point of view.
The code in an ASPX page class should be related only to that page. If you need the same functionality elsewhere, move the code for that functionality to some other place (such as a class library that can be called from both places).
You should extract common functionality to a class of its own - this way you can call the code from both the web page and the web service and keep them decoupled from each other.

Is it possible to modify ASP.NET to no longer require runat="server"?

I know why runat="server" is currently required (ASP.NET why runat="server"), but the consensus is that it should not be required if you incorporate a simple default into the design (I agree of course).
Would it be possible to modify, extend, decompile and recreate, intercept or otherwise change the behavior of how ASP.NET parses ASPX and ASCX files so that runat="server" would no longer be required? For instance, I assume that a version of Mono could be branched to accomplish this goal.
In case specific requirements are helpful, the following highlights one design:
During parsing, when configured namespace tags are encountered (such as "asp"), default the element's runat property to "server"
During parsing, when configured namespace tags are encountered (such as "asp"), if the element's runat property value is available, then that value should be used in place of the default
New page-level setting introduced (can be set in the page directive or web.config) that specifies the default runat value for a specific namespace tag
I'm afraid you'd have to modify the entire page parser to accomplish this, and I don't think that's possible.
On the other hand, you should be able to create your own. See the buildProviders Element and the BuildProvider class. You should be able to create your own build provider for .aspx pages and use it to replace the built-in provider.
Unfortunately, the PageBuildProvider class used by ASP.NET is internal, and the PageParser class that it uses to parse pages is sealed. You'll be entirely on your own.
Consider that runat="server" has been in ASP.NET for a decade now, and I think you'll see that this won't change anytime soon.
You'd also lose Designer support, but maybe you don't care about that.
So far as I know, there are no hooks deep enough in the ASP.NET Page handling process that would allow this. I know of no way to override or extend the parsing or processing of actual aspx/ascx code.
While ASP.NET is fairly flexible and lets your override many default behaviors (like how ViewState is saved/loaded, where Session is stored, etc) this is not one of them.
However... technically the Page object is just another HttpHandler. You could write your handler and do anything you wanted with it. All you have to do is implement everything the Page class does and then throw in this extra functionality. :) Alternately, pull out Reflector and dig through the Page object's ProcessRequest method and see where it is actually parsing/initializing the objects declared in aspx and you might get a clue how to implement the functionality you're looking for. But I suspect you'd be wasting your time.

Resources