We Keep Coding

General Q about using only [WebMethod] AJAX functions to handle requests.

I am working on redesigning and streamlining the checkout process for an Ecommerce website using ASP.NET/C# into 1 page. (Currently, the website doesn't use any ASP controls)
Just for a little back info, the customer will be able to enter a shipping address, add a gift message, and select a shipping date per recipient while updating the backend with the correct information. I want this process to be elegant and pain free for customers to use.
Now I have created WebMethods that get called through AJAX requests that work correctly on previous features.
My question is:
Would it be an ok idea to submit ALL these requests through WebMethod AJAX calls, have it update the backend, and render the correct information to the user?
I know it is doable but I just want to be sure that this is an ok approach to take. I have been looking at other JavaScript frame works that might help but am too unfamiliar with them to know if they would work or not.
Please let me know what you think and if you have other suggestions.
Thank you!

Short answer: Yes.
You mentioned:
an Ecommerce website using ASP.NET/C# into 1 page
If that is true, then you are talking about a single page web app. There are a couple of references to single page web apps here:
https://msdn.microsoft.com/en-us/magazine/dn463786.aspx
https://en.wikipedia.org/wiki/Single-page_application
It's very common to do what you are talking about. Using AJAX to perform back-end processes and then update small pieces of the front end is key to making fluid, fast, and responsive web applications. That's mainly because smaller pieces of data are being sent through the network, and the UI is being updated in smaller segments. If architected correctly, single page web apps can provide a slick, intuitive web experience for clients and customers. Emphasis on "If architected correctly". So make sure to do your research.
There are several libraries out there that can help you, such as:
jQuery
jQueryUI
Bootstrap
Angularjs
Sencha ExtJs
Backbone
Knockout
You don't have to use them, but they can save you a lot of time. At the very least, I would recommend using jQuery. Do some research and find out which one(s) will work best to fit your specific application.

I don't see any problem in this approach, the good part about ajax WebMethod is that you will transfer only the important data to do the operation. its better and fast than use a updatePanel
We use a lot of ajax webMethod in our asp.net project and we never got problems with it :)
A good advice is looking for asp.net mvc, its better than asp.net web forms

Code behind web methods vs. javascript? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
What are the pros/cons of using c# code behind instead of javascript to change contents of an asp.net/html page? Specifically, I was wondering which would be better if I get a JSON object from a different server through a button click and then have to fill in that JSON object's contents into a table and then sort that table.
Also, a user could request multiple objects which would mean appending multiple tables to the same page without reloading the page. Would code behind allow this or is javascript the better option here?

