In asp.net web applications, it is common to have dozens — if not hundreds — of user controls that perform postbacks to the server, actions initiated by a user such as a button click. Often before a save, delete, or other critical action is performed, it is desirable to ask the user if they are sure.
In Asp.net web applications, buttons and other controls have two event properties that we are concerned with:
onClick , and
An asp.net button
onClick event calls a specified function in the code-behind file. At this point, the postback has occurred, and any confirmation would have to take place with another rendered page — meaning lots of wasted time and wasted resources. With the
onClientClick event, we can interrupt the
Using jQuery, we can bind function to all of these “confirm-able” user controls, which will interrupt the default post-back behavior presenting users with a confirmation dialog box:
jQuery postback confirmation dialog
//Bind a confirmation dialog box to corfirm buttons
//"cancel" prevents the postback from occuring
varresponse=confirm("Are you sure?");
Button targeted by 'confirm' script
Using this method, we can target all user controls with the CSS class confirm. Additionally, if we wanted a broader reach, we could modify the jQuery selector to
input[type=button], or a for all buttons, or all links.
The confirm box
Button groups are an important part of user interface design, but choosing their orientation can often be difficult. I’d advocate that horizontal groupings are better in most cases — consider this:
Imagine that each element on the page is assigned a “Danger Zone” — and area where within one unit of margin of error, an undesirable action will occur. In mobile interfaces, this unit is the width of a finger, or the accuracy of a touch on the device.
The danger zone in button groups extends along the edge of the button that is touching another item. As represented above in orange, the danger zone for a vertical button group extends across the width of each button — covering nearly 50% of the surface. This reduces the touch-safe portion of the button to a slim area, greatly diminishing the effect of “friendliness” in the minds of the users. Clicks to these buttons must be precise, and the consequence is not just the inconvenience of a missed button, but the danger of a click on the wrong one.
Consider the horizontal button group: the danger zone only extends over a small percent of each button. Users can click or touch imprecisely and without stress. Additionally, horizontal button groups easily convey a “forward” and “backward” action, which lends itself well to buttons like Save or Cancel.
One major offender is jQuery Mobile — arguably the defacto standard framework for mobile development. By default, button groups in jQuery Mobile are vertically oriented. Although it is simple to switch the grouping to horizontal, some are under the false impression that the default option is the best choice.
I few years ago, I wrote a post about forcing two divs to be equal height — quite a feat if you’ve ever tried! Since then, a great jQuery plugin has came out that makes equal div height pretty easy to accomplish.
My library has gone through several major revisions — and more than one complete re-write, but now is exactly what I started out hoping it would be: functional, clean, small, and a solid learning experience.
I’d like to share what I learned from this project, and I hope you share back with me through the comments!
Pick one particular function, or aspect of web development/design that you would like your library to handle. Pick a niche need, and be happy with yourself when you fill it.
I decided my library would be a simple way to manipulate elements visually. At this point, I didn’t quite know how — but all you need is the kernel of the idea.
Step 2: Mock-up how would use the library
You always mock-up a webpage before you start building it right? Whether on paper, Photoshop, or even in code, it helps to pretend what the finished product will look like before you build it. It helps you to see obvious bugs, conflicts, and unwanted interactions you don’t catch when looking at the problem mentally.
Have you ever mocked-up your code? Write some implementation, pretending that the class or object you are dealing with exists. Trust me, it will solve problems!
I want my library to do visual stuff with elements, and I like how jQuery looks. How about this?
Looking at my pretend implementation, I can see 1 problem and a hand-full of design implementation points.
The problem: $ as a function name is likely to conflict with lots of other libraries. Through some Googleing, I learn at StackOverflow that functions must start with a $ (dollar-sign) _ (underscore) or letters.
We can also tell some design patterns:
_ is the function name
_ must accept one or more parameters
_ should return itself so that a dot-operator will work
_ must control its scope so that we can have more than one _() on a page
dot-operator methods must also return the _ object for chaining
Step 3: Code up an outline
At this point, we know enough about the goal of our library, and how we will implement it, to begin outlining the structure of our library.
Now don’t try and run your code just yet: we have a pretty big scope issue (besides no functionality):
_() function returns
this , it is actually returning the entire window, or the global scope. Therefore, when we call
_().toggle() , we are asking the browser to call the toggle() method which belongs to the window. Obviously this fails.
This problem can be solved by recursively creating another _ object using the new keyword.
Next to implement in our constructor: making the _() represent an element with some bonus error prevention.
First, we create an about object that will be returned, if the implementation doesn’t specify an element id. Next, we check if the id parameter was sent, and then create a variable to contain that element.
Here is a final version of the _() constructor:
// About object is returned if there is no 'id' parameter
Updated:"23 November 2011"
// Avoid clobbering the window scope:
// return a new _ object if we're in the wrong scope
// We're in the correct object scope:
// Init our element object and return the object
// No 'id' parameter was given, return the 'about' object
Step 5: Prototype method implementation
This step is pretty fun: being creative, and implementing what you want your library to actually do!
I mentioned earlier that I wanted my library to do some visual manipulation of elements. Make a list of what you want to do. I came up with the methods:
size (height, width)
The depth of this step depends on the functionality of your library. Mine were rather trivial to implement:
Did you use this tutorial to create your own library? I would really like to hear about it. Please leave me a comment below.
Stack Overflow user W3Geek asked a question about part of this tutorial. Visit his question: How do these pieces of code function exactly? His question is focused on Step 4 about the object constructor. User Leland Richardson does an excellent job explaining this further — I’d direct you to his thorough explanation rather than duplicating it here.
Bugged by popular jQuery tab content rotators that a bulky, non semantic, to fast/slow, or can’t use custom HTML anywhere you want? Really Simple jQuery Tabs is a jQuery plugin that tries to address each one of those issues. It’s goal is to be as simple and flexible as possible. You can completely rip-out and replace the CSS with your own, changing elements position, styling, etc. It is quite small: at 844 bytes your bandwidth won’t know the difference!
And oh yeah: they rotate!
I have used several jQuery tab/content rotators/panels/things and, although each has been extensively developed and tested, am always left with the feeling that something is missing:
This one doesn’t let use put your own HTML in the tab-link
That one only supports images
The other one is 10,000 lines of code and you only use it once
This one cycles too fast/slow
The purpose of Really Simple jQuery Tabs is to be really simple and really flexible.
Add HTML to your semantically correct list item tab-links
Panes are regular DIVS – put images, text, AJAX loaded content, etc. up in that DIV
Specify (down to milliseconds) how fast to cycle, if you want to cycle at all
bonus feature: only 844 bytes!
Completely customize the CSS to affect layout, coloring, etc…
While designing a page template for a University today, I realized that there were many areas of the future pages that would include street addresses: buildings, conferences, offices, ect.. I thought, “Wouldn’t it be nice if these addresses were links to Google Maps?” Then people could easily find directions or set their phone GPS whilst driving (at a red light of course).
However, I quickly realized that in such a large institution as I am, that no faculty member would take the time to include a maps link. As always, such wondering is the stuff of inspiration. With a little bit of thought, I began writing a little jQuery function that could fulfill my dream.
The function scans the entire webpage for instances of the <Address> tag:
Original address tag
1600 Pennsylvania Avenue NW Washington, DC 20500
And surrounds the address with a link to Google Maps: