Rename multiple files in Office 365 via Silverlight Client Object Model

 

One of the first Silverlight "tools" I build for SharePoint 2010 was a tool to rename multiple files in a SharePoint document library with regular expression find/replace, via the client object model. 

This is a successful test run with Office 365, without modification.

This is also the installation / user guide - XAP file is at the end of the blog post.

 

Upload Silverlight XAP file

image

1. Upload the xap file to SharePoint. 

 

image

2. Save.

 

image

3. Copy the shortcut to the xap file, for me this is:

/TeamSite/Documents/DocRename.xap

 

Add Web Part

 

image

4. Edit the current page - I'm inserting the webpart directly above the list

 

image

5. Add to the webpart zone

 

image

6. The Office 365 Web Part Adder is a lot prettier.  Select the Silverlight Web Part

 

image

7. Configure the Silverlight webpart.

 

image

8. Give it the path to my XAP file

 

image

9. Set a minimum height

 

image

10. Stop editing page (save)

 

Run it!

 

image

11. The webpart should load now - the find/replace is done via Regular Expression.  Here I'm matching anything named (.*)\.htm and changing it to the html suffix, while retaining the file name.

 

image

12. Results

 

image

13. Files renamed.

 

Summary:

Important notes

  • The Silverlight component picks up the list on the current page
  • You can also set the list name via Silverlight InitParam property
  • The replacement rule is this that - if there is already a file with the name you are placing, it will skip.  It will NOT overwrite.
  • The webpart doesn't refresh the list after running, so you need to hit F5
  • Finally, the Ribbon is contextual and you may find that since there is an extra webpart on the page, your normal List ribbons don't appear unless you focus on the list webpart.  If you can't stand this anymore (I can never last more than a few minutes), remove the Silverlight webpart or add it to a different page Smile
  • Here it is, have fun!  https://static1.squarespace.com/static/5527bff2e4b0b430660b0d10/5527c30de4b030eeeef09715/5527c30fe4b030eeeef0a162/1304422652343/DocRename.xap

Rich or Reach, pick one

Martin Fowler's latest article on CrossPlatformMobile is a great read, he argues based on history with Java and Smalltalk, that the best solution for Cross Platform Mobile solutions is the web, with caveats: 

  • Don't use cross-platform toolkits
  • For maximum reach: built a web app that looks like web app
  • To appeal to a particular platform: build a native app for that platform, with a experience design based on that platforms interaction style

I agree in part, but strongly disagree with the first conclusion.

 

The need

There are lots of difference devices, there are more coming, if we can write once and run it everywhere it would surely save us a lot of time and effort.  Let's look at our options:

  • Cross platform toolkits, such as Adobe Packager, or .NET Silverlight with Monotouch
  • A web application

 

History with Java

Of course, whenever anyone says "Write Once Run Everywhere", the most famous example that comes to mind would be Java.  Java indeed suffered from having mixed minds about what to do with the UI - do we ignore platform differences and go with our own standard UI (Swing), which doesn't behave the way users expect.  Or do we go with platform specific UI (AWT) but on different platforms the behaviour is different?

I would probably argue that in the days of Java - there was a strong community sentiment to go with Swing, to believe in the write-once run-everywhere model.  Even to the point of disregarding the user's experience.  This probably is the biggest downfall in why Java's UI was never really accepted.

If you were writing a rich desktop application today, and for some reason choose to use Java, I would argue that you stick to a well defined MVC design and make sure you have a great UI for the platforms that are important to you.  E.g. Windows, and Mac.

 

MVC or MVP

I briefly mentions MVC or MVP, which ever design you follow, the teaching is the same.  The View is interchangeable.  One assumes that a significant part of a Rich application is the underlying model and the logic, these are not UI focused and are completely interchangeable.

If you are at a point where it is important for you to have a great amount of User Experience, then I'd argue that you spend the time customizing the View specific to that platform, and not waste more time stuffing around with the model or presenter logic that you already have.

 

What would EA (Electronic Arts) Do?

Supporting rich applications cross platform on a massive scale is not a new problem.  It is not even an unexplored territory.  Nor is it specifically difficult.  This is a problem that is already solved in the electronic gaming world.  How does EA publish a game simultaneously for Play Station 3, XBox 360, PC and perhaps even the Wii at the same time?  Yes there are different teams customizing each individual experience, but the majority of the work is built on a common platform that they have created over the years.

 

The problem with the Web as a platform

There is only one problem with the web as the platform.  It is absolutely the lowest common denominator.  If you are picking the web, you have to ask yourself OK, is my goal here to produce something that "works OK" for as many devices as possible.  Or is my goal here to create a custom specialized experience on two or three specific platforms.

Martin raises the problems of Web in terms of lacking API support, here are a few more issues:

  • Uncertain Offline Support
  • Unstable Web Socket support
  • No Camera access, pipeline, image or video
  • No API for communicating with other applications on the device
  • No API for communicating with on device facilities such as contacts, lists, calendar or local library
  • No background thread capability
  • No bluetooth device support (or USB)
  • But no Accelerometer, compass
  • Immature UI controls
  • Simple UI data binding
  • No control over browser caching
  • No 3D graphics acceleration capabilities
  • Encryption capabilities (DRM)

