Reading InfoPath template's default values in code

String xml = "";
FormTemplate template = this.Template;
using (Stream s = template.OpenFileFromPackage("template.xml"))
{
    XPathDocument reader = new XPathDocument(s);
    XPathNavigator nav = reader.CreateNavigator();
    XPathNavigator repeat = nav.SelectSingleNode("/my:myFields/my:Repeats/my:Repeat[1]", this.NamespaceManager);
    if (repeat == null)
    {
        return;
    }
    xml = tender.OuterXml;
}
if (!String.IsNullOrEmpty(xml))
{
    XPathNavigator destination = this.CreateNavigator().SelectSingleNode("/my:myFields/my:Repeats", this.NamespaceManager);
    destination.AppendChild(xml);
}

The top part of the code is particularly useful if you want to use the Default Values for repeating sections in InfoPath.  Your code will read the xml for the default values and insert them into the repeating section.  I've previously hardcoded these XML segments for insert, but that's extremely error prone when you inevitably update your XML template with new and more exciting child elements and attributes.

Wrap up: SharePoint Saturday Adelaide and Brisbane

There is always an relevant tweet.

Tomás Lázaro‏@tomzalt May 22 The book Javascript Ninja has a Samurai on the cover. That happens because JS is not strongly typed.

This is a Post-Event update post.

Adelaide

In Adelaide, I went at a good pace and gone through the TypeScript example, demos but had very little time remaining for discussions or questions.

The main feedback I got was perhaps there was too much time (still!) given to JavaScript and we can all spend more time in TypeScript and the demos.  Also, there was questions regarding deployment.

Brisbane

In Brisbane, I trimmed the JavaScript discussion but added a silly demo that got people laughing.  But possibly still ate my time.  I was not able to go through the sections on adding TypeScript to your existing JavaScript.  But I was able to cover the deployment scenarios for SharePoint 2010 and 2007.

Working with SP 2007

• Editing:
  • Use Content Editor webpart and point to a HTML file, which then references a JavaScript file generated from TypeScript.
  • Use VS.NET 2012/2013 with WebDAV
• Deploying:
  • Package as farm solution web part
  • Include map file to debug in IE12 / Chrome.

Working with SP 2010

• Editing
  • You can use Content Editor as above
  • You can build VS.NET farm or sandbox solutions and use TypeScript directly
• Deploying
  • Use Sandbox solution to deploy a sandbox webpart
  • Reference a JavaScript file generated from TypeScript
  • Package as sandbox solution

Deployment – SP 2013 / Office 365

• Using App for SharePoint to deploy an App Part
• Do not create code behind. Reference JavaScript file generated from TypeScript
• Configure App permissions
• Package as SharePoint “App”
• When deploying – grant permissions to App

Download Links:

• Presentation
• demo.zip file

If you are using TypeScript in your environment, let me know and tell me how it is going for you.

SP2010 Forcing previously deployed file to update to latest version in site definition

I’m a big fan of quickly making changes to my SharePoint JavaScript file in SharePoint Designer and then test whether they work correctly in the browser.  Quick browser refresh and I’m testing.

But I don’t recommend this on your test or production environments.  For those cases, you should package your JavaScript files into a solution and deploy them.

SharePoint 2013 ReplaceContent Attribute

SP2013 introduced a new attribute ReplaceContent=”True” http://msdn.microsoft.com/en-us/library/office/ms459213(v=office.15).aspx when this attribute is set to True, when your feature is activated it will replace existing files on SharePoint with the contents of the files from the package.  This attribute is excellent for deploying JavaScript files.

SharePoint 2010 IgnoreIfAlreadyExists Attribute

In SP2010, you aren’t as lucky.  The IgnoreIfAlreadyExist attribute needs to be set to true.  Otherwise your feature will most likely fail to activate if a file already exists.  This is troublesome because with the ignore flag on, your JavaScript files won’t update to the latest new version.

There are a few approaches that people take.  Some chooses to delete all the assets when deactivating the feature.  Then on reactivation, the assets are recreated brand new with the latest bits.  This works fine for CSS, JavaScript files, but will not work for MasterPage or PageLayout files that are in use.

Add Reset to Site Definition

I propose this fantastic method:

SPFile.RevertContentStream();

http://msdn.microsoft.com/en-us/library/office/microsoft.sharepoint.spfile.revertcontentstream(v=office.15).aspx

This forces the SPFile to revert back to the site definition.  Essentially this is what SharePoint Designer does when you click on

When I deploy to production, but I know I need to bump 2 of my JavaScript files to the latest site definition, I run this powershell.

PS D:\> $web = Get-SPWeb http://server
PS D:\> $file = $web.GetFile("Style Library/app/John/john1.js")
PS D:\> $file.CustomizedPageStatus
Uncustomized
PS D:\> $file.RevertContentStream()
PS D:\> $file = $web.GetFile("Style Library/app/John/john2.js")
PS D:\> $file.CustomizedPageStatus
Uncustomized
PS D:\> $file.RevertContentStream()

This works whether the file is Uncustomized (deployed via a previous package) or Customized (deployed manually or updated by a user).  After the method is run, the file content will be the latest version that was in the deployed WSP package.

Try it out.  Quite useful for fixing 1 JavaScript file in a package.

