We Keep Coding

Non-MVC alternatives to ajax for passing data to usercontrols

I'm in a huge bind.
Long story short, I am working on a big project and am learning ASP.NET, C#, everything as I go.
The elementals of my project are comprised of user controls. My line of thinking was that I could create many user controls, each performing a function for a "component" of the project I'm building. Up until now I have been using clientside scripting to postback ajax calls to the code-behind on each of my user controls. AJAX worked well because it allowed to me pass data(that I need from the client) to my user controls and then I could return something in order to do an action.
I have been using a method for generating querystrings to create a callback "action" in order to determine what method needs to handle what data when the postback is sent to the code-behind side.
My problem now is that I need to start using many user controls one page -- and so now whenever ANY control does a postback ALL of the controls go through a page load. I thought my callback solution would take of this, but it isn't. Particularly when I drop a custom registered control into another user control.
I have done multitudes of research and having seen various ways to get around this, the best of them being [WebMethod] and controllers. However the project I am working on is NON-MVC.
I am also attempting to use UpdatePanel controls to minimize postback to the entire page but have had little success.
What can I use as alternatives? I feel like I'm running out of options or am missing something very basic here.
TL;DR -- I need a non-MVC method to pass data to user controls that can distinguish between multiple controls. Cannot use pagemethods(or page). Manual ajax calls are not working out. Cannot afford to do a full postback

Take a look at:
updatepanel vs page methods
Based on this:
My problem now is that I need to start using many user controls one page -- and so now whenever ANY control does a postback ALL of the controls go through a page load.
This might sound simple but have you tried to use if(!this.IsPostBack) in your load events?
Well not, the only way to avoid this situation, is using PageMethods or create a Script Service to handle AJAX requests (Web services with the ScriptService attribute or WCF REST services)
Note that even if you use the evil UpdatePanel, absolutely all the page life cycle will execute, which means that the whole page viewstate has to be sent in each post, the only advantage of using UpdatePanel controls is that you gain partial rendering, that's it, the performance on the server side doesn't change at all.
So you could use PageMethods or Script Services. But there's a catch, if you start using them you will notice an incredible performance change, your application will be more responsive (RIA applications), but the catch is that you won't be able to use the benefits of the ASP.Net server controls such as GridView, Repeater, etc. In other words you would need to change most of your view controls (this is the approach followed when working with MVC applications)

You can create static methods on your aspx page and mark it with [WebMethod]. Then you can call the method using jQuery ajax from the user user control markup. Take a look at this blog

Stop ASP.NET PostBacks Showing As Separate Pages?

I have an ASP.NET form that the user can make lots of changes to, each time they make a change the page PostsBack and the details are updated.
If the user hits the browser back button they go back through all the previous versions of the page.
Is it possible to stop each PostBack being treated by the browser as a new page?
So the would make any changes they like and if they hit the back button it brings them to the previous form and not the same form but a different version?
I know I could use AJAX to update values but I'm not an advanced coder so trying to keep things simple as I haven't used AJAX before.

Ajax is your only solution.
There is no way to remove a page from the browser history. Javascript is explicitly denied the capability.
Now, you could, potentially, stop them from using the back button at all. Although this might result in unhappy users and I'm not 100% certain it works in all browsers.
function body_onload(){
window.history.forward(1);
}

You could use a trick to do it.
On postback you can set a session bit to true saying they submitted that form. On your postback check to see if that value is set. If it is they are trying to do it again and you can just abort it. It wouldn't prevent the postback per se but you could control the logic and prevent it from DOING anything.
I personally would explore ajax as Jquery provides some nice ways to do it and it'd be a learning experience but I suppose this would work as you are asking. On a per session basis. If you only want 1 submission ever use a database to store the activity.

You could use UpdatePanel: http://msdn.microsoft.com/en-us/library/bb386454.aspx

What are the MUSTS for having an asp.Net application to support BACK button of the browser?

Is there any pattern or kind of "least requirements list" to follow for ensuring an asp.NET application to support BACK button of the browser for each aspx page?
thanks

