There is always loads to be said about why NOT to rely on javascript for validation but what’s better than an example.
Disable javascript on your browser and then go to http://www.geni.com/ and hit login, it will not only log you in but also say you have a 20% complete profile. The only saving grace is of-course it says the site requires flash and javascript!
I am currently working on yet another pet project http://panditg.com (currenty underconstruction, there is a beta url if you want to try it out) its an Indian matrimonial website, in case you dont understand what that means read more here http://en.wikipedia.org/wiki/Marriage_websites .
Anyway that’s not the reason why this blog post was written as the post’s title suggests. I wanted to have a drop down for two items item1 and item2 and based on the selection of item1, item2 would change. I needed to have it working n the non javascript environment and also not make use of ajax to populate the second select box.
As always when I am trying to look for interesting solutions before I start thinking I somehow end up on this mans website 
So chris posted a really interesting solution but since I am using jquery for this project (and that i am fairly new to it) i decided to implement the same in jquery. I am sure it can be written in a better way as other jquery gurus can suggest, feel free to leave a comment.
Markup:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | <select name="quicksearch[religion]" id="quicksearch_religion">
<optgroup label="Hindu(Any Caste)">
<option value="Hindu(Any Caste)_1">Adi Dravida</option>
<option value="Hindu(Any Caste)_2">Aggarwal</option>
<option value="Hindu(Any Caste)_3">Agri</option>
<option value="Hindu(Any Caste)_4">Ambalavasi</option>
</optgroup>
... more markup
<optgroup label="Jain">
<option value="Jain_258">Digamber</option>
<option value="Jain_259">Shwetamber</option>
<option value="Jain_260">Others</option>
</optgroup>
<optgroup label="Parsi">
<option value="Parsi_261">Not Applicable</option>
</optgroup>
<optgroup label="Jewish">
<option value="Jewish_262">Not Applicable</option>
</optgroup>
<optgroup label="Buddhist">
<option value="Buddhist_265">Not Applicable</option>
</optgroup>
<optgroup label="Other">
<option value="Other_266">Not Applicable</option>
</optgroup>
</select> |
This select box is inside a form tag ofcourse and each form element is a list item, the last list item being the submit button etc. Someday when i have more time I would make this function more generic or make a plugin out of it. For now just as a note (#frm-quicksearch is the form and #quicksearch_religion is the select box)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | /** * jquery to convert the large select into changed selects * to read from one master select item and make two different selects */ $(document).ready(function() { $('<li>').insertBefore('#frm-quicksearch > ol li:last').html('<select name="quicksearch_religion" class="religion">'); $('<li>').insertBefore('#frm-quicksearch > ol li:last').html('<select name="quicksearch" class="cast">'); $('select.cast').css('display','none'); // hide the parent select box $('#quicksearch_religion').css('display','none'); // popular the religion one $("#quicksearch_religion").find("optgroup").each(function() { $('select.religion').append('<option>' + this.label + '</option>'); }); // attach a handler $('select.religion').change(function() { // empty all select options $('select.cast').empty('option').css('display','block'); $('#quicksearch_religion > optgroup[@label=' + this.value + ']').find('option').each(function() { $('select.cast').append('<option value="' + this.value + '">' + this.text + '</option>'); }); }); }); |
This script has the following differences
I recently updated my iPhone to 2.0.1 and played around with some apps from the app store. This native wordpress app is so cool I can now blog on the go
Recently I have been hearing a lot about Hudson, with a friendly web based interface for building / testing and monitoring of processes and it runs on it owns web server and serves pages with clean hackable urls and rss feeds. For anyone who is interesting knowing more about it, the slides below explain what it does, it seems quite promising especially considering how easy it was to install it using java web start all under less then 3mins.
Some other interesting links are:
I keep getting confused with terms with CVS esp. when I have to start doing some stuff that I usually don’t have to do on a regular basis. So writing it here so that I can refer to it later.
Trunk: The trunk is the mainline code base. Its similar to a branch with no name, so by default all the commits go to this nameless branch.
Branch: Its an alternate place on the codebase where the commits go other than the trunk. The idea behind is when developers want to work on fixes for a particular release where as other set of developers work on the next release. Then doing a branch is useful. My previous post Branching and Merging Code in CVS has more details on how to use it.
Working Directory: Working directory is the current directory where the code was checked out.
Tag: A tag identifies a set of revisions of files in the repository. There are two kinds of tags: static and branch.
Sticky: The term ’sticky’ in CVS has two somewhat different meanings depending on the context. If you have checked out from a static tag, then those files in your working dir will be ’stuck’ to that tag - and you won’t be able to commit changes to them until you ‘unstick’ them. This is because there may not be a place for that change to go. For example the tag may identify revision 1.5 of a file which already has a revision 1.6. Since there already is a revision 1.6, you can’t make a new revision 1.6 (unless of course you make a branch…)
Branches on the other hand, are implemented in CVS by being ’sticky’ to a branch tag where commits are allowed and go into that branch rather than the Trunk. In this sense a branch tag is also known as a ’sticky tag’. So if you have a branch based at the above file’s 1.5 revision you can now make a commit to that branch. The new file will have revision number similar to 1.5.1 meaning it is the first revision based on revision 1.5. This is a completely different revision of the file from 1.6 as it is on the ‘1.5 branch’ of that file.
CVS has never been a configuration management system of my choice but none the less there are times when it doesn’t come down to my choice, I recently had to branch some code as I had to start on a new set of developments where as the previous development hadn’t been released so I had to save the snapshot of the code and carry on with the development for the next release. Not ideal! but that was the case.
Documenting this for now so that I can refer to it later and for anyone else who might find it useful.
DISCLAIMER: I have always found working with CVS very daunting and hence I am always extra careful in running the commands. The following instructions work for me and I cannot guarantee how it will work for you. So execute the commands only if you understand the instructions and are sure what you are doing.
Go to working directory and make sure you have the most recent version of the code:
cvs up -A
Do a cvs stat on any file to ensure that you do have any sticky bits set, from a previous branch etc.
$ cvs stat stuff.xml ============================================================ File: project.xml Status: Up-to-date Working revision: 1.19 Repository revision: 1.19 /code-monkey/confi/stuff.xml,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none)
Ensure that the working and repository directory are the same.
Tag the current set of files as one save point. Which means you can later refer all those various versions of files stringed together for one tag.
$ cvs tag CODEBASE_2008_08_30
Once tagged, you are ready to branch the code based on that tag.
$ cvs tag -r CODEBASE_2008_08_30 -b CODEBASE_BRANCH_2008_08_30
This creates a branch of your code now called CODEBASE_BRANCH_2008_08_30
Now you can switch to the branch code using the following command:
$ cvs up -r CODEBASE_BRANCH_2008_08_30
Now you can confirm as well which branch you are on by using the stat command on the same file.
$ cvs stat stuff.xml =================================================================== File: project.xml Status: Up-to-date Working revision: 1.9 Repository revision: 1.9 /code/stuff.xml,v Sticky Tag: CODEBASE_BRANCH_2008_08_30 (branch: 1.9.1) Sticky Date: (none) Sticky Options: (none)
Working on the branch:
Working isn’t any different from working on the trunck. All the code that you commit while you are on the branch goes straight into the branch.
Merging the branch to the trunk:
The important thing to remember is before merging you need to switch back to trunck.
You can now verify using cvs stat command as explained above.
Doing the actual merge
cvs up -j CODEBASE_BRANCH_2008_08_30
Now examine the output for any conflicts etc and then fixing them. Its worth at this point of time to run the application and check everything is working fine, run your test suites etc. Once confirmed everything is working fine, its time to check stuff back into the cvs.
You can now either do a full commit of your working directory which is not a good idea or identify which files had to be merged and check those only. To get to know the state of the current working directory run the following command:
$ cvs -nq up
and it will show you all the files with their status’. The files starting with M are the once which have been modified and the once with C are conflicts, resolve them as usual and then you can check files marked as M back into cvs with the comment that they have been merged from the branch.