Archive for CAPS

Quick Tip: CorasWorks Variables in your Path References

Now nearly two years old, you have been using CAPS, the CorasWorks API for building solutions in SharePoint, for a while; and hopefully you’re hammering out some pretty slick custom displays. However you keep running into one place you can’t leverage your CorasWorks variables, be it Global Variables or our built-in ones. Namely, how do you centralize your resource files (i.e. JS, CSS, images, etc) and yet still be able to leverage a Global Variable to reference those files?

CAPS has the answer for you: the “GetFileContents” method!

You may say “Wait, that is not right; is it…?” but it is. Normally, you might use a CorasWorks CAPS HTML Viewer to call an HTML file that is the base of your display; and to keep things clean, you reference all your dependent JS, CSS & Image files inside that HTML file. However that means that you have to reference them either via fully-qualified domain names (which then are not portable) or via relative paths, which is not always conducive to centralizing those resources. Well here is the technique…

In your CorasWorks CAPS HTML Viewer, instead of pointing directly to the HTML file (a scenario discussed in a previous blog post), make a call like this:
%SiteURL%/_layouts/CorasWorksApps/CorasWorksApplicationService.ashx?RequestType=GetFileContents&FileUrl=[Your Global Variable]/Folder/YourFile.htm

Then in your HTML file, you can now freely use references like:

<link href="[Your GV]/Folder/YourFile.css" rel="stylesheet"/>
<script src="[Your GV]/Folder/YourFile.js"></script>
<img src="[Your GV]/Folder/YourFile.png" title="Your Image">

This also open up the use of any of the built-in CorasWorks variables or your own Global Variables for anything else in that HTML page (think maybe current Username or Site Title in an <h1> tag). The reason this works is because the contents of the file – in this case, an HTML file – that is being queried via the GetFileContents method is automatically being passed through the CorasWorks variable replacement engine, thus ensuring proper translation/insertion of variable values anywhere within that HTML. And because that HTML includes those resource file URLs, their location is automatically set using those variables.

Integrating SharePoint data into Office Apps via CorasWorks API

Yes, it’s that simple! Whether it’s a Task Pane app in Excel, Word, PowerPoint or Project; or a Mail app in Outlook, you can easily leverage CAPS, the CorasWorks API, to integrate SharePoint data into your Office Apps.

Organizations with Office 2013 have limited options when it comes to published Office Store apps that integrate SharePoint data into Office Apps; a quick search of the store for just “SharePoint” and filtered by each Office client shows few choices, most of which are simple Site or Document Library explorers. Instead, wouldn’t it be great if you could be in say Excel and pull down a collection of SharePoint list items, filtered & aggregated across multiple sites, site collections or web apps – with CorasWorks, you can. Building these Apps is quick & easy; anyone with web developer skills (HTML + JS + CSS) can do it.

As Microsoft says:

Task pane apps enable users to see the app for Office side-by-side with an Office document… and supply contextual information and functionality to enhance the document viewing and authoring experience.1

What greater source of “contextual information and functionality” do most Microsoft shops have than SharePoint?

As long as the Office clients are amongst the applications end users leverage most often, integrating business data into that experience – and remember, that integration can be two way – will have great potential. The Office Apps provide for a seamless user experience & without requiring they open a separate browser to copy/paste between; and now with CorasWorks, the functionality of those Apps can be taken to the next level!

1: Overview of apps for Office 2013

Auto-generate PowerPoint decks using CorasWorks

For everything CorasWorks can do – our visual Application Designer, reporting & dashboard wizards, Gantts, maps, grids, calendars, custom forms, workflow, integrating external data, the list goes on – I still have seen even the most savvy business user succumb to the need (or desire) make this same mistake: copy & paste data out of an application and into a PowerPoint presentation. Ugh!

CorasWorks users of the world, know you do not have to fall victim to the same trap. Working with our Services team, we can design & implement a solution that uses the CorasWorks v11 platform to auto-generate PowerPoint decks (PPTX files) in a matter of seconds and even save them directly to a SharePoint Document Library.

The design is almost elegant in its simplicity; you start with a template PPTX file that includes spaces & placeholders for the dynamic content that will be injected. Using the CorasWorks APIs, we can then load almost any data or content into the deck, including:

  • Any data within the local SharePoint farm
  • Any data within remote SharePoint farms
  • Any data within external or line-of-business systems accessible via OLEDB, ODBC, OData/REST service or SOAP web services
  • Aggregations and/or analysis of accessible data
  • Snapshot images of any CorasWorks-generated chart or Gantt
  • Copies of any image file upload to any SharePoint Library