Pros for WebMethods/WebServices/WebAPIs in providing content for a web page:
You have more resources at your disposal for processing requests, for example, you can access data stored in the filesystem or in a DB, process it and return it in a variety of formats such as XLS, CSV, JSON, Images, Strings, Binary blobs, etc.
You can handle your application's security in a better way since the code is not exposed and is not editable, also diminishing the posibilities for glitches and bugs.
You can leverage larger computing power than you would have on the average computer that's sending the request
Cons for WebMethods/WebServices/WebApis:
The response time will always be higher since requests are sent through the network and all the possible roadblocks apply: latency, network traffic, packet loss, server load, etc.
Large workloads require more complex logic for requests processing and it will consume more resources, resulting in higher costs for maintaining the application
The technologies used will usually involve more complexity than using just client side technologies (C#, ASP.NET, MVC, SQL, WCF, etc vs JavaScript, HTML and CSS)
Pros for client-side technologies:
They are lightweight (relatively) and possibly easier to learn and use than server side technologies
The response time can be faster than sending requests to a server provided the operation can be performed without using resources located remotely (for example, creating a chart and saving it as an image does not necessarily require you to send data to the server)
Lots of platforms can be targeted since these technologies are supported by the majority of browsers
For your specific case, DOM manipulation is faster when done in the client side, AJAX is the evidence of how much people hated postbacks and roundtrips to the server for trivial things.
Cons for client-side technologies:
Trying to process some operations that are better suited for a server-side operation results in convoluted and sometimes unpractical solutions due to unavailability of things like access to the filesystem and other local machine resources (HTML5 helps a lot in this with the addition of Local Storage, Local DB and other resources for manipulating binary strings as data but the adoption levels for HTML5 browsers are still not where everyone want them). Specific example: I once had to create a dashboard using only jQuery, HTML and CSS due to unavailability of server side resources, i was also required to render these charts as images to allow saving, and then allow the dashboard values to be exported to Excel, all of this while supporting all browsers back to Internet Explorer 8. Needless to say, the solution was a mix of multiple scripts, plugins and use of dreadful things like ActiveX objects that ultimately get the job done, but complicate your life beyond necessity. (There is of course the issue of practicity overlooked during application design but i had no say in this)
The execution can be slower than a request sent to a server for complex calculations that will perform different depending on the underlying hardware and available resources
Your code is exposed and open for examination and can also be edited on the fly. Debugging client side code is also not a very pleasant experience, though progress keeps being done on this front every day.
At the end of the day, i think there are no best/worst technology, just tools better suited for a specific type of job. If you need to work with objects and data available from the client side, JS + HTML + CSS is the way to go, but if you need to persist and manipulate data stored outside of the client machine or perform complex calculations that require lots of processing power, then server side technologies are better suited for this task.

Ideally I prefer ASP.NET Web API , meaning get all the data from server through JSON over RESTful services , once you have your data , your JS/Jquery should manipulate your HTML or DOM . Both work inclusive rather than exclusive , for your data, security you have to rely on server . client side data shouldn't be heavy and should not disclose any PII. See JqueryGrid for dynamic table manipulations , there are many more client rich controls .

In a single sentence: ASP.NET code behind (C#) is a server-side technology, while javascript (or jQuery) is a client-side technology. The first one is much more robust and client platform-independent, while a second one provides much better responsiveness (no need for round trip to web-server). For any business-critical data operations (especially if security is a major concern) server-side technology (i.e. ASP.NET/C#) is a preferred one.
Regarding your second Q in comments: In case you need to persist any data you can use either ViewState ot SessionState objects (also, objects/methods in global.asax file).
Also, valuable addition to ASP.NET is AJAX technology (Microsoft VS implements so-called UpdatePanel control, which greatly simplifies the implementation of AJAX pertinent to ASP.NEt pages), which improves the responsiveness of ASP.NET web pages.
Rgds,

Proper way to use AJAX in ASP.NET Website

I am learning how to create a website using ASP.NET & C#. Right now I am learning making AJAX requests & outputting the response. I have lots of experience with websites & using python/php server side & javascript + html client side.
Whats the best practice method to perform AJAX requests in an ASP.NET website? Is it JQuery or C#/ASP.NET?
Is it better practice to use native C#/ASP.NET AJAX calls/code?
// I think its something like
<asp:AJAX ....>
Does it matter which method is used?
Are you able to give a simple example in ASP.NET of how to write an AJAX request/call? I know how to do it in JQuery & also native Javascript but not in ASP.NET.

Since you're asking this question, you probably realize that there are a few different ways of doing things. Unfortunately, with so many different options you have to actually make a choice, which can be difficult.
There is no 'proper' way to use AJAX with your ASP.net site, as they all have their pros and cons. It all about what will be the easiest for you (and any team members) to write, read, and maintain.
There are several controls built specifically to use AJAX (by using a ScriptManager control on the page that imports all kinds of useful JS). Things like the UpdatePanel can help make AJAX-y partial-postback things on a page really simple to write and maintain. There are also tons of other neat controls in the AJAX Control ToolKit that give you even more pre-built controls to use.
If you're looking for a more 'traditional' AJAX experience, you can make life easy by using PageMethods. You can also look into things like Web Services (kind of deprecated, but you'll still find them all over the place, and WCF services to make things as painless as possible. These can be called via your code-behind, asp, or jquery/js.
So, in short, just as with everything else in web development, there is no 'right way', just the right was for you.

In ASP.NET, AJAX is utilzed by UpdatePanel control.
See these resources:
http://www.asp.net/ajaxlibrary/act.ashx
http://www.asp.net/ajaxlibrary/act_tutorials.ashx

Does AJAX 2.0 + still send full postback on requests

This is a general question really. I had read some where, it may of been an Microsoft whitepaper or blog I am really not sure as I dont have the link right now.
Basically, the person was describing that (of which he referred to AJAX.Net 1.0) when using an update panel, although you would expect only the controls and components associated to be updated/refreshed, the entire page is submitted with the request in the update panel.
Obviously this defeats the purpose of AJAX when the design is to minimize traffic sent to and from the server. In this case you might as well do a full post back for the page. I guess from a cosmetic point of view, AJAX.Net does the trick as intended but behind the scenes doesn't do what you would expect.
Now this could well of been resolved in later versions I just can't confirm this. I have searched Google high and low for an answer.
What the person said was to use JQuery as this offers true optimized traffic flow when updating, which of course it does, so this is why I ask have Microsoft done the same with their later versions.
Just thought I'd ask you lot before attempting the impossible task of asking someone in Microsoft.
I'll have a look for the link when I get home and if I find it I'll add it here just so you don't think I'm off my rocker. :)

This post ASP.Net AJAX Not Working (Full page postback) explains pretty well about the problem and the solution.

Controls versus standard HTML

I'm getting into ASP.NET (C# - I know it doesn't matter for this particular question, but full disclosure and all that), and while I love that the asp:-style controls save me a lot of tedious HTML-crafting, I am often frustrated with certain behaviors. I encountered one last night when working with Master Pages: my <asp:BulletedList ID="nav">, when converted into HTML, became <ul id="ct100_nav">.
There are other issues--I noticed that when you auto-populate a DataGrid, it adds attributes to the resulting table that I don't necessarily want there.
I know that there is a certain amount of "convention over configuration" that you have to accept when you rely on a framework to take over some of your tedious duties, but the "conventions" in these cases aren't so much any established conventions, but rather unnecessary extras. I know why the ID adds the prefix, but I should be able to tweak and turn things like this off, especially since, as a bit of a web standards evangelist, I don't duplicated HTML id's in a single page anyway.
So the question here is for those ASP.NET devs more seasoned than I: in your experiences in developing and deploying apps, how do you leverage these controls? Do you find yourself resorting back to hard-coded HTML? Do you use a blend? I don't want to design my HTML around idiosyncratic quirks in these controls, but, if possible, I'd like to leverage them when possible.
What's a boy to do?

