Archive for SharePoint 2010

Who Really Needs Custom Forms on SharePoint Anyway

Right about now, a lot of IT decision makers, SharePoint users & developers are all probably thinking the same thing – that somewhere in the halls of the Microsoft campus in Redmond, somehow this idea has taken hold: that no one wants, alas needs, custom web-based forms on SharePoint.

How else do we explain the sudden, if not buried, announcement that not only has InfoPath Forms Services been extended indefinitely on O365 and included for the next release of SharePoint on-premises (i.e. SP2016), but the most promising alternative on the horizon – Forms on SharePoint Lists (FoSL) – has simply been cancelled.

Consider the facts:

  1. A few weeks before the SPC14, Microsoft makes a big announcement that they’re retiring InfoPath. They say InfoPath 2013 will be the last version of InfoPath, InfoPath Forms Services is not committed to indefinite O365 support (i.e. it will only be “supported until further notice”) and, for on-premises, SharePoint Server 2013 (SP2013) will be the last release.
  2. They heavily promote, both before & during, a session at SPC14 entitled “Update on InfoPath and SharePoint Forms – SPC348″, during which four potential alternatives are introduced, of which FoSLs receive the most attention; we actually blogged about this in the immediate aftermath of SPC14.
  3. An InfoPath “funeral” is held at SPC14, and yet very little additional information is released after the conference regarding FoSLs
  4. Then suddenly late on a Friday afternoon (February 6, 2015) – because that’s a great time to get maximum exposure on a major announcement – rather than making a new post, an “Editor’s Note” is added to the original January, 2014 article concerning the end of InfoPath, simply noting “we are also updating the timelines for removal of InfoPath Forms Services components of SharePoint and SharePoint Online.”
  5. In parallel, and not mentioned within any related post during that time, the release of FoSLs on the O365 Roadmap is abruptly moved from “In development” to “Cancelled”, which is succinctly defined as “Previously planned updates that are no longer being developed or are indefinitely delayed.”

So 13+ months removed from the news that InfoPath would no longer be updated, Microsoft has giveth then taketh away the only fully web-based form customization tool (FoSLs) they had on their roadmap, maintained the removal of Design View in SharePoint Designer 2013 and then extended the life of InfoPath – though it’s noteworthy that they did not commit to a new release, only an extension of how long & on which platforms the old/last release will be supported. Hardly a strategy any CIO/CTO I know would want to bank on.

It’s here that platforms like CorasWorks provide critical value; our existing Actions framework is a mature capability set, with nearly a decade of evolution behind it. It easily supports customizing which fields appear on a form, the order of those fields, whether or not a field is required or read-only within that form instance, customizing the description or guidance for each field using HTML rich text, triggering Workflows and even executing external service/API calls upon form submission. As the browser landscape has improved – namely IE8, the last major browser to not support HTML5 & CSS3 falls to under 3% usage worldwide – CorasWorks now looks to add even more form customization features to include more options over how forms are laid out visually, leveraging the best free frameworks on the web.

We’ll continue to track this development and the potential impacts it has; but more importantly, we’ll also continue to grow & improve our platform to meet the evolving needs of the SharePoint ecosystem, InfoPath getting a last gasp notwithstanding!

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.

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.

Still using SharePoint 2010? Watch out for polyfills…

Pushing the boundaries of SharePoint is a daily exercise for us here at CorasWorks. When still working in SharePoint 2010 though, all too often, the real limiting factor in designing & building applications is the browser – or more specifically, the Document Mode enforced by the masterpage in SP2010:

<meta http-equiv="X-UA-Compatible" content="IE=8"/>

One way you’ll see some people or companies work around this is by adding polyfills; if you’re unfamiliar with the term, a polyfill is essentially a piece of code or script that ensures (or restores, depending on how you look at it) a piece of functionality the browser should natively support. You can read more about the term here.

A word of caution though; if you add a polyfill into your application, you run the risk of conflicting with the stock SharePoint JS. This is exactly what I observed recently when attempting to use the Modernizr.js and Less.js libraries – they broke the ability to add new web parts to any page. The error I was getting in my browser console pointed to a file named “WPAdder.js” and only stated:

Type mismatch.

My research led me to this blog post by Steve Ottenad, an excellent web designer based (ironically?) in Seattle, WA and not far from the Microsoft campus. His findings confirmed my suspicion and, as soon as the offending JS was removed, I was once again able to add web parts to a page.