Other key features include the ability to dynamically replicate one or more slides based on data (i.e. one slide per distinct Fiscal Year, one per Project, etc), define & pass-in variables to use in the filename and even generate “read-only” presentations that can be opened in PowerPoint & used for briefing from but cannot be modified (governance anyone…).

If you’re interested in learning more about how CorasWorks can help add not just efficiency, but consistency & governance, to your process for generating & delivering PowerPoint presentations, reach out today. Email for more info.

Tokenize Me

While working with a customer recently we wanted to pull items from multiple libraries that were similar in structure to show the current status of documents in an advanced chart.  The results of the data were to be shown in columns stacked by status by library.

How to dynamically retrieve the friendly name of the library from each item being returned in the CAPS response? An easy, yet inelegant, method is to add a text column to the libraries that simply defaults to a hard-coded value with the library’s name when a document is added.  But, why add something if it is not really needed, and what if you are dealing with more than just a few libraries?

XSLT 2.0 to the rescue.  One of the great functions of XSLT 2.0 is the tokenize function.  It is pretty easy to use, yet very powerful for a variety of tasks.  In this scenario I wanted to grab the name of the library from an item using the “FileDirRef” column and I didn’t want to apply a recursive template or such to get to it.  I wanted to keeps things as simple and lightweight as possible.  So here it is:


Just tokenize the “@ows_FileDirRef” value from the CAPS response using the “/” as the delimiter and then tell it you want the last value using the predicate filter [last()] on the result.

Happy building!

BYOF – Responsive SharePoint Apps with CorasWorks

BYOF? Bring Your Own Framework – meaning whether it’s Bootstrap, AngularJS, Durandal, Foundation or any other (maybe still-to-be-invented) responsive framework, you can use CorasWorks to accelerate the development & expand the functionality of your responsive apps on SharePoint.

There are three core capabilities that the CorasWorks stack provides that will facilitate creating these richer solutions:

  1. The CorasWorks Application Designer as the base for you content management process. Easily create a site using the App Designer and you’ve got all the built-in capability you need to define, manage & even work through approvals for the content that will flow into your responsive app.
  2. The CorasWorks Application Service (CAPS) as your API for not just your data access but also dynamic HTML generation. Sure the native CSOM or REST API will provide access to raw SharePoint data but only CAPS will give you a single, integrated touch point for all your data needs – including executing multiple queries serially or in parallel – while also providing access to the only XSLT 2.0 processor on SharePoint, for generating your HTML.
  3. caps.js, the javascript library for rapidly building client-side with the CorasWorks API, CAPS.

With these three layers of your application now accounted for – specifically managing the content, accessing the content & building the application itself – you’re well on your way to creating a beautiful, responsive application that will have your users saying “Wow, this doesn’t even look like SharePoint!”

Want proof? Our own CorasWorks Customer Center is built on the Bootstrap framework but the site is running on SharePoint 2010. CAPS is used to drive all the dynamic content on the site, while an App Designer-driven site behind the scenes manages the content submission & curation process.

And of course if you’re looking for a partner to help design and/or build a responsive SharePoint-based solution for you, our Services team can help; just email for more info.

Access the URL of a file in a Document Library via Lookup

This was one of those “I can’t believe it works this way” moments in SharePoint; if you’ve spent anytime architecting or building applications on SP, you know the feeling I’m talking about.

I had a simple scenario of wanting to allow users to easily link items in a List to a file in a Document Library; however, rather than requiring they copy-paste the URL to the file (manually or otherwise) within the List item, I wanted to use a Lookup. Worked great at the UI layer for end users; however, as soon as I tried to build a display that leveraged the JOIN ability within the CorasWorks API to pull the file URL based on the Lookup value, I hit a wall – any & all fields that contained some or all of the file name or path cannot be queried via the SPQuery.Joins property. I tried them all, including the most obscure of internal system fields like “LinkFilename2″ but none worked.

A quick search of the web revealed I was not alone; even worse, all the solutions I could find required custom workflows or even custom code and all followed the same pattern – create some event handler to grab the URL of a file after upload & write it to another field. Sure it would work, but getting any custom code installed on this client’s server is not easy and requires a multi-week CCB process. All that just to get the URL of an item I already have a Lookup relationship for?!

Then I had an idea: I knew our CorasWorks Actions provided direct and easy access to any field on a List or Library item, including all hidden & internal system fields. So I took the equally direct and easy approach to solving the problem – I created a Set File URL Action (a CorasWorks Modify Item Action) that wrote the “Server Relative URL” for a document into a field I can access through the JOIN on my query.


I then created a List Activation that automatically runs said Action every time a file is added to the Document Library and I’m set – no custom coded event handlers or workflows to have to write & deploy. Another streamlined solution thanks to CorasWorks!

