I have been investigating jQuery for about six months now. There are some great examples of it out on the Internet through sources like Paul Grenier’s “jQuery for Everyone” series on End User SharePoint as well as Jan Tielen’s blog. Most of the examples I have seen relate to using it to change style and formatting of standard content. It is definitely good at that with its rich selector formatting.
In a recent project I hit an interesting snag that was ultimately solved by using jQuery. I had an interesting project requirement for a SharePoint workflow solution where the users wanted to be able to cancel a request by simply clicking a button from a list of open requests.
Initially I didn’t expect this to be much of an issue since I had done some DataForms in the past. I ended up finding two limitations to this process though; overriding default values is not easy because the fields are databound, and any changes to any rows are saved on submit of the form. This means that if you do override the field you are looking to change, every row shown in the form would change not just the individual row for the button clicked.
My next thought brought me to building a custom web part to do this. In fact this is something I have done many times in the past for somewhat similar requests. This was not a good option though since the rest of the display could need to change frequently and really should be more dynamic and configurable. In the end the cost to maintain this would be too high.
I decided jQuery was the best solution for this particular project. It gave me the ability to keep the display as a DataView which is easily configurable, and call a script on the page that can perform updates via a jQuery to SharePoint UpdateListItems web service call.
In the end, the code was very simple yet effective. As I get a handle on all of the capabilities, I see it becoming more and more central to my development toolkit.