Personally,
I think the standard ASP.NET controls are fine for inhouse stuff - quick and dirty is good in that scenario. But, I once worked with a web developer who was also a designer and he refused to use the ASP.NET controls and only code in HTML and add runat="server" tags when needed. This was more because he wanted to know exactly how his HTML was going to be rendered, and at the time anyway, some of the ASP.NET controls wouldn't render to standards compliance.
I sit somewhere in the middle - use HTML where appropriate and not when not. You can sort of best of both worlds with the CSS control Adapters

I'm actually quite relieved to see some opinions here agreeing with my own: ASP.NET as a template language is very poor.
I'd just like to rebut a couple of the pro points made here (flamesuit on!):
Dave Ward mentions ID collisions - this is true, but my how badly handled. I would have preferred to see nodes referenced by xpath or deep css selectors than by making the ID effectively useless except by deferring to ASP.NET internals like clientID - it just makes writing CSS and JS that much harder pointlessly.
Rob Cooper talks about how the controls are a replacement for HTML so it's all fine (paraphrasing, forgive me Rob) - well it's not fine, because they took an existing and well understood language and said "no, you have to do things our way now", and their way is very poorly implemented. e.g. asp:panel renders a table in one browser and a div in another! Without documentation or execution, the markup for a login control (and many others) isn't predictable. How are you going to get a designer to write CSS against that?
Espo writes about how controls give you the benefits of abstraction if the platform changes the html - well this is clearly circular (It's only changing because the platform is changing, and wouldn't need to if I just had my own HTML there instead) and actually creates a problem. If the control is going to change with updates again how is my CSS supposed to cope with that?
Apologists will say "yes but you can change this in the config" or talk about overriding controls and custom controls. Well why should I have to? The css friendly controls package meant to fix some of these problems is anything but with it's unsemantic markup and it doesn't address the ID issue.
It's impossible to implement MVC (the abstract concept, not the 3.5 implementation) out of the box with webform apps becuase these controls so tightly bind the view and control. There's a barrier of entry for the traditional web designer now because he has to get involved with server side code to implement what used to be the separate domains of CSS and JS. I sympathise with these people.
I do strongly agree with Kiwi's point that controls allow for some very rapid development for apps of a certain profile, and I accept that for whatever reason some programmers find HTML unpleasant, and further that the advantages the other parts of ASP.NET give you, which requires these controls, may be worth the price.
However, I resent the loss of control, I feel the model of dealing with things like classes, styles and scripting on the codebehind is a wrongheaded step backwards, and I further feel that there are better models for templating (implementation of microformats and xslt for this platform) although replacing controls with these is non-trivial.
I think ASP.NET could learn a lot from related tech in LAMP and rails world, until then I hope to work with 3.5 MVC where I can.
(sorry that was so long </rant>)