SharePoint Saturdays in Australia

I wanted write about two things.  I still wanted to do a summary of SharePoint Saturday Adelaide 2014, but I will have to do that later, perhaps combine my thoughts after Brisbane.  Right now, I wanted to talk about the upcoming SharePoint Saturday Brisbane 2014, as well as SharePoint events in general in Australia.

SharePoint Brisbane is May 31st

Will be upon us very soon in two weeks.  There’s a strong call for additional local speakers.  If you are in Brisbane – you really should consider presenting a topic.  It can be a simple topic.  If you feel you don’t have enough content, prepare for 30-40 minutes, and let your audience ask questions.  You’ll be surprised how quick a session is.

Attending a SharePoint Saturday

There are several great reasons to attend a SharePoint Saturday event:

• SharePoint Saturday events are free.  We will bribe you with food.  Additionally, there’s usually good sponsor prizes.
• You get to hear from your local knowledgeable SharePoint people, on a variety of topics that you can choose.  Sure, you can see them in the monthly user groups, but you don’t always get to choose the topic that’s presented at the user group.  SharePoint Saturday offers that choice.
• You get to network with your local SharePoint people.
• We understand and are thankful that you are sacrificing one day of your precious weekend to attend a training event.  Please don’t feel bad at all if you need to leave early, or can only visit for an hour after lunch.  It is still great to see you, so nice of you to make the trip.

Presenting at a SharePoint Saturday

Because there is a larger set of available spots in a SharePoint Saturday event.  There is a lot more room for local speakers to present. 

• Have you done a particularly cool project and want to talk about it? 
• Have you did a presentation in your company that you want to test with a wider audience? 
• Sure, not everyone will agree with your particular approach.  But that’s the best thing about SharePoint – there’s always more than one way to do things.  You way is superior already because you get the stage to explain it to your audience!
• The perfect springboard to learn what you preach.  It is true.  The best way you learn is if you can teach someone else.  I personally learned so much from talking about what I’m doing.  I stop and write this blog, because it helps me document and digest what I’m doing.  I write an event summary, because it wraps up my thoughts, preparation and the aftermath.
• The person that benefits the most from a SharePoint Saturday event, is the presenter.

Whether attending or presenting, I hope to see you at SharePoint Saturday in Brisbane, or in a SharePoint Saturday event in your city soon!

IE11 (+Win8.1.1) F12 Developer Tools for the SharePoint Dev

This blog post is about all the new nifty features I'm finding in the latest IE11 F12 developer tools.  I updated my Windows to 8.1 update 1, and IE11 was updated.  I started seeing a few cool new features, and went on Twitter to find the official documentation.

http://msdn.microsoft.com/en-us/library/ie/dn641599(v=vs.85).aspx

Was supplied by @AdamTReineke

https://twitter.com/AdamTReineke/status/454678702169677824

Rather than bore you with a list of features, which is on MSDN.  I want to just quickly share how I'm using some of them.

Disclaimer - I had just watched LEGO movie.  So EVERYTHING IS AWESOME!

DOM Explorer

1. CSS Changes

• When you "touch up" CSS in SharePoint to get the exact look you want.  You often forget which rule you had applied.
• The DOM Explorer's "Changes" tab tracks all the individual changes, and you can revert an individual rule, or copy them all and paste to your CSS file.
• Copy All.  Awesome!

2. Pseudo Rules

• You know those pesky :hover and :visited CSS rules in SharePoint that can never find to eliminate? 
• Now you can apply :hover or :visited and see the effect rule without actually trying to catch your mouse hovering.  Haha.  Awesome!

The super cool updated Console object

3. Console info, warning, error

• My "warnings" are currently filtered. 
• use console.info() console.warn() and console.error() to write to these.

• No ribbon button but you can right-click to filter Log messages too.  For those really spammy libraries, which is pretty awesome!

4. Console handles objects, multiple objects and HTML

• Chrome and Firefox both were able to log objects and inspect them.  IE11 used to just log the [object].tostring which was pretty useless.
• The update now fixes that, and allow multiple arguments to be logged at the same time.

5. Console always available for dev. 

• So you can have all your logs happening without trying to start the debugger before you load the page
• Remember your end users won't have this on, so TEST before you deploy code.

6. Console can switch target to an iFrame. 

• Note, I couldn't get this to work in IE8-Compat mode (which my SP2010 runs on).  This works fine for IE9, IE10, Edge.
• This is awesome for debugging objects in the SP.UI.Dialog

 

Debug

7. Debugger can be attached without reloading the page

• Not sure if we need a picture to describe how awesome this is.  I imagine the picture will involve unicorns, rainbows and kittens.  AWESOME!

8. Just My code

• Debugger only stops on my code.
• Note, some libraries can throw error when you call it wrong - so sometimes not so awesome.

9. Pretty Print

• Oh crap.  Something in sp.runtime.js don't know how to read this...

• Not anymore in 2014!
• Hit pretty-print - the sp.runtime.js becomes actually readable, and you can set line-based debugging too!

• I didn't switch to sp.runtime.debug.js - this is awesome!

10. Source Maps

• Now finally we have source map support.  Here is me debugging Typescript in IE11

Summary

• The developer story on IE11 (after this update) is awesome!