I've been looking at the jQuery code but is kinda huge. Would this be an easy task? Any idea how to do it?
The reason I want to do this is because I want to use it not for a web page but for a C# application that needs to know when there is ajax activity going on in a WebBrowser. So I would inject my javascript code in any web page I want to detect ajax activity, instead of injecting the whole jQuery which might be already present and cause a conflict.
jQuery's ajaxStart doesn't fire for arbitrary XMLHttpRequest events, only for those coming from within jQuery.
You can trivially test* this by spinning up your own XMLHttpRequest after registering an ajaxStart handler.
So, technically, its easy to emulate: just route all your ajax traffic through a common method.
I doubt that's going to help you much since you won't actually capture all ajax requests, just the ones you kick off (and thus already know about, by definition).
*I did, since I wasn't sure.
Related
on one of the project I was delegated to I saw some c# code like this
string.format("some JavaScript function(){{ {0}.setValue and do magic",param1,param2,...");
Then the function was set as index changed method of some JavaScript element.
It's not the first time I saw it but its the first time it struck me so hard. The actual code was enormous and there was large number of parameters passed.
I was wondering if there is a better way (Probably plenty?) cause this seemed for me like a poor one. Writing complex javascript logic can be painful and writing it using string.format is semi insane for me. Can some 1 explain to me what are the alternatives and best practices are?
Thanks for help.
Regards.
If you have not some really need of generating conditional javascript code for the client, bacause that is what the presented code is doing, I would strongly advice to keep JS on client, and deliver it to the client via different standard mechanisms available in browser.
In short
use client side JS delivered via JS files or like a text and after treated like JS, but this is often for advanced scenarious.
use any MVC framework on client side, to avoid continue callback to the server, if you don't really need it, and manage states and appearance of content on your site in easier way.
a) knockout
b) angular.js
... many others...
Let's say you have an ASP.NET MVC 4 Web API project. One of your resources, when you call it by URL, waits while it gets performance monitoring data for a specified amount of time and then returns it all in JSON form once it has completed. However, between entering the URL and when the process has completed, is there a way to return data dynamically, ie. at each second when performance data is retrieved and display it in the browser.
Here's the issue:
Calling an API resource via URL is static as far as I know and as far as anyone seems to know. Meaning, the JSON won't appear until the resource has retrieved all of its information, which is not what I want. I want to be able to constantly update the JSON in the browser WHILE the API resource is retrieving data.
Since I'm working in a repository class and a controller class, Javascript is not an option. I've tried using SignalR, but apparently that does not work in this scenario, especially since I'm not able to use Javascript.
Is there any possible way to get real-time data with a URL call to the API?
Case in point:
Google Maps.
The only way you can call the Google Maps API via URL is if you want a "static" map, that displays a single image of a specific location. No interaction of any kind. If you want a dynamic, "real time" map, you need to build a web application and consume the API resource in your application with Javascript in a view page. There is no way to call it via URL.
You can put together an old-school ASP.Net IHttpHandler implementation regardless of MVC controllers and routing pipeleline. http://support.microsoft.com/kb/308001. You would then have full acesss to the response stream and you could buffer or not as you see fit. You've got to consider though whether you want to tie up worker thread for that long and if you're planning on streaming more or less continuously then you definately want to use IAsyncHttpHandler while you await further responses from your repo.
Having said that, Web API supports Async too but it's a little more sophisticated. If you plan on sending back data as-and-when, then I'd strongly recommend you take another look at SignalR which does all this out of the box if you are planning on having some JavaScript client side eventually. It's much, much easier.
If you really want to write Async stuff in Web API though, here's a couple of resources that may help you;
http://blogs.msdn.com/b/henrikn/archive/2012/02/24/async-actions-in-asp-net-web-api.aspx
And this one looks like exactly what you need;
http://blogs.msdn.com/b/henrikn/archive/2012/04/23/using-cookies-with-asp-net-web-api.aspx
In order to use that PushStreamContent() class in the example though, you'll not find that in your System.Net.Http.dll, you'll need to go get that from the Web API stack nightly builds at http://aspnetwebstack.codeplex.com/SourceControl/list/changesets
YMMV - good luck!
I think what you're asking for is a sort of streaming mechanism over HTTP. Of course doing that would require sending a response of unknown content length.
This question deals with that sort of chunked transfer encoding which is probably part of the solution. Not knowing what is on the client side, I can't say how it would deal with the JSON you want to push through.
Great question.
You can certainly start streaming the response back to the browser as soon as you want. It's normally buffered, but it doesn't have to be. I've used this trick in the past. In fact SignalR does something similar in some operational modes, although I should add (now I've re-read your question) that although HTTP supports this, it won't be obvious by default from a Web API controller. I think you'll need to get a little lower into the response handling so you can flush the buffer than simply returning a POCO from your web method if that's what you mean.
Essentially, you'll be wanting to write and flush the buffer after you've gathered each piece of information, so I don't think you'll be able to do that with the typical model. I think you'll need a custom message handler http://www.asp.net/web-api/overview/working-with-http/http-message-handlers to get at the payload in order to do that.
I'm curious though, you say you want to send back JSON but you're not allowed JavaScript?
Been looking around for the last few days trying to figure out what the best route is. I am fairly new to ASP.Net so I am in need of a little assistance.
I like the idea of using Master Pages as it will make making changes to the template a lot easier! But I am running into some problems. I will just list them below and see where we can go, maybe this will help some other newbies like myself.
Dynamic Menu:
I am trying to create a menu system that will show certain links depending on the users role. This is simple enough until I just want the link to perform some functions and thats it. So I dont want it to postback or anything. So my next step was to try to use jQuery as I would with my php development. Problem is I cant seem to get my jQUery to call the master page code behind function. I've gone through all the tutorials I could find with WebMethods but just keep getting an error to the like of This type of page is not served.
General Classes:
In PHP sometimes I would have the need to just have some General classes that pertained to a specific area of the application. I would just use these to hold all the function I may need to call from jQuery. Is there something like that in ASP.Net? I tried just adding a class but again couldn't call it from jQuery. Is this something Web Services would be good at? I am still trying to understand their full use. Seems like we could use Web Services as a buffer between the client and the back end classes.
I look forward to any pointers or tips!
Oded and jrummell made it very clear I should probably start with ASP.NET MVC first. It will most likely be an easier road for me moving from php.
I come from a ASP.Net background and taking baby steps in open source world. I have an image based application and for every image click I want to log data on server. I'm using Django/Python to host this application.
My understanding is that I need to process this data on client side and send to server using Ajax calls. Please correct me if I'm wrong. In ASP.net world, we had "runat=server" tag for every HTML control that made logging data on server really easy. Is there something similar in Django/Python?
Also, what is the most efficient way of logging image data in this situation?
Thanks in advance. Your help is highly appreciated.
Cheers!!
Your understanding of needing to use AJAX calls is one correct answer.
You could also register onclick JavaScript events for all images and have the JavaScript call a function that submits a form with the needed values for the view to process. That's sort of how ASP.net's PostBack works. The only difference is you're writing the client-side code yourself and nothing is obfuscated with the __VIEWSTATE hidden field.
Basically, ASP.net and Django come from two very different schools of thought. ASP.net's runat=server stuff makes things accessible to the various Page Lifecycle Events (Init, PreLoad, Render, etc) using helpful nuggets from __VIEWSTATE.
Django has no such Page Lifecycle model. It keeps things much simpler: a request is directed to a view method (or class-based view) using urls.py. The view method then returns a response.
There are benefits and drawbacks to both ways of doing things.
The short answer is that different frameworks tend to solve the same problem in different ways.
Recently I posted a answer to a question that I thought was quite an easy one, The question was about issues with the lifecyle of the page in asp.net where items would only reflect the changes made after the first postback, so I suggested using
Response.Redirect(Request.RawUrl)
And almost instantly got voted down for this as (Why cause another round trip)
Well I want your suggestion, is this type of thing good practise, simply practical or should never be used, please back up your answer with a little motivation its something I do from time to time and now question if I should rethink it.
This is the original post
Dynamically Change User Control in ASP.Net
There is nothing inherently wrong with Reponse.Redirect, just in most cases it isn't required in that kind of situation. You can change the way the page is constructed by working with the lifecycle rather than against it. Then there shouldbe no need for another postback.
The ASP.Net page lifecycle provides plenty of opportunities to step in and set things up, so I don't see that it would be necessary to use Response.Redirect to make the client load the page twice.
As an aside, using Response.Redirect with just the one argument can throw a ThreadAbortException, so it's often best to use the overload Response.Redirect(string url, bool endResponse) with the second argument set to false. This definitely applies to ASP.Net 1.0 and 1.1 (see here), not sure about 2.0.
Another solution would be to use an UpdatePanel with an AutoPostBack DropDownList to switch the user controls, then that is only responsible for switching the user control, and when the main submit button (or other event) posts back the whole form, you can process all of the data.
UpdatePanels do update the local page ViewState, if you do it correctly.
It seems like programming by coincidence, but much of ASP.net is that.