What is the CorasWorks CAPS HTML Viewer web part?

If (hopefully when) you upgrade to CorasWorks v11.3.2, you may have noticed a new web part available to you: the CorasWorks CAPS HTML Viewer.

Great! But was is it…? If you’ve ever used the native Content Editor Web Part (CEWP) to load an HTML file from a Library via the Content Link property, then prepare to upgrade your experience! There are three main limitations to using the CEWP in this way; one, it cannot load an HTML file that is not on the local site (i.e. the same site where the web part resides) unless you’ve enabled Anonymous authentication. This means if you have some centralized content in an HTML file you want to display across multiple sites, you’ll have to enable Anonymous authentication or the CEWP will display a message saying it cannot load the content [Reference here, in the IMPORTANT tag].

Second, also on that same Reference page under the NOTE tag is this quote: “If you enter a URL into the Content Editor Web Part as a relative link, the link converts to an absolute URL when the entry is saved.” It then goes on to say if the page the CEWP is on will then be moved (think DEV to QA/Staging to PROD) “…you will need to edit the Content Editor Web Part on the production server and update the URLs manually.” Eek!

Finally, say you want to point to some endpoint (wink wink, CAPS call) that dynamically generates some HTML – so instead of a static HTML file, you want to inject dynamic HTML into a page via web part. The CEWP simply does not support this; use the Content Link property to point it to a Service/API that generates HTML and it will fail to display it.

Fortunately, the CAPS HTML Viewer address all of these limitations. First, not only can you use it to point to any HTML file anywhere within your SharePoint farm – you can do so without having to enable Anonymous authentication.

Additionally, it supports all the CorasWorks built-in variables as well as any Global Variables within your URL. So no more worries about the CEWP converting your relative URLs to absolute ones.

Finally, it fully supports loading dynamic HTML (again, generated via CAPS or any other capable Service/API) into a page; so you’re no longer limited to static HTML files.

No more will you be limited by or struggle with the Content Link property of the Content Editor Web Part – let the CAPS HTML Viewer unlock the full potential of your application design.

UPDATED: CorasWorks Application Service capabilities index

It’s been a year since the CorasWorks Application Service was first released publicly – and if you missed it before, we previously posted a concise listing of everything you could do with the version of CAPS that launched with v11.3.0.

Now that CorasWorks v11.3.2 has been released, it seems like the right time to update the capabilities index for CAPS as much has been added in the last two platform releases. Just see for yourself…

Added in v11.3.1

  • Addition of a new “ProcessGlobalVariables” method providing create, edit & delete capabilities for your CorasWorks Global Variables
  • Addition of a new “ProcessList” method providing create, edit & delete capabilities for SharePoint Lists & Libraries
  • Addition of a new “StartWorkflow” method allowing you to kickoff SharePoint workflows via CAPS call
    • Addition of a new “RunOptions” parameter to the StartWorkflow method to allow for setting the corresponding run parameters (Added in v11.3.2)
  • Addition of a new “ListType=External” parameter to the ProcessBatchData operation to provide create, edit & delete capabilities against External Lists leveraging External Content Types
  • Addition of a new global “DatesInUtc” parameter, available on all CAPS operations, for telling the Service to interpret & use the UTC value of any & all CorasWorks date variables within your call
  • Addition of a new global “ContentDisposition” parameter, available on all CAPS operations, for specifying the Content-Disposition header you want the Service to specify for its response
  • Addition of a new “Title” parameter to the CopyFile method, which enables the renaming of a CorasWorks Action or Central View definition if that is what’s being copied
  • Improved error handling for mal-formed XSLT paths

Added in v11.3.2

  • Addition of a new “GetContentTypes” method for enumerating all the available Content Types
  • Addition of a collection of new parameters on the “GiteSiteCollections” method…
    • GetSubsites = true/false, if true returns the children of the site the CAPS call runs in the context of
    • SiteLevels = Integer, specifies the number of levels deep to iterate through & return children sites
    • StartAtRoot = true/false, if true tells CAPS to start enumerating subsites from the root of the Site Collection
  • Addition of a pair of new parameters on the “GetSiteUsers” method…
    • GetUserProfiles = true/false, if true returns the data from the User Profile Service instead of the User Information List of the current site collection (Requires use of Server CAL and User Profile Service)
    • Properties, a comma-separated list of the properties on the object that you wish to return (if absent/null, all properties are returned)
  • Addition of a new “Properties” parameter to the GetSiteInfo and GetListInfo methods, a comma-separated list of the properties on the object that you wish to return (if absent/null, all properties are returned)

CAPS is like a fine wine – it just keeps getting better with age!

