I am trying to use jQuery and Asp.net Ajax library. The jQuery code is solid, I have it working on a separate page. When I incorporate the jQuery code into an existing page that using Asp.net Ajax, the jQuery code does not work.
I think this has something to do with name mangling.
How can I stop asp.net from name mangling or whatever else is going on?
If you're running into major naming issues then leverage QJuery's ability to use almost anything as a selector, including classes. Sure, class lookup isn't as fast as id lookup, but it is far less prone to being mangled by auto-generated code.
Here is a good article detailing How To Work With JQuery in ASP.NET.
Generally, the two frameworks do not interfere with each other. You can run into issues though, since asp.net ajax adds a hole bunch of extra functions to some of the base types like string, int or data.
But usually that is not a problem when only using jquery, but I have had issues with a few plugins that was not written probably, so that might be where your problem is.
With that said, it is hard to give you any concrete help without more information or/and code.
Maybe the two frameworks (jQuery and ASP.Net AJAX) collide in defining some operators like the $.
This old forum post is made by someone facing similar situation.
Related
Assuming I'm stuck with asp.net web forms (I'd love to use MVC partial views), are there any good alternatives to asp.net AJAX 4.0 client-side templates?
In other words, is there some way to specify some html, with placeholders for data properties, to which I could then bind a JSON result. Are there any good jQuery plugins to do this?
I ask because based on the results I'm seeing from Google, this library doesn't seem to be widely used—most search results are from 2008-2010. This question seems to confirm that suspicion.
EDIT
I despise answering my own question, but this link (jQuery Templates) seems to me to be the best bet. If anyone else has any input, please post.
Definitely consider jQuery Templates. We use them quite extensively in WebForms with ScriptServices as a data provider. There is a very small learning curve.
Also check out KnockoutJS, which integrates seamlessly.
Adam, coincidentally, I am using JQuery to retrieve some server side data calling Web Services via Ajax and binding the result on the client side. On my particular case, I am only showing data in a tabular manner, so I am using the jquery datatables plugin (which is fantastic, in my opinion; the API is well documented and easy to extend if you need to).
If you need to show data differently, I think you'll need to write quite a good amount of boilerplate javascript code.
EDIT: I just saw your link reagarding Jquery Templates and looks really cool. I didn't know it existed :) Thanks!
I am a quite new to web development and I am trying to do some small form updates without causing a postback. For example making a control visible when a drop down list is changed.
I have so far come across some features that achieve this like the RequiredFieldValidator inside an update panels. However, these are specific to a single task.
What are my options to achieve these client side updates in Visual Studio? At the moment I don't know any JavaScript, so I would prefer another solution if it exists.
If you don't know JQuery you should or at least any other Javascript library this will give you an edge and also pump up your resume. The learning curve of these JS frameworks is so short that you'll be creating awesome UI's in no time. I suggest that you take at least two hours to get to know JQuery you won't regret it.
Here's a few great article on using ASP.NET with JQuery:
http://dotnetslackers.com/articles/ajax/using-jquery-with-asp-net.aspx
http://www.dotnetspark.com/kb/1532-gridview-and-jquery-asp-net-tutorial.aspx
http://www.beansoftware.com/ASP.NET-Tutorials/Using-jQuery-ASP.NET.aspx
Here are a few of the best tutorials on JQuery:
http://www.ajaxline.com/best-jquery-tutorials-march-2010
For display functionality like you have described, javascript really is the best solution. Take a look at jQuery, it makes writing javascript a lot easier, and you should be up and running with it in no time for tasks like your basic show/hide functionality.
Unfortunately, AJAX stands for 'Asynchronous Javascript and XML' so getting this behaviour without using Javascript is going to land you in a bit of a pickle.
Update Panels do work and are very easy, but they're also very slow in comparison as even if you only see the contents of your panel update, the entire ASP page has to be executed.
I'd urge you to take a deep breath and head over to JQuery.Com and practise the tutorials there. Javascript is easier then you think and JQuery takes a lot of the hardships of cross-browser compatibility out of the picture, leaving you to focus on the real tasks.
Good Luck!
Not sure if this belongs in community wiki...
Can somebody give some general guidelines on how to successfully build an ASP.NET site that isn't dependent on JavaScript? My understanding is that I should build a functional site initially without JavaScript, and use it to enhance the user experience. That is easier said than done... how can I make sure my site works without JavaScript short of disabling JavaScript and trying it? Or is this something that comes with experience?
Try ASP.NET MVC! sure most of the examples use JavaScript for the AJAX functionality, but it's easy to build a fully functioning site that doesn't use JavaScript.
Since ASP.NET MVC doesn't use server controls with all their embedded JavaScript, it's a great way to build a site with very minimal and lightweight HTML, while still writting your data access and business logic in C#, VB.NET, or any other .NET language.
I've built working ASP.Net sites with little or no JavaScript, so it's definitely possible (just a royal pain.) The trick, and this sounds silly, is to use as few <ASP:> type tags as possible. Those all spawn various levels of JavaScript. Regular old-school HTML elements work just fine with no scripting.
So, on the extreme end, you write, say, your form using all plain-vanilla HTML elements, and then you have that form submit point at another page that accepts the form submit and hands it off to your server-side scripting.
To put it another way, pretend that all you get with ASP.NET is a snazzy server-side programming language and you're writing HTML in 1998.
Now, having done this, I can tell you that what this ends up as is a classic ASP webpage with cleaner programming syntax. ;) Most of the features that make ASP.NET "better" than classic ASP hang on JavaScript, so writing a JavaScript-free ASP.NET system is an exercise in shooting oneself in the foot repeatedly.
However, the one thing you should absolutely do is make sure the first page or two do work without JavaScript. Unlike 10 years ago you can safely assume that any browser hitting your page has JavaScript, and unlike about 8 years ago, your visitors probably don't have JavaScript turned off for speed reasons, but they very well might have something like the NoScript plugin for Firefox dialed all the way to 11. So, your first couple of pages need to work well enough to a) tell the new visitor that they need JavaScript, and b) still look and work good enough to make it look like adding your site to the white list is worth it. (In my experience, most people get the first one done, but in such as way as to totally drop the ball on the second. To put it another way - if your super fancy web 2.0 mega site starts looking like craigslist if noScript is fired up, I'm probably not going to bother letting you run scripts on my machine.)
If you want to use many of the ASP.NET controls (i.e. the DataGridView), ASP.NET pages are generated with lots of JavaScript in order to handle the events on the controls (i.e. selecting a row in the DataGridView). I think you're going to lose so much of ASP.NET that trying to have ASP.NET work without JavaScript enabled is impractical.
Disabling Javascript is the best way to test how a web site performs with out it. Good news, IE8's developer tools provide a quick and easy way to do just that. Now, having said that, often times the only thing that you can do is put up a message with a noscript tag to the effect that your site requires javascript for best function.
Many ASP.NET functionalities & controls won't work when JavaScript has been disabled. Think of LinkButton's onclick event which contains a call to a JavaScript function.
LinkButton is just an example. But there are many other things too.
If your concern is with JavaScript being disabled in user's browser then you can check for that and handle your site accordingly.
If you do decide to build the site without JavaScript then you will end up building a somewhat static web site. If your need is just to build a static website then you can go on with this approach.
Write everything with basic html forms and css, and then you will know that it works without javascript.
Once you are happy with it, then look at unobtrusive javascript, so you can modify the way the application works when javascript is enabled.
Last time I looked at some stats about this around 1% disable JavaScript, so why spend hours and hours on this when what you should do is show a message telling the user that your site requires javascript.
Use your time to be productive instead of trying to write around perceived limitations.
I’m new to .net, though I’ve been writing in classic asp for years. I know it’s time to make the change, but I can’t stand how bloated the HTML becomes.
For example, a simple menu using a web.sitemap and adds over 100 lines of JavaScript and HTML. A simple form with server-side validation adds in masses of ugly JavaScript. And a basic table of data using GridView adds in a ViewState that makes my eyes water.
Call me a purest, though I don’t like sending data to the browser unless it’s needed. And I don’t need a form-riddled menu when a simple unordered list of links will suffice.
So, set in my ways, am I destined to forgo the benefits of the Framework entirely by insisting on writing my own, cleaner code for everything? Or am I missing the point?
As a brief aside I’m a big fan of Campaign Monitor, a newsletter distribution company. They’ve written an elegant and comprehensive user-interface in .net without a single ViewState or bizarre .net-mangeled ID reference. Even the Sign Up form on their website (/signup.aspx) is as clean as a whistle. What’s their secret?
I hope I not the only one. Any advice would be greatly appreciated.
Try ASP.NET MVC or one of the other MVC web frameworks for .NET
If your GridView doesn't need it, then turn ViewState off for it.
Also, please edit your question to say what version of .NET you're using. Some of this gets better, and some does not. You might also want to try VS2010 beta 1, and complain about anything it doesn't fix.
Another idea would be to go on treating ASP.NET like it's classic ASP. Do it exactly the way you're used to, but do it with the idea in mind that there's about 10 years of development work that's gone into solving some of the problems of classic ASP. Once you actually hit one of those problems, find out if ASP.NET has solved it, and how.
For instance, I have a hard time believing you enjoy writing FOR loops to generate table rows. If you get tired of that, learn to use a Repeater control, or a DataList control, or even the old DataGrid control. If you turn ViewState off on those, I think you may find the generated HTML to be acceptable, and you'll find it a lot easier to generate tables and other structures that repeat based on repeating data.
You can opt-out of much of that bloat by not using all the out-of-the-box controls that come with it but I prefer the MVC route that activa suggested
Here is my list:
Keep the use of asp controls to minimum
Turn off Viewstate when it's not need
If you don't want the JavaScript associated with Client Side Validation (with ASP.NET Validation) set the EnableClientScript to False
Use asp:literal instead of asp:Label
Yeah it seems to be that everyone is bashing webforms at the minute for the reasons you have outlined above. HTML heavy Controls, ViewState, no control over ClientIDs all seem to cause an issue with people.
However let is be said that you can use asp.net (webforms) and produce some decent applications.
Control of html is yours through httpModules and httpHandlers and some of the issues mentioned above are fixed in asp.net 4.0
I just listened to a great podcast comparing MVC and webforms. Its in the area you are asking about. Also check out this blogpost by a dotNetNuke regarding the good asp.net code and why people should take a breath before converting everything to mvc.
Having said that I've tried Asp.net MVC and it is awesome. I'd probably look at dotNetNukes code to as its a mature asp.net product.
Also, when you do want to use these newfangled server controls, check out the css friendly control adapters. They clean up much of the bloat.
For client IDs the key thing to remember is to let the framework handle them. If you need to get an element on the client side, remember to emit the control's ClientID property into your script.
I've been using a template system and am very happy with it. Basically write an http handler for .html files and put tokens in the html files that regex could find in one sweep and inject any stuff. (google template c# for more info).
I tried some of the supposedly cool new features of ASP.NET for a little while. I also didn't like most of them. I felt constrained to work within the limitations of the common paradigms Microsoft had dreamed, even though I new how easy it would be to produce the HTML and JavaScript myself to do specifically what I wanted to do without having to learn how to jump through the hoops of so many new Microsoft-specific idiosyncrasies.
Anyway, I stopped using the parts of ASP.NET I didn't like on new code I've been writing lately. When I first started using ASP.NET, nothing in the MSDN documentation jumped out at me about how to avoid such complications, so I posted a couple "Hello, World" at http://www.agalltyr.com/rawaspdotnet.html to help spread the heretical word. I couldn't care less if it's the latest cool technology or the recommended technique. It's a reliable and reasonably efficient tool I can use to do my work.
Oh, and I'm not in the mood to learn ASP.NET MVC either. That's just more idiosyncrasies. Give me a language (C#) and a framework (.NET), and I'll design my own abstraction, thank you.
I have very basic knowledge of Javascript and now I am looking forward to learn Ext JS and implement in in my ASP.NET application.
If anyone can guide me on how to start and which book I should follow, I'd be thankful.
Nor sure if it is the quickest approach, but all I did (as well as another developer that was working with me) was review the ExtJS documentation and samples gallery (and viewing their source).
One big issue to watch out for when using ExtJS with ASP.NET is that when using BorderLayout you will go crazy trying to figure out why Postbacks no longer work. There is a workaround though.
Another ASP.NET gotcha is that if you use ExtJS to talk with ASP.NET web services (or WCF) you have to do some special things to get it to work (adorn your webmethod with special attributes, or add some things to web.config, etc).
Those were the only two gotchas I can recall, other than just learning and getting the hang of ExtJS itself.