I have for example ASP.NET site with textbox, button and many other controls.
When user click on button i want to retrieve some data(string,number) from DB(MSSQLServer) and show these data to user without postback(ajax).
How can i do this?
Thanks
There are two key components. A server-side method that can respond to a request for data and a client-side javascript function that can make an AJAX request to that method and consume the data, updating the web page.
On the server side you can use an actual web service or web application methods marked with the WebMethod attribute. These accept a request and respond, not with a web page, but usually a partial HTML snippet, XML, or JSON.
On the client side, I would look at using a framework that implements AJAX -- such as MicrosoftAjax or jQuery, though there are many others. It would be then be a matter of correctly configuring the client function to respond to the interaction trigger (button click) so that it calls the proper method with the right parameters and processes the response.
Partial Page Updates vai AJAX
Using Web Services via AJAX
jQuery -- many examples and documentation
Related
I am a beginner to .NET, I have some doubts in my mind. Can anybody help me to sort out?
When a user requests for a file(*.ASPX), The request first goes to IIS server and with the help of Handlers and modules it finds the type of file that need to be processed and sent back to the client. But while displaying on the cilent machine the content of the .ASPX file will be displayed as HTML controls. How are the events generated at the client side and sent back to the server?
I know runat=server tells the control will be processed at serverside.
But every time why we need to write "runat=server". Is there any ASP.NET control which runs at client side?
When you tell a "tag" to runat="server", you tell the server to register the tag. Now the tag is included in the control/tag tree on the server, and can be found ont the server: When an event is fired, or attributes or contents is changed server side.
Client side events, are silently converted to a form POST. Together with some extra information, like the ID of the control, and the type of event.
Since your tag is registered on the server, it has an ID, that is also transferred to the client (look at the html source). This tree is build, (by parsing the .aspx file) before the event is "fired". Using this id, you can find the tag in the server-side control/tag tree, and run the method that is used to handle the event.
Using these technique, and a lot of ViewState, Asp.Net tries to deny the stateless nature of HTTP. At first this looks like a good idea, IMHO its better not to fight with nature. Currently ASP.Net MVC feels more naturally.
if you are starting with .NET web development, ASP.NET MVC is the way to go IMO
an ASP.NET server control that is generating client events in the browser is exercising standard dom events via javascript code that gets injected into the page that is sent from the web server. try view page source from any browser to see what is actually generated and the picture will become more clear.
essentially runat=server is telling the ASP.NET parser to process the tag and generate some special HTML output for the page. see GvS's explanation in this thread of how client events for these controls are converted to a form POST that is handled on the server.
http://www.w3schools.com/aspnet/aspnet_intro.asp
How Does ASP.NET Work?
When a browser requests an HTML file, the server returns the file When
a browser requests an ASP.NET file, IIS passes the request to the
ASP.NET engine on the server The ASP.NET engine reads the file, line
by line, and executes the scripts in the file Finally, the ASP.NET
file is returned to the browser as plain HTML
also see
http://www.w3schools.com/aspnet/aspnet_controls.asp
http://www.w3schools.com/aspnet/aspnet_events.asp
These event just raised by server-side controllers ,when you click on a asp button , event information be captured on the client and an event message transmitted to the server, via an HTTP post.i think these possible by some registered event on the server.when you page is loading , some events registered on you page framework , and the raised by http post request.
Look, one of the difference between the client side and server side controls is the server side are registered in server and you can save their state in a view state for example. when you click on a server side button , first its client side event raised and the the server side .note that because the server side controls event registered on the server , when you click on the button ,you page posted back.but the client side controls just are valid in client , and their event just raised for you web browser
need more help ? comment me to edit my answer
regard , Ali
In my asp.net application I have a some client side scripting that alters the page events and do different things. One problem I am having is when I post back to the server after all of the validation is done on the client side, I have a couple more validation checks on the server side (c#), and I want to show the proper error, but the page refreshes. I just would like to do some server side coding and if i need to go back to the page, go there as lasted viewed, with the error in the label, and changes i made on server side. Thanks for any help.
I think you must post it in ajaxy fashion.
I mean use ajax to post..
Evaluate the results on client side using JS.
Then if everything is fine do a redirect.
if errors exist you are still on that and can modify the html .
Do your server side validations in an AJAX call instead of a normal page post back. Because, you are making a background server call, your page does not refresh and on validation failure, you can retain the browser side UI. If validation is successful then you can do your regular post-back for actual processing.
From implementation perspective, you can use Page Methods (or JSON WCF services) in ASP.NET AJAX for the same: see this tutorial to get started with Page Methods: http://www.singingeels.com/Articles/Using_Page_Methods_in_ASPNET_AJAX.aspx
When we write our own custom HTTPHandlers aren't they behave the same way as ICallBackEventHanlder does? we use both to make ajax calls from our web page, isn't this correct? or my understanding wrong, I wont doubt if it is :(
Obviously HTTPHandlers are more broader concept since a web page (.aspx) etc are also http handlers.
A ICallBackEventHandler is for integration with a page -- a handler is for anything. A callback handler is useful when you want to do an ajax request from the client-side of a page, and from that handler you still want access to all of the controls on the page, their re-saturated state that comes from ViewState, etc. An http handler has no access to the page or its state. A callback handler can also push some state changes back to the client. For example, a callback handler might render something which requires the __EVENTVALIDATION field on the client-side to be updated.
I got to work on PHP app which requires a webservice call to an Asp.net webserivce. Client insist to call this webservice with POST directly via jquery.
My knowledge says its not possible to call different domain webservice from JS and I'll have to create a proxy page to consume this webservice.
So I just want to confirm, is there any hack around to consume webservice directly from jQuery POST call and parse response (Which is XML not JSON) on page.
Thanks
No there is no way around it x-browser. Server Proxy or json-p are your choices.
I've been using user controls extensively but never use a HttpHandler and was wondering if I am doing something suboptimal or wrong
Unfortunately your question is a little like "Should I use a sandwich or a cement mixer". HttpHandlers and User controls are completely different things.
HttpHandlers are used to process HTTP requests. For example, if you wanted to dynamically create an RSS feed, you could write an HTTP handler that handles all requests for ".rss" files, creates the output and sends it back to the user.
User controls are used within ASPX pages to encapsulate units of functionality that you want to re-use accross many pages.
Chances are, if you're using user controls successfully, you don't want to use HttpHandlers!
Basically a user control is a piece of server logic and UI. An HTTP Handler is only a piece of logic that is executed when a resource on your server is requested. For example you may decide to handle requests for images sent to your server through your own handler and serve images from a database instead of the file system. However, in this case there's no interface that the user sees and when he visits a URL on your server he would get the response you constructed in your own handler. Handlers are usually done for specific extensions and HTTP request types (POST, GET). Here's some more info on MSDN: http://msdn.microsoft.com/en-us/library/ms227675(VS.80).aspx
Expect a better answer (probably before I finish typing this) but as a quick summary.
A user control is something that can be added to a page.
A HttpHandler can be used instead of a page.
Just to clarify the question. I was reading the Hanselman post
http://www.hanselman.com/blog/CompositingTwoImagesIntoOneFromTheASPNETServerSide.aspx
and thinking that I would never solved the problem with a HttpHandler, maybe with a simple page returning a binary content.
This led me to think that I should add HttpHandler to my developer tool belt.
Even an Asp.Net page is an HttpHandler.
public class Page : TemplateControl, IHttpHandler
A user control actually resides within the asp.net aspx page.