Adding reveal, overlay & push sidebars to a SharePoint site

Sidebars are all the rage in web development today; from their simple beginnings on mobile devices – where the flexibility to tuck a full menu or block of content behind a click or swipe can net valuable screen real estate – to growing usage on the web in general, you can’t deny their popularity. Now wouldn’t it be great if you could add the same capabilities into your SharePoint-based applications & sites? How’s that for a leading question ;)

We’ve had great success with the Slidebars jQuery plugin by Adam Smith; it fits two key criteria we look for anytime we’re evaluating the addition of a new jQ plugin to a SharePoint application – compact size & CSS that won’t conflict with the myriad of Core.css quirks all us SharePoint developers must endure.

The first criteria is easily checked and Adam even calls it out in the first paragraph of his site: “ultra-light at 1469 bytes (js) & 499 bytes (css).” Well done Adam! As for the second, well that just requires some quick validation within a SharePoint site and we’re happy to report it works great, especially with a CorasWorks Application Designer-based site.

Implementation is straightforward – within your site’s masterpage…

  1. Load the obligatory resource files: jQ (1.8+) as well as the Slidebars JS & CSS
  2. Add (or if you already have one, update) a “viewport” meta tag to the page:
    <meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no">
  3. As a direct child of the <body> tag, wrap the <form> tag that constitutes the main portion of your page content within a DIV which you give an ID of “sb-site”
  4. As siblings to new said DIV, add ‘n‘ additional DIVs each with a class of “sb-slidebar”; you can have more than one sidebar and can set its position on the page through additional helper classes
  5. Initialize the plugin on page ready:
    $(function() {

Optionally, you can then add new or update existing page elements that will trigger the opening & closing of the sidebars; this is accomplished by just adding corresponding CSS classes to the elements, described on the Slidebars site here.

We’ve found Slidebars to be a great way to bring an improved user experience into our SharePoint-based applications – and thanks to features like CAPS and CAPS-Xt, CorasWorks customers can even dynamically load sidebar content based on user interaction, roles & permissions. It’s a great complement to our existing feature set and one I hope you’ll try out yourself.

Hiding a Java Applet until it’s fully loaded & ready to display

I recently designed & implemented an application for visualizing multiple data sets with interconnected many-to-many relationships – some real complex radial visualization type stuff. To satisfy the requirements, a Java applet was leveraged for the interactive UX. One nagging issue I had though was that, by default, when you load a Java applet on a web page, you only see the default Java loading animation (a coffee cup inside a blue spinner) while the JAR file is being downloaded & launched.

In my implementation though, I was leveraging the newer JNLP-based approach of defining the applet’s parameters; and not only is my JNLP dynamically generated server-side (based on end user inputs & interactions), contained within my JNLP are some attributes for loading data via CAPS (the CorasWorks API) calls. The issue is that the JNLP loading & CAPS calls all happen after the JAR has been loaded – leaving my users to stare at a blank screen for sometimes 5 seconds or more.

Enter the concept of Java status and event handlers (reference). Starting with the release of Java 7 (July, 2011), web developers can tap into key statuses and events of an applet on a page; and just like we often do elsewhere in our client-side development, we can then use those event handlers to improve the user experience. In my case, that meant:

  1. Keeping the Java applet invisible while it loaded everything
  2. Displaying my own loading image/animation while it loaded
  3. Hiding the loading content and making the applet visible once ready

And here’s how I did it…

First, I ensured that I had the “java_status_events” property on my parameters object set to true. Then I made sure I had an ID property & value for the applet specified in my attributes object. Something like this:

<div id="AppletContainer" style="visibility:hidden">
    <script src="//"></script>
    <script type="text/javascript">
        var attributes = {ID:'MyApplet',width:1000, height:700};
        var parameters = {
            jnlp_href: 'URL-to-JNLP-Service',
        deployJava.runApplet(attributes, parameters, '1.6');

Then I created a DIV, which I placed directly above my “AppletContainer” DIV:

<div id="LoadingContainer">
    <img src="images/Loader.gif">

Finally, I added an event handler to hide my “LoadingContainer” and display my “AppletContainer” when the applet is done loading:

$(function() {
    KTMApplet.onLoad(function() {
        $('#AppletContainer').css('visibility', 'visible');

There you go – a solution for showing my own custom loading animation while my Java applet loads, then displaying the applet as soon as its ready. There’s other events & statuses you can attach to, but chances are, this is the one you’ll use most often.

And in case you’re wondering, you do have to use the CSS ‘visibility’ property, as opposed to display (i.e. show/hide with jQuery) because an applet that is hidden – say in a DIV with a “display:hidden” style – will not register its event handlers, thus preventing your ability to display it when loaded.