In general, the back button on the browser will take you to the previous HTML GET or POST that occurred. It navigates by page-wide transactions, so anything done dynamically cannot be navigated that way. Also, the back button doesn't rewind code execution, so if you are determining something based off of a Session variable or something similar, that won't be rewound either. Obviously, it won't rewind database transactions either.
In general, if you want to support the back button, you'll need to make sure to divide everything you need to navigate between with said button is divided by an HTML transaction of some sort.
Again, you're going to run into issues if your page display is dependent on server-side control that changes from one post to the next. This is one reason you see some forms feed a 'Page has expired' error when you try to navigate back to them.

Not really... It depends on your application flow.
There are things that make supporting the back button more awkward.
for example using pure ajax to change the majority of the content on the page,
will look like a 'new' page but wont be compatible with the back button (though you can fudge it)
another example is posting back to the same page more than once, as this can make it appear like the back button is not working, and at the same time re-doing your request (and therefore database transactions)
Fundamentally it depends on your application requirements.

Form POST in ASP.NET

I'm trying to convert a classic ASP page to ASP.NET 3.5. The page has several forms on it for several different things.
In ASP.NET, there's a server form control wrapping the entire page, and form controls don't work within a server form control, and you can't have more than one server form control on a page.
So in order to keep this functionality, I can either:
Remove the server form control that's wrapping the page, and leaving the html forms on the page.
Create button click events for every form and perform the POST in the code-behind.
What's the preferred method here?

I wonder if converting to vanilla asp.net (aka webforms) is a bad idea here. Personally I'd go to MVC instead - allows multiple forms etc, and the views are much closer to he HTML, a lot like ASP.
I guess I'm saying there are some glitches vanilla asp.net introduces that you don't have to suffer.

I would go with the second option, any button click is going to post the whole page back anyway so you're not saving any bandwidth. Simply handle each button appropriately.

Check the answer I provided to a similar question here :-)
How to get past embedding a html form for paypal buttons asp.net
If you're going to use different button clicks, you still need to use this override to disable the non-related buttons in each handler, otherwise it won't work. You can only have one form tag at a time - this way you can toggle/disable the ones you're not using as appropriate.
Better still, refactor your application to use a single form. While MVC would be a closer match to the model you're using right now, it wouldn't make sense to go that route unless you were experienced enough with it; Web Forms is an easier jump.

jQuery within a Repeater

I'm very new to the world of jQuery and might be asking a fairly trivial question here. I'm curious as to what the community views as the best practice for a databound object with jQuery functionality.
As a specific example, I've currently created a repeater bound to a list of objects. Each object has properties such as "link", "thumbnail", "subtext", etc. This is a small repeater(<10 items at any time). When a user clicks on "link", a separate area of the page updates to reflect that object.
The approaches I've discovered so far involve:
Dynamically creating the necessary jQuery script from the C# codebehind
Creating a JSON service to respond to the link request and return the object to be loaded(an extra possibly unnecessary database hit)
To dynamically create a JS Struct within the C# codebehind (similar struct)
I guess the main reason I have for avoiding a JSON service in this scenario, is that the objects have already been bound once after being returned from the datasource. I'm not sure if another db hit is warranted, but I'm open to any and all suggestions.

Dynamically creating the necessary jQuery script from the C# codebehind might be unecessary as the JQuery code won't have to change. Bear in mind that unobtrusive JS is what jQuery is largely about.
I imagine the single piece of JS would look something like this:
$('.link-class', '#repeater-id').click(function(){
// Get the id of the link or the target using $(this).attr('id')
// Show a page section or call a service using the the discovered ID.
});
You can use the first comment to pull out the data you need to identify the data you wish to display.
The second comment can be either an Ajax call or a div toggle to some other section on your page. If this data is large then I'd be inclined to Ajax it. Otherwise I would keep it on the page and just toggle it on or off.
If you think users would be more inclined to click on several of the links then I would weight the non-ajax option a little more favourably even if the page was a little heavier. Especially if the user might return to a previously clicked link.
Does that make sense? Happy to elaborate further...

I assume this list has some basic details about some items and when you click on one you see some more data about that particular item.
I would definitely pick choices one (dynamic jQuery) or two (JSON service) depending on the size difference of the rendered page. If we're talking a difference in the vicinity of 10kb I would go with dynamic jQuery and just have all the data ready to go. If it's significantly more than that use a JSON service.
There's nothing wrong with an extra DB request and the delays it implies when the user expects it. If someone clicks on a web page item they're going to be fine with any delay less than half a second and perhaps a little over a second if you're nice enough to just say "please wait" to signal that a noticeable delay is normal.