The short answer is that you should never use an asp:... version of a standard HTML control unless you have a really good reason.
Junior developers often get suckered into using those controls because they're covered in most ASP.NET books, so it's assumed that they must be better. They're not. At this point, after 8 years of daily ASP.NET development, I can only think of 2 or 3 cases where it actually makes sense to use an asp:... INPUT control over a standard HTML one.

As for the ID's on server-controls: You can find the actually ID that is going to be written to the browser by accessing ClientID. That way you can combine server-side og client-side scripting and still dont have to hardcode _id="ct100_nav"_
I always try to use the included controls instead of "hacking" HTML, because if there is an update or some improvement later on, all my code will still work by just replacing the framework and I don't have to change any HTML.
Hope this helps

#Brian,
Yup! You can pretty much control all the behaviour.. Consider looking into creating Custom Controls (there are three types). I recently gave an overview of them in my question here.
I would strongly recommend checking them out, has help me no end :)

I too am on my adventure into ASP.NET and have also had similar frustrations.. However, you soon get used to it. You just need to remember, the reason you dont have the tedious HTML crafting is because the ASP.NET controls do it all for you.
To some extent you can control/tweak these things, even if it means inheriting the control and tweaking the HTML output from there.
I have had to do that in the past, where certain controls were not passing W3C validation by default by putting some extra markup here and there, so I simply overrode and edited as necessary (a fix that too literally a couple of minutes)..
I would say learn about how the controls system works.. Then knock a few together yourself, this has really helped me grok whats going on under the hood, so if I ever get any problems, I have an idea where to go.

The HTML renders with those sort of IDs because its ASP.NET's way of preventing ID collisions. Each container control, such as a Master page or Wizard control, will prepend an "ID_" on its childrens' IDs.
In the case of your bullet list, the ListView provides a nice middle ground. You can still bind it to a datasource, but it gives you much tighter control over the rendered HTML. Scott Gu has a nice intro to the ListView here:
http://weblogs.asp.net/scottgu/archive/2007/08/10/the-asp-listview-control-part-1-building-a-product-listing-page-with-clean-css-ui.aspx

If the ID's prefix added by ASP.NET is an issue for you to access them later using JS or something... you have the .ClientID property server side.
If the overhead added by ASP.NET you should consider ASP.NET MVC (still preview) where you have full control over the emitted html.
I'm moving to MVC because I don't like all that stuffs added too....

I think most of the answers here take a designer's point of view. On a small-to-medium project it might seem like an overhead to synchronize code and CSS/HTML and make them standards-compliant and clean. A designer's way to do that is to have full control over rendered HTML. But there's many ways to have that full control in ASP.NET. And for me, having the required HTML in the aspx/ascx file is the most non-scalable and dirty way to do it. If you want to style controls through CSS, you can always set a class server-side through the CssClass property. If you want to access them through JS, you can emit the JS with right IDs server-side again. The only disadvantage that this provides is that a dev and a designer have to work together closely. On any large project this is unavoidable anyway. But the advantages ASP.NET provides far outnumber these difficulties.
Still, if you want standards-compliant HTML, skinning support and other goodies to control rendered markup, you can always use thrid-party controls.

As Dave Ward has already mentioned, "it's ASP.NET's way of preventing ID collisions."
A very good example of this is if you're attempting to put a control inside of a custom control, then use that custom control in a repeater, so that custom control's HTML would be output multiple times for the page.
As others have mentioned, if you need to access the controls for javascript, use the ClientScript property which will give you access to a ClientScriptManager and register your scripts to the page this way. Be sure when writing your scripts to use the ClientID property on the control you're trying to reference instead of just typing in the control's ID.

If you want that much control over the rendered HTML, look into ASP.NET MVC instead.