Saturday, August 13, 2011

Office 365 development

I am a bit excited about office 365.

My company (Extelligent Design) is now a 365 partner, and we aim to support clients implementing it. We want to help people set it up, understand how to use it (my book may come in handy, seeing as the end user interface to the sharepoint online is the same as regular sharepoint) and customise it.

Customising is where the real challange begins. As you probably know, to develop for office 365, you can only use the sandbox - which limits what you can achieve in your customisations. I find that not being able to install application pages (pages that go to the _layouts folder) especially frustrating, and, like a fish out of the water for the first time in its life, I suddenly realise how much I tend to rely on having that resource.

Ok, maybe the fish analogy is a bit much. I can still write web parts, and features with event receivers - not to mention list and library event receivers as well! But this is when I hit another wall - a lot of code I wrote in the past relied on me being able to run sections of the code with elevated privilages. This is gone if you develop a sandbox solution, and is very frustrating. Some obvious things that people will want to do in their hosted sharepoint site rely on code being able to run as other users. Workflows are a great example - having a user with permissions on list A enter data into that list, and then the workflow enters data into another list to which the user does not have permissions. Oh, wait, workflows are also not allowed in hosted sharepoint, so replace the word "workflow" with "event receiver" in the sentance above and you still get the same functionality, and you still hit a wall with not being able to write code that implements that requirement.

PS - the security limitation is blocked for both usual methods of running in elevated privilages mode - you cannot use the security namespace (preveting you from using SPSecurity.RunWithElevatedPrivilages) and you cannot use the SPSite constructore - preventing you from loading a new SPSite object with the system user's token.

So where does this leave us? Not all is doom and gloom - we can still write web parts and event handlers and features - as long as they are not too complex. This is great for deploying look and feel, features that implement site templates and more. I see a lot of developers now focusing on creating turn-key solutions that implement industry-specific templates for sites. Small businesses have a lot in common, and they are the real target of office 365 - so anyone who comes up with a feature that creates lists and libraries that solve a common problem for a small business may hit a jackpot similar to the mobile phone app developers.

Finally, hosting companies that host office 365 may let you deploy code to the servers directly, allowing non-sandbox development to take place. I think this will be hardest to do, since those companies will be very afraid to change their environment from the microsoft default, but a strong partnership with such a company may be a great thing for a sharepoint developer. Come to think of it- if you ARE a hosting company that office 365 hosting and you want some value add to your clients - talk to me!

No comments: