Geeks With Blogs
David Jacobus SharePoint Consultant

I recently blogged about Knockout with JQuery and the SharePoint Client Script Object Model.  I saw a use for some of the techniques used in SharePoint 2013 crossing over to SharePoint 2010.  One of the issues, I am having working with my current client is that they are not master of their own domain.  What I mean by that is that they have contracted with another third party to mange their SharePoint environment which is located off-premise!  Okay, as a consultant, that is a parameter/limitation that I need to live with!   To develop a farm solution may take me a few days or more but I can depend upon a 6-8 week deployment cycle for the third party!  I am not knocking the third party here as I saw the same cycle when developing for Microsoft in the past.  What this does mean is that to react to client needs I need to be creative in getting custom development on SharePoint.   The first step was to look toward Sandbox solutions as a way to mitigate the long deployment lead times for farm solutions.  To my dismay, I found that web parts and event handlers were sporadically running and could not be depended upon for production.   I could deploy artifacts: images, pages, scripts, etc. but I could not depend on sandboxed code to run!  I am actively, working with the third party to rectify this situation but again, I am hampered by time.  Okay, I could use the SPA techniques used to build applications on SharePoint 2013 with the Client Script Object Model (CSOM)!  Here are my steps to make this happen:

1.  Use Visual Studio and create an empty project

a.  Create a modules folder and add  the following modules:

    1) HTML 

    2) CSS

    3) SCRIPTS

    4) SitePages

    5) Images

The difference between a SharePoint 2013 (SPA) and what we need to do for SharePoint 2010 is in the site pages module we will have a template page which we will house a generic Content Editor Web Part (CEWP) and link to an HTML page which in turn links to, CSS, Images, and Scripts.   Simple and works beautifully! 

I thought I could do this, test my CEWP’s on a single page which I deploy in my solution and then use the CEWP on the clients web parts pages.  It does work, for single web parts on page!  When I tried to add more than one web part on a page I found that the first web part worked but none after!  Wow!  This was a shock to me.  I had this nice plan in place to meet my customer needs!  What was going wrong???  At first, I thought it was Knockout and could not data-bind (islands) of HTML on a single page?  So I tried JSRender and had the same problem!??  I then,  thought, just get rid of the data-binding libraries and just use JQuery to get the data on the page.  Same Problem!!!  So, I kicked myself, as obviously, it was and issue with CSOM.  I think, it must be with the client context in CSOM not being able to be changed within a web part page (If some one know how to change the client context within the same web part page in CSOM then please let me know, as it would make my life, and other developers whom have to live under this third party umbrella, easer).  For the time being:  I have solved this issue by using page viewer web parts to look at the single page applications I was using as test pages for my web parts.  So on my home page, I have a JQuery UI tabs view with 8 tabs, 5 of which use the techniques described above using page viewers. 

Posted on Friday, March 21, 2014 8:28 AM | Back to top


Comments on this post: Single Page Applications (SPA) Versus Web Parts SharePoint 2010

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © David Jacobus | Powered by: GeeksWithBlogs.net