Microsoft cloud engineer - SharePoint, Office 365, Azure, DotNet, Angular, JavaScript.
Microsoft cloud engineer - SharePoint, Office 365, Azure, DotNet, Angular, JavaScript.

SAAM – Site Asset App Model

Developers have more options in SharePoint 2013 than any version before.   App Model is center stage.  Understandably this has created some confusion and debate in the community.   I’d like to suggest another coding pattern to consider in addition to pure App Model which I call “Site Asset App Model.”

Long before SP2013 released, I would add jQuery “widgets” to pages in MOSS2007 and SP2010 with a Content Editor.  Upload HTML, CSS, and JS files.  Simple and effective.   Requires no special infrastructure changes.  This approach remains valid and has actually improved with advancements like :

  • JavaScript frameworks
  • Angular,  Knockout
  • HTML 5 browsers
  • REST /_api/ endpoints
  • ASP.Net WebAPI
  • Entity Framework
  • BreezeJS

I might not always use pure “App Model”, but I’m 100% sold on JavaScript front end development and the “from Bricks to Houses” philosophy (http://channel9.msdn.com/Events/SharePoint-Conference/2014/SPC404)    Call this whatever name you like, but JavaScript coding has advantages for both developers and administrators alike.    I suggest coding JS first, then fallback to C# wrapped in WebAPI over HTTP, and finally farm solution WSP as last resort.  

Please leave a comment if you found this helpful!  

shades_smile

Diagram

image
image

How to Use

Configure

  • Create new folder in Site Assets
  • Map drive letter
  • Create HTML/JS/CSS files with local IDE (Visual Studio, Brackets, NotePad++, etc.)
  • Add page to SharePoint site
  • Add Content Editor to page. Set source Property to HTML location.

Debug

  • Edit source HTML/JS/JSS
  • Reload with browser
  • Press F12 to debug, set breakpoints, inspect DOM
  • NOTE – adding the JS statement “debugger;” can help raise a local browser event. That can be a nice trick to more easily create breakpoints in your editor instead of scrolling the same codebase again with F12. http://www.w3schools.com/js/js_debugging.asp

Admittedly there are drawbacks:

  • No Visual Studio F5 debug
  • No full package (.APP)
  • No Office365 store
  • No app-only principal (limited to current user permissions)
  • Hard to deploy multiple instances

However, there might be times when SAAM is preferred:

  • Working on SP2007/2010
  • Lacking SP2013 App Model infrastructure (Wildcard DNS, Service Apps, etc.)
  • Visual Studio not available (required for .APP package/deploy)
  • Non-SharePoint developers comfortable editing HTML/JS/CSS directly

Comparison Table

Feature SP2013
“App Model”
Site Assets
App Model
(SAAM)
HTTP call host web without SP Request Executor Proxy NO YES
Support REST to External Content Types made in SharePoint Designer NO YES
List and Library user data kept if app uninstalled (code upgrade) NO YES
Create standard Views for lists and libraries with App user data NO YES
Works on SP2007 and 2010 older versions NO YES
Restricted to “App Web” where many features disabled YES NO
Requires server infrastructure changes YES NO
* Claims authentication YES NO
* Wildcard DNS on network YES NO
* Service Applications YES NO
* Additional SQL databases and service accounts YES NO
Requires security manifest YES NO
* Permissions plan to use YES NO
* Web service endpoint URLs YES NO
Able to publish and sell in Office 365 Store YES NO
Able to use App Identity Security Principal YES NO

SP2013 “App Model”

Site Assets App Model (SAAM)

straight-jacket-costume

References

http://channel9.msdn.com/Events/Speakers/Scot-Hillier

  • ​”From bricks to houses” > wider view beyond “App Model” looking at all front end coding (JS/REST)

http://www.itunity.com/community/questions/view/question/id/1

  • ​Use SharePoint where it makes sense (components ready), but now able to include a wider menu of 3rd party technology choices.  
  • Non-Microsoft, Google, others, and a whole web of innovation beyond SP core.

http://blogs.msdn.com/b/amigan/archive/2012/12/10/part-2-introduction-to-sharepoint-2013-app-model.aspx

  • Detailed comparison table
  • Yes, some things cannot be done in “App Model”
  • Yes, farm solutions are still valid  (but as a last resort – try front end coding first)

http://sharepointpromag.com/blog/sharepoint-2013-s-cloud-app-model-it-s-what-you-wanted-all-along

  • ​And ultimately, it’s going to be moot. In multi-tenant environments such as Office 365, this is the only real option.
  • Office365 is the gold standard for low administrative effort.

© Copyright 2016
@ SPJeff

Return to Top ▲Return to Top ▲