In previous posts, I’ve covered the core architecture of jQuery. How it works. How you call methods. A brief overview of what’s available.
From here on out, we will focus more on specific solutions that jQuery can provide. One of those is the ability to load partial content from the server and display it back in a section of our web page.
I received the following question recently about my article “ASP.NET AJAX using JSON - Here’s how.“
If we update the value of a textbox or label via a JSON web service call - will the value of that textbox/label be written to the viewstate or whatever so that the server side code can see the new values that came from the JSON request?
When you need to deal with a number that is a fraction, what do you specify for its type? If you are like most programmers I know, you’ll reach for Float (Single if you are using VB) or Double.
If you are working with currency, though, this could get you into a lot of trouble.
Here’s why.
It seems like such a trivial thing to be talking about but not knowing the difference between && vs & or || vs | can make a huge difference between working code and code that only seems to work. Let me illustrate:
Over the weekend I got a question about how to prevent postbacks on buttons from within jQuery tabs. But the question really isn’t specific to jQuery. There are other times when you might not want a button to post back. So how do you do this? There are several ways you might accomplish this depending on what your goal is. The first, and most obvious choice, is to not use an ASP:Button control and use an HTML input type=”button” tag instead. This will allow you to have full control over what is happening on the client side. If at all possible, this should be your first choice.
Jeff Atwood of Coding Horror writes:
“I find it difficult to believe, but the reports keep pouring in via Twitter and email: **many candidates who show up for programming job interviews can’t program. At all.**”
One of the things to keep in mind when using jQuery is that nothing is a blocking call. Sure, there is a certain sequence to when things operate. But, to be safe, you should always assume that step two will happen during step one.
Nowhere is this more evident than when retrieving content from a URL and inserting that content in your page.
The temptation is to write code that looks something like this:
There are several controls that allow you to display content based on the role a user is in, including:
And the web.config file allows us to control which pages can be viewed based on which role a user is in.
But what if you need to determine the role a user is in using the APIs? How do you do that?
Since .NET first became available, passing data around during a request has become a lot easier. The ability to set a property has made that so. Still, there are times when setting a property just won’t do the trick.
I’ve had several occasions in the past where I’ve needed to do my own authentication or I’ve needed to add some additional methods to the authentication process.
As easy as Microsoft has made the authentication process, you might think that in order to manually authenticate you’d need to write all of your authentication code manually. But nothing could be farther from the truth.