I am currently working on a project where I want to implement a bit of logic for each .aspx viewed.
My idea was to use an httphandler that will target *.aspx, and in the handler, I would do my bit of logic, such as printing out: This is the xth page you have visited in this session.
I am curious if there are any problems with my idea or is there a more proper solution I am not aware of.
Though I have tried implementing my solution, I run into an infinite loop. After I complete my logic with the handler, I redirect to the same page, but that of course calls the same handler. Is there a way to bypass the handler on the redirect or a specific way to execute the same page without accessing the handler.
Thanks for the help!
~
Are you using a master page? If so, you could simply increase the count of your session variable in the master page's load event and display or write to DB anytime thereafter.
I think possibly you mean an HttpModule - a handler is an endpoint, you wouldn't have much of a page to display as well.
I would have suggested you add such a counter to a root master page. Simple to implement, doesn't have pipeline complications, can encapsulate the output control a well as the logic behind it.
Your handler shouldn't redirect...
Create an HttpModule and put this in the request pipeline. That way your code will execute and add the info you want while letting the page itself execute as necessary.
Or you could just take Matt's idea and put this in the master page. You'll have more control over where your text goes that way AND it's way simpler to implement.
You should do this with an IHttpModule instead. Modules are executed once per request, and their purpose is to something that does not have to do with the rendering of a page, unlike a handler.
Related
I'm retro-fitting a .aspx page with AJAX functionality (using VB, not C#). The codebehind populates the page with data pulled from a web-service. The page has two panels that are populted (with different data, of course) in this way. On a full page refresh, one or both panels might need to be populated. But populating Panel 2 can take a long time, and I need to be able to update panel 1 without refreshing Panel 2. Hence the need for AJAX (right?)
The solution I've come up with still has the old .aspx page with .aspx.vb codebehind, but introduces a Generic Handler (.ashx) page into the mix. Those first two components do the work on the user's first visit or on a full page refresh, but when AJAX is invoked, the request is handled by the .ashx page.
First question: Is this sound architecture? I haven't found a situation online quite like mine. Originally, I wanted to make the .aspx page into the AJAX handler by having the codebehind implement IHttpRequest, and then providing "ProcessRequest" and "IsReusable" methods, but I found I couldn't separate a regular visit to the page from an AJAX request, so my AJAX handlers took over even on the first visit to the page. Second question: Am I right to think that this approach (making the .aspx page do double-duty as the AJAX handler) will never work? Is it impossible to tell whether we're getting a full-page request or a partial-page (AJAX) request?
If the architecture is good, then I need to dynamically generate a lot of HTML in the .ashx file, right? If that is right, should I send HTML back to the client, or should I encode it in some way? I've heard of JSON encryption, but haven't figured out how to use it yet. So, Third question: Is "context.Response.Write" the only pipeline for sending data back to the client? And, if so, should I send back HTML or some kind of JSON-encoded objects?
Thanks in advance.
It sounds as if the page requires some AJAX functionality added to the UI.
Suggest using an UpdatePanel for each web form element that needs to have AJAXy refresh
functionality. That'll save you from having to refactor a bunch of code, and introduce a whole lot of HTML creation on your .ashx.
It'll be more maintainable over the long run, and require a shorter development cycle.
As pointed out by others, UpdatePanel would be a easier way - but you need to use multiple update panels with UpdateMode property set as conditional. Then you can trigger the update-panel refresh using any button on the page (see AsyncPostBackTrigger) or even using java-script (see this & this). On the server side, you may decide what has triggered the partial post-back and act accordingly by bypassing certain code if not needed.
You can also go with your approach - trick here is to capture the page output using HttpServerUtility.Execute in your ashx and write it back into the response (see this article where this trick has been used to capture user control output). Only limitation with this approach is that you can only simulate GET requests to your page and so you may have to change your page to accept parameters via query string. Personally, I will suggest that you create a user control that accept parameters via method/properties and will generate necessary output and then use the control on your page and in ashx (by dynmaically loading it in a temperory page - see this article).
EDIT: I am using jquery to illustrate how to do it from grid-row-view.
$(document).ready(function() {
$("tr.ajax-grid-row").click(function() {
$("#hidden-field-id").val($(this).find(".row-id").val()); // fill hidden filed
$("#hidden-button-id").click(); // simulate button click
});
});
You can place above script in the head element in markup - it is assuming that you have decorated each grid-row-view with css class "ajax-grid-row" and each row will have hidden field decorated with css class "row-id" to store row identifier or the value that you want to pass to server for that row. You can also use cell (but then you need to use innerHTML to get the value per row). "hidden-field-id" and "hidden-button-id" are client ids for hidden field and submit button - you should use Control.ClientID to get actual control ids if those are server controls.
JSON is not for that purpose, it is to pass objects serialized with a nice light weight notation, is you need to stream dinamically generated html using ashx, response.Write is what you have. You may want to take a look at MVC
Or you could use jquery if it's just html, the simpliest would be the load function, or you can look into Ajax with jquery. Since the ashx can be served as any resource it can be used in the load function.
I agree with #p.campbell and #R0MANARMY here. UpdatePanel could be the easiest approach here.
But then like me, if you don't want to go the UpdatePanel route, I don't see anything wrong with your approach. However, generating the html dynamically (entirely) at the back end is not a route I'll personally prefer (for the maintainence reasons). I'd rather prefer implementing a solution that will keep the design separate from the data.
It is possible to have a control that would proxy requests to another domain/Web site, including postback?
In this control, you would specify the URL you wanted to execute, and whenever the control executed, it would make a GET request to this other URL, and render the HTML return. (This part is not hard.)
However, when the page is posting back, it would make a POST request, with all of its postback variables intact, to this other page.
I'm really looking for a blind proxy. Some control that will take the incoming request and throw it another URL, and render the results. The other page would really have no idea it wasn't interacting with a human.
I want to think I could develop this, but I can't be the first person who wants to do it, so there has to be some reason why Google isn't revealing the solution to me. I suspect I'm going to run into the same Big Problem that anyone else with this idea has run into.
I'm not exactly sure what the value of this is; which is probably why you haven't found a solution yet.
However, it seems to me that there are two possible solutions.
When the page is rendered have the control modify the form action to point elsewhere; or,
on post back, have the control execute a web request to the alternate URL with the post variables and decide what to do with the results at that time.
In this end, this never had much of a chance of working. I experimented with it for a while, but Postback requires intimate knowledge of the control tree, and there's no way that you're going to be able to apply a postback from the calling page to the other page and have it overlay correctly because the control trees between the two pages are totally different.
Now, if you wanted to write the backend app as a more traditional Web app (even something not in ASP.Net), it might work. During postback, you could iterate the Request.Form values and send them back, and just have your backend app prepared to accept those incoming values and deal with them, but this wouldn't be a traditional postback.
I'm looking for a way to intercept the ASP.NET processing pipeline in such a way to be able to register event handlers to all events on the Page class. The reason is, I need to maintain a session-bound instance of a component that needs to be notified of all important Page events, starting from OnPreInit.
There's an arbitrary number of Page descendants in the application, which are not under my control. Hence I cannot use an approach like using a single custom descendant, that would notify the session-bound component, as a base class for all pages in the web application.
I don't think creating a custom IHttpHandler or IHttpModule implementation would solve the problem. Also note I cannot create a custom HttpApplication descendant.
It isn't going to be an elegant process to do what you are looking at, especially if you need to handle multiple page events, but in theory it is fully possible from within the Global.asax to setup handlers that you need for each and every page.
The trick here is to add your code to the global.asax in the PreRequestHandlerExecute method, from here you can get access to the HttpApplication object, get access to the page from there, and then register your events. This process is necessary as a new page instance is created for every page that is processed.
Now, other options as you know are far more elegant, but this should get to where you need to be. One helpful tutorial I found although around Themeing shows you the whole process here.
EDIT:
After seeing your comment, yes, you can simply do what I'm stating above, in a custom HttpModule. The article I linked even shows you that process :)
Without knowing more about what you're trying to accomplish it really sounds like you do indeed want to create a http module or handler. You might want to take a look at this question
I have to integrate an existing, simple asp.net web forms app including postbacks etc. into another external site with a jQuery load() call., an app that was intended to be integrated through an iframe. I doubt that's possible without a rewrite of the app.
The app is a basic questionnaire that leads the user to a product suggestion at the end.
Does anyone have any pointers to how I could solve this? I guess I will probably have to rewrite the app with web services and dynamic calls to RenderUserControls, I will also need access to the page that calls the load() and write additional jQuery methods to handle the user input... I will probably have to remove all of asp.net's postback calls and rewrite the handling of the user input?
First of all you should note that the load() function, like all ajax, can only work on the same domain. So if the 'external site' is on another domain ajax is the wrong choice.
It does sounds like a lot of hard work, depending on the complexity of the page. Postbacks can occur in many places - image clicks, combo selects, etc. Also, there are hidden fields to worry about, like the View State and Event handler - those have the same names on both pages. You'll have an easier time if the external site has no state and postbacks.
If the pages are relatively simple this can probably be done. It's been my experience that forms don't work well in other forms, so you'll have to remove one of them (probably the loaded page's form), or place them one after the other. As you've mentioned, you'll have to rewrite postbacks, you'll want to serialize the data. You may be able to change this string to fit the names on the original page (if you've changed the name of the viewstate, etc, it's easier to change it back on the serialized string than to mess with IDs), post it to the original page, and load again.
Personally, as much as I like jQuery, and as much as this project sounds interesting (and it is), I'd probably go for a server-side solution. It sounds much easier to create a user control (that may use ajax itself), or to the expose the page's functionality using web services or better, generic handlers.
How can you make the ASP.net Session Data available to a JavaScript method? I found this link when I googled. Anyone has a better trick that does not use the ScriptManager?
If ditching the ScriptManager is your aim, exposing the page method is still a good option, just use javascript that doesn't rely on the ScriptManager js libraries.
I like the solution proposed in the linked page, but it might be a too wide open though. Maybe you want to create a strongly typed and controlled PageMethod for any/all Session items that you want to allow access to. That way you can't access some secret Session value accidentally.
Also, I think you need to tag the PageMethod with
VB
WebMethod(EnableSession:=True)
C#
WebMethod(true)
as I don't think EnableSession is on by default.
The purpose of session is to hide details from the client. Sounds to me like you should convert it over to using cookies which is obviously trivial to retrieve via javascript.
You have to put it into the page somehow. Using hidden form fields is one approach. Using webmethods like your link is a more sophisticated approach which gives you some ajax-powers.
If you don't actually need this value to update from the server except on post-back, you can just use the hidden input control HtmlInputHidden.
A regular AJAX call to a ASHX that implements IRequiresSessionState
Why on earth would you want to though?
Honestly, the ScriptManager method looks pretty easy. Rolling your own solution would require an HttpHandler on the server side and an Ajax call, which doesn't seem worth the trouble in this case.
There are two alternatives I can see:
Generate a JSON object of the Session data you want the JavaScript to have access to. Send this to the browser either during the initial page generation or as a result of a JSON Callback.
Create an ASPX page you can call via AJAX which would return the value of a session variable with a given key.
#2 is probably what the ScripManager code is wrapping around, and you should probably just use that anyway. But I would be careful about deciding what session data you want to go to the client, and I'd use a Whitelist to only return the Session data I actually need to go down to the client.