Using VSNET 2013 and write TypeScript directly to any SharePoint via WebDAV

/

Disclaimer:  This is not the recommended workflow.  As a developer you should use VS.NET 2013 and build SharePoint projects.  You can then use TypeScript in your solution.

This is just a REALLY nice way to be super productive while working on Javascript in SharePoint.  Additionally, it works with Office 365, SharePoint 2007, 2010, 2013.  Does not require you to have a SharePoint development environment with Visual Studio .NET installed.

 

What do you need:

  • A windows machine, with Visual Studio .NET 2013 (TypeScript is better with VSNET 2013)
  • You don't need SharePoint installed in this machine.  You also don't need to have the VS.NET SharePoint extensions installed.
  • You need TypeScript though, grab it from: http://www.typescriptlang.org/#Download

 

Change your VS.NET settings:

We will be opening TypeScript and Javascript files directly from SharePoint via WebDAV.  These files are not part of a VSNET project.  So we need to flick on an option within VS.NET to automatically compile TypeScript files which are not part of a project

image

 

Open... TypeScript!

So now you can open TypeScript directly from File > Open

image
Figure: VS.NET Open File Dialog

 

And as you work in VS.NET and save the TypeScript file, the Javascript is generated and populated next to the TypeScript file on SharePoint.

image
Figure: SharePoint TypeScript and Javascript files kept in sync by VS.NET

Similarly, you can create new TypeScript files in VS.NET and save it to SharePoint.

Your master page references the Javascript file.  So you can go back to the pages that is using the new function and just F5 to refresh it and see the new results.

 

Why is this cool?

 

  • You can use VS.NET 2013 on your client machine, and use the latest version of TypeScript regardless of what SharePoint server you are talking to.  You aren't restricted by SharePoint 2010 and needing VS.NET 2010, or using VS.NET 2008 with SharePoint 2007.  You don't need SharePoint installed locally and you don't need to have the SharePoint extensions installed for VS.NET 2013.  As a consultant this is a life saver - I can now use TypeScript on old 2010/2007 environments.
  • You get the productivity of being able to save (in VS.NET), refresh (in browser) and immediately see changes in your Javascript.  You don't have to package / deploy / update-spsolution etc
  • You get all the benefits of TypeScript, including reference paths (as long as you put the definition files in SharePoint too, in a relative location).
  • When you are ready to package and deploy, take the TypeScript file out and put it into a proper SharePoint solution.

Introduce your drastic UI changes... slowly

/

 

We are in the middle of a somewhat sudden rebranding exercise.  One of the main colours that was used prominently in the previous theme of the website is now being retired as the UI is simplified.

 

So here is what we have right now:

image

 

And here is where we're going (currently in development).

image

 

Where's the Yellow?

 

In every case where we ask one of our existing users the first response is always: Where's the "Company Yellow"?

There's of course a marketing message that will go out with our latest release. 

But here's the secret developer compromise.

 

We can reduce the yellow, slowly, overtime

 

The old header background will remain.  But in the Javascript that's run on every page, we introduce a small piece of script that modifies the opacity of the background header.

var days = (new Date("2013-08-20") - new Date()) / (24*60*60*1000);  // remaining days until 2013-08-20
var opacity = (days > 0) ?  (0.5  * (days / 14)) : 0;   // starts from 0.5 opacity to 0
$(".header-banner").css("opacity", opacity);

What this does, is that over the course of two weeks, the yellow's opacity reduces from the original (50% at this next release) to 0%.  So as days go on, the yellow header begins to fade, and after two weeks, it will simply disappear!

I wonder what'd be the water cooler conversation.  Each person will wonder what happened to the yellow as it slowly faded out of our lives.

Australian SharePoint Conference 2013 Melbourne

/

Thank you attendees for yet another super conference.  It was quite a lot of fun presenting TypeScript for SharePoint.

 

I've got lots of feedback regarding the section on JavaScript - and have heard you guys loud and clear:

  • While the examples are fun...
  • But if you have other stuff to talk about, skip it!

I will miss talking about hoisting.  One of the craziest JavaScript gotchas there ever was.

 

VS.NET Extension

 

Downloads

Retrospective - Australian SharePoint Conference Sydney 2013

/

I had planned to post this as soon as I finish my session - but you know, conference.  Lots of friends come visit during these events and the evenings do a lot of damage to your hair, and possibly liver.  I don't often get opportunities to chat with so many SharePoint experts in such a short span of time.  Lots of catch up, lots of thoughts, A LOT of ideas.

 

As for my session, Building SharePoint Solutions with Microsoft's TypeScript: how and why.  I think it went well.  I really wanted to thank the audience for being so kind, and stayed awake through the presentation.  As promised, here is my presentation:

Presentation:

 

Downloads:

A huge thanks to the organisers, speakers, vendors and attendees for such a fantastic conference.  I hope to see you guys again soon.

InfoPath - reading template.xsd in code for type checking

/

InfoPath is the world's most advanced XML-based form system.  Each InfoPath document is a fully structured XML file, and the template contains the XSD schema definition for the XML file.  This includes a bunch of information such as min/max occurrences, as well as the type information for each of the elements.

Because the information for the element's type is stored separately in the xsd file, it isn't possible at runtime to workout what the type of each element is supposed to be. 
When we are given:

  • my:value1

If we can't read the template.xsd file, we don't know if that's a number, a string, a datetime nor do we know if the field is nillable.  Some fields in InfoPath, such as the boolean and the datetime fields, can't be blank.  They have to be set to nil.

 

Here's how you can read the template.xsd in code

An InfoPath Form

 

Here is an InfoPath form with a few fields

image

 

The XML File Connection

 

Add a XML File Data Connection to an existing file in the template, I use "template.xml"

image

Save the template, and now drop into the code behind.

 

Code

public void InternalStartup()
{
    EventManager.FormEvents.Loading += new LoadingEventHandler(FormEvents_Loading);
}

public void FormEvents_Loading(object sender, LoadingEventArgs e)
{
    FileQueryConnection file = this.DataConnections["template"] as FileQueryConnection;
    file.FileLocation = "template.xsd";
    file.Execute();
    XPathNavigator template = this.DataSources["template"].CreateNavigator();
    string notes = "";

    foreach (XPathNavigator nav in this.CreateNavigator().Select("//*", this.NamespaceManager))
    {
        string localname = nav.LocalName;

        XPathNavigator element = template.SelectSingleNode("//*[@name='" + localname + "']", template);
        if (element != null)
        {
            notes += string.Format("{0} is of type {1} {2}; ", localname, element.GetAttribute("type", ""), element.GetAttribute("nillable", ""));
        }
    }

    this.CreateNavigator().SelectSingleNode("/my:myFields/my:notes", this.NamespaceManager).SetValue(notes);
}

  • The interesting part is at the top, where we bait and switch the FileQueryConnection to read the template.xsd schema file instead.  Because it is a valid XML file, InfoPath will read it happily.
  • We can then map any field in the main datasource to the corresponding definition in the template, and pull out the additional metadata such as type or nillable.

 

Result

image

 

Download