One approach I considered, but eventually abandoned in favor of taking a different path altogether, was I could have wrapped my polyfill code inside a script block that only ran if my page was not in Edit Mode. But I didn’t trust SP & IE enough that some other issue wouldn’t crop up in the future.

And lest you think I didn’t consider addressing the “root problem”, there is no shortage of tips, tricks & workarounds for using SharePoint 2010 without the “IE=8″ meta tag – but they involve some pretty heady work around overriding stock SP JS files and modifying key server-side application pages for things like the People Picker. In other words, fodder for a future blog post ;-)

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.

JS Date functions not working in SharePoint with IE…?

Ever run into a problem where you have what you know to be valid javascript, trying to work with a Date object, and yet you keep getting JS errors in the console? If you’re working in SharePoint 2010 or older, blame Microsoft ;-)

Joking aside, even if you’re using the latest version of Internet Explorer, because of the meta tags present in the OOTB masterpages of the older versions of SharePoint, IE will load the page in an older Document Mode; IE8 Standards for SP2010 and Quirks for SP2007. You can always, of course, apply a different masterpage or customize the native ones, however you run the risk of encountering issues elsewhere – for example, remove the “IE8″ meta tag from an SP2010 masterpage (or just setting it to a newer version) causes myriad issues with controls like the People Picker, the RTF field, certain menu options in the Item Context Menu, etc.

If your organization’s timeline for upgrading to SP2013 is a long-term effort, consider allowing/enabling your users to run Firefox or Chrome (Chrome Frame was a nice alternative until it was retired at the end of 2013). I know, not the most ideal answer – but at least you can stop banging your head on your desk wondering why your perfectly valid JS for manipulating Dates keeps throwing errors in IE.

Triggering a SharePoint List View’s AJAX refresh with jQuery

With the release of SP2010, we were given snazzy new List View web parts that included a whole set of AJAX options:


And it wasn’t long after starting to use these that you may have decided you wanted to be able to trigger an AJAX refresh (Asynchronous update) through your own client-side script. This is great if you have other interactive elements on the screen that will result in the underlying data changing and you want to display them to the user without requiring a full page reload. Enter jQuery!

The easiest way to achieve this is to first enable the “Show Manual Refresh Button” – don’t worry, can easily hide the resulting button from your end users with this CSS snippet:

#ManualRefresh {display:none}

Then, whenever you want to trigger an AJAX refresh of the List View, just fire off this one line of jQ:


And the existing button (perhaps hidden by the above CSS) on the page will take it from there :)

SharePoint’s Edit in Datasheet broken? Try this!

Having to support multiple clients across a myriad of SharePoint flavors, I’ve had my share of issues with Datasheet mode. On any given week, I can find myself working across SharePoint 2013 (on-prem and in Office 365), SharePoint 2010 (Foundation & Server), SharePoint 2007 (WSS & MOSS) and even occasionally still, some SharePoint 2003. Couple that with installed versions of SharePoint Designer 2013, 2010 & 2007 plus a constant flow of Windows & Office updates (I’m currently running Win8 x64 + Office 2013 x64) and I seem to regularly encounter this:


As has been blogged numerous times elsewhere on the web, you can often fix this error by downloading & installing the “2007 Office System Driver: Data Connectivity Components” (sometimes referred to as the “Access Database Engine”) from Microsoft here:

However, all too often, I find that while installing the above allows me to then access Datasheet view, the result is a crippled version. Just some of the limitations I run into include:

  • The inability to drag & select more than one cell at a time
  • The inability to delete more than one row at a time
  • The inability to drag & move columns
  • The inability to resize columns
  • And perhaps the most limiting feature, the inability to drag the + icon in the bottom-right of a cell to auto-populate additional cells or rows

Fortunately, I found all the above (and probably more) problems are resolved with a second, less-discussed package. Also available for free from Microsoft, you’ll want to download & install the “Microsoft Office Access Runtime and Data Connectivity 2007 Service Pack 2″ from here:

My guess is some, if not all, of the necessary files & configuration changes included in these packages were originally part of the Office 2007 Suite installation; so when you upgraded your installation of Office (or your entire machine) to Office 2010 or 2013, and especially if you jumped to a 64-bit version of Office, said files were no longer being found by the browser when attempting to Edit in Datasheet. In my experience across an array of machines with varying Windows & Office versions, these two packages have always restored Datasheet mode – hope they help you!