Some good points:

  • CSS is an excellent UI skinning capability
  • DOM is well understood
  • Support for video and sound playback are decent
  • Most mobile browsers provides Geo location information.  But this isn't guaranteed on every mobile device.

 

And of course, we all have to choose

Yes I suppose if you have to pick a platform, the web is at least on the radar

But we are looking at an API model that is really still a few years behind most leading rich API's, on any platforms that you look: iOS, MacOS, Windows, Andriod and even the Windows Phone

So, my choices for cross platform comes down to:

  1. Rich - build specific user experiences, but share a common backend logic
  2. Reach - build a good enough application without most of the bells and whistles

Still can't decide?  Ok try this litmus test with some of the world's best web applications

  • Most platforms have a rich application for Facebook.  Do you use the rich application, or do you use the Facebook mobile web?  Do you only use the mobile web because it has a feature that isn't included in the Facebook rich app?  Do you expect that eventually that feature will be implemented on the rich app?
  • Most platforms have a rich application for email, which allows you to connect to GMail, do you ever use the GMail web application on your mobile device?

 

I don't know how I will choose.  I think it comes down to a balance between what devices you need to support as well as how much budget you have, vs. whether you think it's worthwhile to give your users a crap experience (vs. perhaps no experience at all).

 

image

 

So, Rich or Reach, pick one.  I think there's a strong argument to pick a cross-platform toolkit.  Let me know what you think.

Line break in InfoPath web browser forms

Microsoft once mentioned a line break trick using rules in InfoPath.

http://blogs.msdn.com/b/infopath/archive/2005/03/04/385577.aspx

The main problem we're trying to dodge is being able to insert a special character 
 (which is the chr(10) character), without InfoPath trying to be helpful and further encode our string.

image

Step 1: Create XML file

image

Step 2: Add secondary connection

image

Step 3: check it's now available in your secondary datasource

image

image

Step 4: when you need a newline character, insert it from the XML file.

Step 5: In InfoPath, you need to use the Textbox control, and enable multi-line.

 

Preview

image

Figure: Preview in InfoPath Filler

 

If you publish to web, it will use a TextArea element, which supports the line break.

image

Figure: Via Form Server

image

Figure: Textbox rendered as textarea element

Notes

You can set the textbox to read-only if you want to use it like a label.

Script and Link in SharePoint CQWP XSL Style Sheet

Help!  I added some script and link tags to my XSL style sheet for my Content Query Web Part, and now SharePoint has stopped working!

 

Problem

The main problem is not very obvious, but it's basically that SharePoint is spitting out incorrect HTML, that your browser can't render - so your browser starts guessing what the page should look like.  And since SharePoint 2010 relies heavily on javascript based client side objects, the ribbons, actions, web part zones all start to collapse once the page itself isn't rendering correctly.

When you type in an XSL (XML) file:

<script src="/Style Library/js/myscript.js" ></script>

SharePoint processes this as correct XML, but then proceeds to output:

<script src="/Style Library/js/myscript.js" />

Which is also correct XML, but is incorrect HTML!

The same happens for a link to CSS

<link rel="stypesheet" href="/Style Library/css/mycss.css" ></link> becomes <link rel="stypesheet" href="/Style Library/css/mycss.css" />

 

You wanted:

<script></script>
<script></script>
<link></link>
<div class="mycss">
</div>

SharePoint produced:

<script />
<script />
<link />
<div class="mycss">
</div>

Your browser doesn't understand <script />, so it begins guessing what the page should look like:
<script>
<script>
<link>
<div class="mycss"></div>

Result:

The DOM has just blown up.

 

Fix

When in doubt, always use the <xsl:value-of> in your XSL

<xsl:value-of disable-output-escaping="yes" 
select="string('&lt;link rel=&quot;stylesheet&quot; href=&quot;/Style Library/mycss.css&quot;&gt;&lt;/link&gt;')" /> <xsl:value-of disable-output-escaping="yes"
select="string('&lt;script src=&quot;/Style Library/myscript.js&quot;&gt;&lt;/script&gt;')" />
You will need to escape the characters " [&quot;]  < [&lt;] and > [&gt;]
 

SharePoint 2010 loads hidden Silverlight?

A while back we had an email conversation where there was a Silverlight plugin crash on one of our publishing pages, this happens occasionally while running on Chrome, except we weren't using Silverlight on that page.

This is something you should check.  If you are using the Content Query Web Part, chances are it is placing a Silverlight control hidden on your webpage, even if you are not using it.

image

Figure: Firebug picked up the Silverlight object

The way to confirm this is to check your Content Query Web Part, the "Play media links in browser" is a new feature in SharePoint 2010.  If your content query webpart was showing data from a media library, you can play the movie files directly within the browser, via the hidden Silverlight media player.

image

FIgure: Content Query properties - Play media links in browser

You can also turn this off in your .webpart file

image

Figure: Webpart file property - PlayMediaInBrowser