I use the ASP.Net ScriptManager to load the scripts needed for calling WCF services via HTTP/JSON. I am optimizing the total size of my pages (including scripts) and I see that Microsoft's AJAX library is the biggest file that I have at 96KB. Is there anyway that I can get a version of this file with just the features I need loaded?
Or since I already have jquery, should I use that to call my WCF JSON service instead?
Cheers,
Jon
WCF JSON services degrade gracefully down to working as a standard webservice, so you should have no problems using jQuery to post and retrieve data from them. You may lose some of the integration bells and whistles, but as someone who has taken the path you're suggesting, I can say that I don't miss it at all.
The only problem might be if you're using advanced WCF feature like 2 way connections, or guaranteed connections.
Related
We have an application that uses webforms for some older web app pages, but also contains MVC functionality for some of the newer features. We have some new requirements for downloading files that will have to be processed on the server (not direct links to static files on the web server).
I haven't seen anything to indicate if there is a reason one should use an ASHX handler over just using an MVC controller and operating on the response object and returning EmptyResult() at the end of the action method.
Is there a best-practice for this with MVC? Should ASHX handlers be left for WebForms or is there some benefit they provide over using MVC for this type of file download feature?
The performance of HttpHandler is better since it is more bare-metal than MVC actions (just a few extra steps, but still).
Besides that, I see no reason why you should choose one over the other for performance reasons. MVC has some nice features you might want to use, like caching and authorization attributes.
If you choose to use MVC, use results that are specifically built for file handling, like FileStreamResult or FileContentResult.
Well, an ASHX can be a bit more contained and specific... however, there is something to be said about having all your code and logic in your main application.
There is no technical reason to do one over the other, to my knowledge with MVC nowadays. With WebForms it was harder to stream large files, but with MVC you can do that pretty easily (so you don't have to load the whole file into memory first). Also, given modern Async methods you don't have to worry so much about tying up worker threads and what not for scalability.
It's really up to you. Even if you wanted to separate it into its own module, nowadays it might make more sense to make it an owin module rather than an ashx. It's more about how you want to design your app.
I have seen that ASP .Net Code Behind files are really slow. I have used local web services which I call from jquery ajax function and they are fast. But I am still confused? Should i display dynamic data from code behind or web services?
I let my web service return a JSON Object and I assign relevant elements from that JSON object to different html elements like (image, div etc.)
You need to weigh several things..
If you are dealing with a low-traffic, internal web application, perhaps server-side postbacks are the way to go. Often you'll find that there's less code you'll have to write in this case.
If you are working on an external, public, high-traffic web application, perhaps AJAX is the way to go. That way you avoid posting back entire ViewState and running through the full page lifecycle. This may result in more front-end code, but is less load on the web server.
Keep in mind that client-side data binding is a very viable solution these days, with the help of such things as jQuery Templates. So that helps bind data returned from AJAX calls to tables and other elements.
As far as web services go, they are great for when you're sharing data/functionality between different systems. If you don't foresee doing that for this particular application, then perhaps there's no need to over-engineer it - keep it simple with either MVC and Action methods that support AJAX calls out of the box, or get familiar with PageMethods.
I'm sure there are other pros/cons I haven't mentioned, but this is the first thing that came to mind.
ASP.NET classic life cycle and postback is the base of Microsoft Click&Go philosophy. It is not designed to be fast even if it suits in most cases.
AJAX plus Web Services architecture is good way to improve server performances and dynamicity. It may not improve client performances, may increase the network load if bad designed and complicate a website architecture.
Another possible orientation is ASP.NET MVC, where old life cycle and postback is ancient history.
Like Kon said, mixity is probably the best way at the moment : MVC+AJAX or ASP.NET+AJAX where classic client<->server requests are used for common functionnalities and AJAX requests brings dynamicity with small requests for friendly functionnalities.
Note that most users on the planet are using Internet Explorer who have the worst javascript engine on the planet ;)
Does anyone know of a good article or tutorial on the Internet demonstrating the use of GWT leveraging a (ASP.NET) web service cross domain?
To my knowledge, interacting with either XML or JSON should be possible from GWT, but becomes a lot more difficult when the web service is on a different domain. I've tried finding an article that demonstrates this setup, but without any luck.
There are a few options available:
use the Cross Site linker - it should make cross domain request easier, simply add <set-linker name="xs"/> in your module file (*.gwt.xml)
window.name hack :) Be sure to read the post with the original dojo proposal
JSONP
many others ;)
But first I recommend reading http://code.google.com/webtoolkit/tutorials/1.6/Xsite.html - it should get you going :)
I was initially going for a JSONP approach (as suggested by Google), in order to do cross site AJAX calls in JavaScript, but ended up with too many hacks that I had to incorporate into the ASP.NET web service in order for it to work.
The solution, in my case, was instead to use GWT RPC to a JAVA servlet, acting as a proxy, which then would call the ASP.NET Web Service using SOAP. The SOAP Java classes was generated using the wslist tool that is part of JAX-WS project (as demonstrated here).
Using the GWT RPC, I was still able to call the JAVA servlet asynchronously, giving the user a seamless experience.
I'm planning a ASP.NET project for which I'm going to use AJAX. I'm researching all the available technologies for doing so in the .NET world.
I need a solution that is well documented and stable.
The current solutions I've found are:
1. ASP.NET AJAX UpdatePanel
2. ASP.NET AJAX with Web Services + JQuery
3. JQuery + Http Handlers
In the second and third solutions the backend would only send JSON or XML messages to the client.
In my experience the best way to go is JQuery with WCF with JSON webservices.
The reason is:
ASP.NET ajax is gives you alot for free in terms of coding but is bloated from the start and needs to be stipted and slimed. On the other hand you have JQuery that you needs more development but is light weight. JQuery has a great plugin library as well.
XML is to slow, JSON is fast.
Thats how I would do it today.
All will work but I've had most performance and stability with using JQuery and a script service.
An update panel will work but as its designed to work in the general case it can be a little bloated if you aren't careful. One reason being is that it posts the viewstate back with each update.
I recommend you check out the site: encosia.com as it has a number of posts on how to use script services and page methods. Then you can make a more informed decision. I would say that I've not used page methods and probably won't but that's entirely for personal reasons.
One other thing to consider will be any mvc you may end up doing. The general consensus is that it's a whole lot easier with JQuery. Added to that Microsoft have officially adopted it and also provide intellisense in VS2008.
All compelling reasons to include at least some of it in your project. In mine I only use the built in ScriptManager when I absolutely have to.
HTH!
S
Do you guys know about an ajax toolkit (or something similar to the m$-ajaxtoolkit) for mono??
Microsoft's ASP.NET AJAX Control Toolkit works on Mono, and is open source (Ms-PL). That doesn't preclude the use of jQuery, though. There are actually several third party AJAX libraries and control toolkits that support Mono, and many are compatible or work in conjunction with ASP.NET AJAX.
I agree with Brian, but want to add that you should read Dave Ward's series on jQuery and ASP.net. He really distills the essence of what you can do with jQuery, PageMethods, and WebForms without MS Ajax. These ideas are directly applicable to the Mono / Linux environment.
Here's a list of essential posts:
Using jQuery to directly call ASP.Net Ajax PageMethods
Use FireBug To Learn jQuery
Simplify calling ASP.NET Services with jQuery
I'd recommend rolling your own using jQuery. That's what m$ is doing now anyway.
Debugging Mono website
Do you remember, that you have no development environment in this machine? You can install it, or download Mono liveCD with openSuse. But before doing it, please note, that GTK# (it’s devenv) is not very user friendly. It even worse, then Eclipse. So let’s try to understand first whether we can fix small compatibility problems without entering code.
The most convenient method to debug web site on Mono is by using XSP and XSP2 mini web servers. Just enter the directory of the site and run it. By default you’ll be able to access the site by using ... (it also be written for you). Enter and notice whether you have any errors in console. No? Keep doing
The most common problem is “error 500” with nonsense stack. If it contains ScriptManager error Type not found, the problem is in Web.config file. Try to regenerate it to be compatible to Mono (for example, Mono has different version of System.Web.Extensions assembly. In ASP.NET 3.5 it has version 3.5, Mono has only 1.0.61025.0 (the old AJAX.NET). To recreate your web.config all you have to do is to execute “mconfig af AJAX Web.config” It will create default web.config file, supports System.Web.Extensions (AJAX features).
Not helped? Keep doing. Let’s look another time into the stack – if it contains errors in “EnablePageMethods” or “ShouldGenerateScript” or “EncryptString” – the problem is serialization. Mono has very limited support for JSON, XML and SOAP serialization. Try to look into your code and notice if you have classes, marked with [Serializable] or you are transferring your own classes by using PageMethods. If so, replace it with regular strings (my grandma serialization).