Exciting news this week as Office Dev center has released the first release candidate version for SharePoint Framework.
There comes a time in every developer's life to make the decision whether or not a piece of software is "good enough" for public consumption. However, I've come to the realization that SPAnyForm-lite will never truly be finished, as it will continue to evolve over time. So here it is!
Okay, I said earlier, in part 3, that Search represents the most significant change to information architecture design in forever. I still stand by that statement but one of the most transformative elements of modern Intranets is a new approach to SharePoint customizations. It used to be your I.T. department would tweak the Intranet to include anything from tailor font styles to omelet making apps. But administrators and business managers became reluctant to implement these customizations because they made upgrades and maintenance cumbersome and weren’t focused on productivity.
Recently I had been working on a SharePoint Hosted App with custom lists created in Visual Studio. On one of my application pages I had a need for an XSLTListViewWebPart and found out the web part was missing the "Add New" button! So where'd it go?
While developing a SharePoint Provider-hosted app, chances are you have come across this error " Error occurred in deployment step 'Install app for SharePoint': The remote server returned an unexpected response: (405) Method Not Allowed." At first you probably think, oh the deployment was just a little tempermental... I'll try it again. Come to find out, it happens over and over and over again. Luckily, the problem isn't all that complicated.
For a while now I've been meaning to write a blog post about the SharePoint Image field. For those who don't know, without publishing turned on, the only way to add an image to an item in SharePoint is by using the Image field. However the name can be a bit misconceiving for someone who hasn't used it before... because it really just holds the url to an image and displays the image when in a SharePoint view. My gripe with the Image field isn't with how it renders an image but why SharePoint didn't provide a way to search for an image to add to an item like they did for the "Publishing Image Field". The only way to connect an image to an item without publishing is to find the URL of an item and past it into the Image URL field. Well what happens if the image isn't in SharePoint yet and you want to upload an image and add it to a library at the same time? Well, that is exactly what you have to do. You must go to the Image library and add your image and then traverse back to the list item for which you wanted to add link that image. Well I have come up with a solution to this scenario.
I’ve been working on a SharePoint hosted app that requires a daily workflow to run to count the number of vacant and occupied homes in each building and create a list item for each day. From there we can use this data to create occupancy charts and graphs with chartJS or Power BI but first thing’s first, I needed to write a workflow that will get me this data in a list called Occupancy Data.
So far we’ve covered what the SharePoint App Model is and why it exists, the pros and cons of the “App Model” and the different way to authenticate using SharePoint Apps. In this part of my SharePoint App series, I’m going to be talking to you about the three different ways we can develop SharePoint Apps.
We can build SharePoint Apps in different shapes and sizes. The three different “shapes” a SharePoint App can take are Full Page, App Parts and Custom UI Actions.
In my last post, I discussed the introduction into SharePoint App development and why I think it’s important for SharePoint & Office 365 going forward. Any technology stack can hold a fair amount of criticism and while some may not fully accept the SharePoint App model right now, remember that SharePoint is a rapidly expanding framework and I think we’ll start to see advancements in the “App Model” going forward.
What’s the big deal with SharePoint Apps?
Microsoft made a bold move trying to implement a new development paradigm in SharePoint 2013. Microsoft has introduced the “App Model” in SharePoint 2013. It’s been well over a year since it has been introduced and it was pushed out with much skepticism from high end technology leaders and SharePoint developers alike. I’d like to express my passion for SharePoint apps and why I think the future looks bright for them.
If SharePoint development isn’t new to you, then you are very familiar with farm solutions. For years, developers have been deploying SharePoint solutions “WSPs” into environments in 2007, and 2010. A WSP is essentially a CAB file that contains a set of features, site definitions and assemblies that get deployed into your SharePoint environment. In a “full trust” wsp, the assemblies and files in the WSP will actually run on SharePoint web front end. This has been the standard and best practice way to deploy custom code into your SharePoint environments…at least until SharePoint 2013.
Topics: SharePoint Apps