At last! After some long weekends and nights, I have finally earned the title of Author!
Black Magic Solutions for White Hat SharePoint is a book that focuses on implementing working solutions without requiring any server side code outside of a standard out-of-the-box SharePoint installation. Pre-Release book sale was announced Thursday, July 11, 2013 – Announcement – and will go on sale August 1, 2013. Secure your copy now for only $7.95 (USD).
The Authors
The book was organized by Mark Miller from End User SharePoint and is a collaboration with six other authors: Dave Coleman, Ben Tedder, Eric Overfield, Josh McCarty, Marc D. Anderson and Wendy Neal. All of them experts in SharePoint and great contributors in the community (which I still wonder to this day: how was I so lucky to land this opportunity? 🙂 )
As you can see from the book’s cover and its reference to jQuery selectors, the solutions described will explore the use of client side technologies like JavaScript, CSS and HTML markup along with libraries and plugins available on the web today. Together, the authors describe how to build working solutions that anyone with Full Control over a team site can implement.
My Chapter
My chapter focuses on how to turn a Team Sub-Site into an Agile Tool to help manage Agile projects. This is an area I have been involved with over the last 1 1/2 years and one that has been successfully implemented across an entire development organization at one of my current employers. The chapter walks through the different business needs that it attempts to solve and describes the approaches taken in implementing such a solution. A working prototype was created in parallel with the writing of the chapter and although not all source code will be available in the chapter itself (just too much), the more interesting parts of it will.
For those of you that decide to purchase the book, I hope that it helps in realizing the tremendous potential of creating client side solutions. I know I did the moment I started to play with SharePoint and have since added SharePoint as one of my favorite platforms to develop on.
So quick… run over to whitehatsharepointsolutions.eventbrite.com and get your early copy now (save ~$5).
paul.tavares 
Hi – I am working through this project as well, and I have noticed a few things.
1 – Why do you append the timestamp to all the procedures that load? By forcing a new version to be loaded at runtime, you make it impossible to set breakpoints in code, every time you refresh, the javascript file loaded changes because of the timestamp. So if I set a breakpoint in chrome, then hit refresh, the breakpoint goes away and a new source file is loaded.
2 – Again, I understand in theory the idea that putting all of the jquery, knockout, etc., external libraries in a single file might make for better performance. But in terms of understanding the code that someone else has written, it makes it very difficult to understand the logic behind what you have done. Maybe I am being dense, but simply by putting a series of document.write statements in the runtime.startup.html file, I was able to load the debug javascript files for jquery, knockout, spwidgets, etc., and actually step through the code.
3 – The system is also very fragile wtih respect to the spWidgets. For some reason, the drop down control is not loading on my implementation, and without it.
All in all tho – the application itself is a remarkable self contained implementation and certainly worthy of study.
Peter,
Thanks for feedback… below are my responses on your comments. I always enjoy receiving feedback on prior projects and looking back at them now, I certainly would have made a few different decisions… More below…
Re: #1 – appending the timestamp.
While developing the solution (on O365) I was not always getting the most current version of a file when the page loaded. I have seen this issue in other SP installations with the only solution being to ensure the URL is unique. You can see this as well with some of MS’s own files on the page. However, since this project, I have changed my approach. I no longer append a runtime generated unique value, but there have a static one per file (a build timestamp). This will ensure that unless the file has truly been altered, the timestamp will not change on subsquent page refreshes.
Here is a quick fix you can apply to your version of the code… On the runtime.startup.html file, find this line:
and change it (add) to the following:
re: #2 – one single file for 3rd party libraries
I have evolved since that solution was put together… I normally don’t have the need to debug 3rd party tools, but have taken the same approach for my own apps (group them all into one file – specially when creating SPA where the entire APP is inside a single file)… My new approach is to have two loading files: one for development, where all files are loaded individually into the page, and a second used to package up the production version. Or, in some cases, I have a url parameter that switches between the two…
Even the version you have supports an alternate way to load the page specific scripts… by adding debug=1 to the page’s url (ex. main.aspx?debug=1) the script file specific to that page will be loaded using script tags instead of jQuery’s $.loadScript(). I do this because I found that Firebug does not show the scripts loaded by jquery and I needed to be able to debug them.
re: #3 – SPWidgets (LookupField) not working
I just ran this on the original site where I developed – which is on O365 – and sure enough it is broken… The issue is the fact that SharePoint recently made a change to how Required Fields html markup is generated/displayed. You can read more about it here. To fix this a few changes would need to be done… The primary location is the Agile.getFormField function, which is the centralized function that finds the fields on the page. It would have to handle cases where the field may be Required. There are other areas as well that would need to change… Example: the acceptance.js file would need a change on line 91, to ensure the input field is found (notice how I’m trying to find a title of ‘Story’ when now its ‘Story Required Field’:
Acceptance.$storyTr.find("input[title='Story']") .SPLookupField(Acceptance.lookupFieldOpt);Thanks again for your feedback and I hope that my approach is worth the study 🙂
Thank you so much for the immediate and detailed response! Working on it now…
Well, I can say I’ve had quite some fun working on the implementation of your Agile Team Site solution as detailed in the new ‘Black Magic’ book. Most things work but some do not and I’m still working through where the fault may be mine or my company’s customized master pages. Once I’ve got things sorted out, would you be available to help me figure out those things that I still just can’t get to work?
Barbara,
Glad you are enjoying the implementation…I think the setup I have will lay a good foundation for you to add much more functionality as your users start to identify more needs.
Absolutely… I will be available to help you in getting everything working as I did in the prototype. Just last week I re-implemented the solution (successfully) on SharePoint 2013 – just to prove that it works. Only had to do a few minor adjustments; mostly cosmetic due to re-named css classes in that version of SharePoint.
I will send you my personal email.