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() {
        $.slidebars();
    });

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.

Quick Tip – Shorthand Variable References in XSLT

Here’s a quick tip – next time you’re writing some XSL and want to include a variable within the attribute value of a node, don’t waste time & code doing something like this:

<xsl:variable name="VarName" select="SomeData"/>
...
<MyElement>
  <xsl:attribute name="AttrName">
    <xsl:value-of select="$VarName"/>
  </xsl:attribute>
</MyElement>

Instead, you can use this shorthand notation for referencing a variable directly within an element attribute:

<xsl:variable name="VarName" select="SomeData"/>
...
<MyElement AttrName="{$VarName}"/>

Enjoy!

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="//www.java.com/js/deployJava.js"></script>
    <script type="text/javascript">
        var attributes = {ID:'MyApplet',width:1000, height:700};
        var parameters = {
            jnlp_href: 'URL-to-JNLP-Service',
            java_status_events:true};
        deployJava.runApplet(attributes, parameters, '1.6');
    </script>
</div>

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

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

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

$(function() {
    KTMApplet.onLoad(function() {
        $('#LoadingContainer').hide();
        $('#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.

Center content with margin:0 auto

Working in SharePoint I almost expect, on a daily basis, to run into some annoying formatting issue due to an overly-generic CSS rule coming from the Core CSS that’s baked into the platform. Today I had a client trying to center some content (a cool News Rotator using the bxSlider jQuery plug-in, fed via the CorasWorks API) that was being loaded up via Content Editor Web Part (CEWP) but no matter what she did, she couldn’t get the CEWP to center within its parent Web Part Zone.

I then shared a handy CSS trick I picked up along the way; this can be used on any block-level element you want to center within its parent when you have a fixed width applied.
margin:0 auto

Using Firebug, it was clear to the customer that the parent DIV containing the Rotator was filling the horizontal space, but applying a “text-align:center” just resulted in the text within the Rotator items getting centered, not in centering the Rotator itself within its parent DIV.

I looked, saw the fixed width on the Rotator and knew right away that a “margin:0 auto” was all we needed – and voilà, another happy CorasWorks customer!

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:

DatasheetView-Error

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: http://www.microsoft.com/en-us/download/details.aspx?id=23734

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: http://www.microsoft.com/en-us/download/details.aspx?id=7020

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!

XSLT 2.0 – Even More on Dates

Recently, I needed to get the minimum and maximum dates from a SharePoint Task list. With XSLT 1.0, you typically accomplish this by iterating over your rows and sorting them in the order you want, then grabbing the first or last value to get the min or max date you want.  This can get cumbersome when you need to do this on more than a couple of fields.

So I took advantage of the opportunity to see what XSLT 2.0 had to offer.  Sure enough there is a min() and max() function and they work just like you would expect them to.

Using a Task list as an example, we can quickly find minimum start and maximum due dates for the entire set of tasks with two lines of XSL applied to our raw CAPS output.

<MinStartDate>

<xsl:value-of select=” min(NewDataSet/Tasks/cw:listitems/rs:data/z:row/@ows_StartDate/xs:dateTime(.))”/>

</MinStartDate>

<MaxDueDate>

<xsl:value-of select=” max(NewDataSet/Tasks/cw:listitems/rs:data/z:row/@ows_DueDate/xs:dateTime(.))”/>

</MaxDueDate>

We have to append our selected node with “/xs:dateTime(.)” so that the XSLT 2.0 engine will compare values as dates and not strings.

You will also want to make sure that you are including “<DateInUtc>TRUE</DateInUtc>” in the CAML of your CAPS call as well.

If you need to refresh your memory about working with dates in xslt 2.0 and CAPS here are our two prior blogs covering formatting and doing calculations.

SharePoint Conference 2014 aftermath – Customizing Forms

As a blog primarily focused on the technical aspects of building applications in SharePoint, I won’t drone on about the far-reaching impacts of “The End of the InfoPath Era” – this was already announced in the weeks leading up this year’s SharePoint Conference, and then (sort of, but more on that later) given more clarity during the Conference itself. In short, although end-of-life support for InfoPath will extend until 2023, last year’s release will remain the final one to include any new features or functionality, while fixes & patches will be at the pace you’d expect from a Microsoft product on its way to sunset.

Sitting in the room at SPC14 with hundreds of my fellow SharePoint developers, users & executives, I got a first-hand glimpse of what Microsoft sees as its path, or really paths, forward. We knew Microsoft meant business when the session was given a primo time slot & 3 Microsoft employees to present; in the end, what we got was a scatter shot of four possible options for replacing custom InfoPath forms:

  1. Using Excel Surveys, an apparently little known feature for creating custom forms directly inside an Excel document & that write to a worksheet therein.
  2. Using a new, yet to be released “Forms Over SharePoint Lists” web-based designer for creating custom forms in SharePoint 2013 (and yes, that acronym is FOSL, pronounced ‘fossil’ by the MS reps themselves – insert irony joke here).
  3. Possibly using Word for structured document forms – this I say “possibly” because MS committed only to providing a roadmap for this option by the end of 2014; no actual product yet.
  4. Using Access Apps, which if you used them in SP2010, seem reminiscent of the Office Business Apps (OBAs) that were touted then.

With such a wide range of choices, and comparatively little guidance on when to use which & where, I couldn’t help but think the flexibility & power of the CorasWorks Actions Framework provides a much-needed alternative. In the coming months, I suspect more vendors will try to fill the “custom forms” gap with new products – but we’ve been building apps with & improving our Actions Framework, including our web-based designer (the Actions Wizard) for more than 8 years now; this is a feature set CorasWorks knows well!

And as an architect that’s designed & implemented 100+ custom applications on SharePoint, I also know just creating a custom form a solution does not make; what if you want to apply a custom form to more than one list, across multiple sites, site collections or web apps, with a single centralized definition – none of the MS approaches facilitate this, while the CorasWorks platform has for years. Or how about custom forms that are exposed depending on the current values or stage an item is in, can trigger Workflows anywhere in the SharePoint farm, or are security trimmed based on the currently logged in user? All core features of the CorasWorks Actions.

Plus, in the coming months, while others are just starting to explore the world of InfoPath alternatives, CorasWorks will be expanding our Action framework further to include integration with other data sources & providing greater flexibility & customizability in the form UI.

So while the InfoPath announcement and SPC14 have put the topic of custom forms for SharePoint at the forefront, CorasWorks has been building & improving our platform – which includes this key feature – since the SharePoint 2003 days.

Enable Logging in CorasWorks v11

The CorasWorks v11 platform adds a wide range of capabilities into the application builders toolbox – and as every good builder & developer knows, sometimes the best way to track down any issues that may arise is by getting the server to log the details of what it’s doing behind the scenes.

Just like native SharePoint has a wide range of logging & debugging options, so does CorasWorks v11. Beyond all the built-in client side tools (putting web parts in debug mode, Wizards that guide you through proper configuration, intelligent CAPS error responses, etc), you can also enable server-side logging. Doing so will enable key pieces within the CorasWorks framework to write logging events into a special CorasWorks Application log that’s then accessible via Event Viewer on the web server.

NOTE: Because the event logging provided is rather verbose, we do not recommend leaving event logging enabled permanently, and use of it within Production environments may impact performance, so plan accordingly.

Here’s how it’s done…

  1. Browse to this location on each (and every) WFE in your farm: “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\XX\Resources” where ‘XX‘ represents the hive for the version of SharePoint you’re running (12=SP2007, 14=SP2010 & 15=SP2013)
  2. Within that folder, locate the following two RESX files: “CorasWorks.Workplace.Data.Engine.Resources.resx” & “CorasWorks.Workplace.Data.Engine.Resources.en-US.resx”
  3. Search the files for the following tag; in most cases, it should be near the end of the page: <data name=”LogEvents” xml:space=”preserve”>
  4. Set the <value> node to True:
    LogSetting
  5. Repeat steps 3 & 4 for both RESX files on all your WFEs, performing an IIS Reset on each box after you’ve updated both files
  6. Finally, repeat the test or behavior you were hoping to troubleshoot, then open the Event Viewer on the WFE and browse the CorasWorks Application log for details on what’s happening behind the scenes

Again, once you’ve resolved your issue, you want to be sure you set the “LogEvents” property back to False – but now you know yet another way CorasWorks makes it quicker & easier to build (and because no one is perfect, also troubleshoot) your applications in SharePoint.

Resolving Errors when saving Sites as Templates in SharePoint 2010

For all the improvements and updates introduced with the SharePoint 2010 release, there’s at least one segment of the platform that got harder to work with – saving sites as templates. Debates rage about whether and to what extent people should even use SharePoint site templates as a deployment mechanism (vs say Features) but if you found your way here, you’ve likely already made that decision and just need some tips on resolving some of the common errors we here at CorasWorks ran into when SharePoint 2010 was first released. Hope these help!

Error #1

“Error exporting the list named “YourList” at the URL: Lists/YourListURL

When getting this error, the name of the list is almost always the first list (in alphabetical order) within your site, and you’ll likely see an error screen like this:List Export Error

The error is often the result of the default content types not being present/enabled within the Site Collection you’re working in. A quick pair of PowerShell commands though and you can get them redeployed fairly quickly.

First, fully disable them:
Disable-SPFeature –Identity ctypes –url http://SiteCollection

Then, enable them anew:
Enable-SPFeature –Identity ctypes –url http://SiteCollection

Now you’re back in business; go ahead and try to save your site as a template again. If you get a new error however, read on…

Error #2

“The attachments column does not exist for list Id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, list name YourList

In this case, a generic error is displayed in the UI and the above message is found in the logs using the Correlation ID of the error.

Usually related to error #1 above, this error indicates the default Site Columns are missing and thus SharePoint is unable to build a functional Site Template. And just like above, a short pair of PowerShell commands are all you need to get said Site Columns redeployed.

Again, first disable them completely:
Disable-SPFeature –Identity fields –url http://SiteCollection

And then re-enable them:
Enable-SPFeature –Identity fields –url http://SiteCollection

References

Using IE 11? We Need a Patch!

If you’re running Internet Explorer 11, you may have noticed that your SharePoint environment isn’t responding in the way you have come to expect.  It turns out…wait a moment!  Didn’t we just write this a few months ago?

Last June we wrote an article entitled “Using IE10? You Need This Patch.”  In the article, we told how there are updates for .NET to provide compatibility for SharePoint with the IE10 browser.  It turns out that the browser definition file controlling how the environment interacted with the browser stopped at IE9.

As a result, SharePoint treated the IE10 browser as if it was IE6 and prevented SharePoint (along with CorasWorks v11) from operating in a modern manner.  There were a pair of hot fixes supplied updating .NET to account for newer browser types.  Once the .NET update was installed, SharePoint could supply to the browser the appropriate script files.

This worked well, until IE11 was released within Windows 8.1.  IE11 users are noticing that SharePoint is treating their browser like IE6 again.  For example, multiline text columns are missing their editing toolbar.  As before, the issue again is with SharePoint not recognizing this browser type.  Although the results are the same, the reason for this behavior is different.

With the IE11 release, Microsoft has changed the formatting of the browser’s user agent.  In short, the user agent is used by the web server to determine what type of browser it is working with.  Unfortunately, SharePoint (more specifically .NET 4) cannot understand the changed format of IE11’s user agent and treats the browser as if it was an old browser.  This blog entry has a partial listing of what users are seeing.

In the long run, the updating of the user agent format is a positive step.  In the short term, we appear to be waiting for Microsoft to issue another .NET patch to accommodate IE11.  To work around this limitation, enable compatibility mode for IE11.  Entering into compatibility mode is tougher than in the past, though.  This blog entry from Windows IT Pro explains how to enable it for IE11.