Using .aspx pages as HTML template outside of ASP.NET 3.5 HTTP request
I need to generate an HTML block for use by an asynchronous operation triggered by an HTTP request (I am calling the Facebook API in response to an HTTP request with an HTML block as a parameter). I already have an .aspx page that generates the required HTML and wants to reuse this code.
I see three options, none of which I want to do:
- Rewrite the functionality currently in the .aspx page into a .NET function that returns HTML. I don't want to waste time re-recording if absolutely necessary. Also, the .NET code for generating HTML will be much less convenient than the .aspx markup to do this (yes, even with XML literals).
-
When I need an HTML block, make an HTTP request to the .aspx page on the local server. The inefficiency of this does not concern me, but a constructive trade-off. Due to the way the application is structured, I would have to put my .aspx code:
if (localRequest)
{DoOneThing ();}
rest
{doTheOtherThing ();}which I don't want to do.
-
Create an ASP.NET application host to spit out these chunks of HTML. I would guess it would improve efficiency 2, but not complexity.
Are there other alternatives? The ideal would be to instantiate the .aspx class and execute it using HttpRequest or HttpContext. Can this be done and is it worth the hassle?
source to share
There are two related but different parts to this problem:
a) how do you ensure that the asynchronous operation has a valid HttpContext?
b) how can you get HTML output from ASPX execution as a string?
For (a) it depends on how you are calling the async operation. Unfortunately, there are several ways to do asynchronous operations in .NET . But if you want to extend HttpContext to asynchronous code, there is only one good option: the Event-based Asynchronous Pattern . While IMHO the event-based async pattern has some drawbacks (e.g. no "pending" operations, difficult to synchronize multiple threads, you need to refactor your code, etc.), it's really great to integrate purely with ASP.NET asynchronous pages and ensuring that the correct context is set up when your callback takes control.
In other words, the propagating context works (without doing a lot of extra work, that is) if you play by the rules set up for ASP.NET Async Pages. You can read the Asynchronous Pages article here if you're not familiar. Here's another post that is helpful. In a nutshell, you break paging down into three steps: 1) for long running operations 2) start long running operations (for example, to get your expensive data) 3) ASP.NET will call the Page_PreRenderComplete handler after all long running operations have finished. from here you can bind your data and render your HTML.
What can get complicated is that you will often have to rearrange existing code as you need to decouple data fetching from data binding.
Now, on (b) above: once you have the context, another question is how to get your page's output to string. There are several ways to do this too, but perhaps the easiest is to encapsulate the stuff you want to output into a custom control (.ASCX) and then follow the instructions in this blog post: http://stevesmithblog.com/blog/ render-control-as-string / . See this post if you need data binding.
source to share