Archive

Archive for May, 2016

MVC Binding to Child Objects in a View Model

Hi There

Quick post to talk about MVC binding which can seem like magic at times.

If you use MVC out of the box and get Visual Studio to create your views for you it all just seems to work, its only when you start using View Models that you have to write your own views for that it all seems to fall apart.

I’ve been doing a lot of this lately and there’s a few simple rules to bear in mind that help a lot.

If the bit of data does NOT end up on the page in a HTML field then its not coming back in the posted model.

  1. There is no magic (or ‘state’) if its not on that page then it cannot be passed back to you.
  2. If you need that bit of data make sure you put it on the page.
  3. It has to held in a HTML field, text won’t cut it, no matter how you mark it up.
  4. Use EditorFor if its editable.
  5. If its not editable but it must be passed back use HiddenFor, this is really only for primary keys though.
  6. If you are not going to use the changed value then don’t pass it back just use DisplayFor.

That’s it, except for collections, here the critical thing to bear in mind is that the MVC binders use numbered fields to rebuild the collection so you must use the following construct:

       

Lists

                    @*Must use for rather than foreach for default binding to work *@
@for (var i = 0; i
{

}

@Html.LabelFor(model => model.Lists.First().Title) @Html.LabelFor(model => model.Lists.First().WebRelativeUrl) @Html.LabelFor(model => model.Lists.First().IsIncluded)
@Html.HiddenFor(model => model.Lists[i].Title)
@Html.DisplayFor(model => model.Lists[i].Title)
@Html.HiddenFor(model => model.Lists[i].WebRelativeUrl)
@Html.DisplayFor(model => model.Lists[i].WebRelativeUrl)
@Html.EditorFor(model => model.Lists[i].IsIncluded)

</div>

The key is @for (var i = 0; i < Model.Lists.Count; i++) which allows us to use model.Lists[i].Title and thus the default binder will realise its a connection.
You must NOT use @foreach (var list in Model.Lists) e ven though this feels more ‘with it’ as it prevents the binder from realising that it is a list.
Cheers
Sebastian
Categories: Uncategorized

Bulk Update Custom User profile Properties in SharePoint Online

Hi Folks

Just a quick heads up on new functionality in SharePoint Online for doing fast update of user profile properties:

http://dev.office.com/blogs/introduction-to-bulk-upa-custom-profile-properties-update-api

Read more…

Categories: Uncategorized

SharePoint 2016 Deployment – Planning

Hi There

Well after a weeks reading, and messing about in Azure, I have found out the following:

  • AutoSPInstaller has added support for SharePoint 2016 and it also has an online version AutoSPInstaller Online.
  • Server roles are available allowing ‘easy’ farm configuration but also for our purposes there is a Single-Server Farm mode that is suitable for development and testing.  However we will have to install SQL Server ourselves and configure the whole farm.
  • There is no longer a ‘free’ version, i.e. Foundation.  I guess this is because you can get ‘cheap’ Office 365 licenses and that is what Microsoft would prefer you use.
  • The minimum server farm is now really four Min Role servers and a SQL Server as opposed to a server and a SQL Server.  Five machines instead of two.
  • The minimum resilient server farm is now none SharePoint servers and two SQL Servers as opposed to two SharePoint servers and two SQL Servers.  Eleven machines instead of four.
  • The minimum specifications for the hardware and software are here Hardware and software requirements for SharePoint Server 2016.
  • A domain is critical and Azure Active Domains are not ‘AD’ for the purposes of domain accounts.  We are going to need to create a domain.
  • There is now Desired State Configuration available in Azure which allows us to define the state we want an Azure VM to end up in when we build it.

So it looks like the practical solution will be a virtual Azure machine based on the right SQL Server and Windows with a domain controller.

Right now I need a deployment plan, this is a simple document that can be handed to a competent person to build a SharePoint farm from, automated as much as possible.

The next post will be this document.

Cheers

Sebastian

SharePoint 2016 Deployment – Research

Hi Folks

“Go fast and break things” is one way of approaching a project “Leave no stone unturned” is another.  Being Agile, see the various posts on this blog, lets Respond to Change (in our case going from no SharePoint 2016 experience to some SharePoint 2016 experience by ding some research before we start.

Read more…

Categories: Uncategorized

Agile SharePoint Development – Using Visual Studio Online

Hi There Folks

Continuing on the theme of Agile development, specifically setting up SharePoint 2016 using Agile methodologies I thought it was time to talk about some of the tools I use.

First out of the gate is Visual Studio Online.

Read more…

Agile SharePoint Developement – Building a Farm

Hi There

So the first case study in Agile SharePoint Development will be, to celebrate the release of SharePoint 2016:

Build a SharePoint 2016 Farm with Multiple Tenancies and ADFS

Read more…

Agile SharePoint Development – SharePoint

Finally we get to SharePoint having covered Agile SharePoint Development – Agile and Agile SharePoint Development – Development.

So how does agile development in SharePoint differ from that in other languages and environments?

It doesn’t because, and here lets refer back to the Agile Manifesto once more, Agile is not about the how, what, where, when or who its about the why.  Use whatever techniques you like Sprints, SCRUM, pair programming, test driven design, continuous integration or deployment, the list goes on just know why you are using and be able to explain why you chose the techniques you did and be ready to change them if they are no longer appropriate.

Having said that experience shows that some techniques work much better than others and some techniques for SharePoint development lend themselves to Agile working whilst some don’t.

A Place to Stand

One thing is absolutely vital though you must have somewhere to work, and that needs a copy of SharePoint that will not impact end users.  You don’t expect a car mechanic to put snow chains on your tires whilst you are driving the car.

So your developers need a place to work where it won’t affect other people.  There are multiple ways of doing this and some are more applicable than others generally but we are being agile so be prepared to evaluate and choose what is right for you, now.

  • A dedicated SharePoint Farm or Tenancy, the ‘ideal’ solution but potentially expensive in license and ownership costs.
  • A dedicated Web Application, one of the few good reasons for a Web Application and On Premises only.
  • A dedicated Site Collection, very often the pragmatic solution but some things like Managed Metadata span all Site Collections.
  • A dedicated Site, not to be dismissed out of hand especially when doing small ‘tactical’ developments as you get a ‘real’ environment.

Some Decent Tools

If the work is serious you don’t do it in your front drive but you take it to a repair shop where they have the serious equipment, car hoists, engine block and tackle, etc.  I can write you a custom SharePoint Add In with nothing but notepad; the command line c# compiler and a Diamond Directive File command line packager but it will take a long time compared to working in Visual Studio.

As opposed to environments there really is only a single sensible choice for your main development tool almost irrespective of what you are developing and that is Visual Studio but there are some extras that can greatly enhance your developers’ productivity and, Agile again, there are some styles of development where other tools can be a better choice (JavaScript injection to implement Angular drawing from REST springs to mind).

  • Visual Studio Enterprise Edition, although pretty much any version will do.
  • ReSharper
  • XUnit

Known Techniques

You don’t need to reinvent the wheel every time so use tried and tested techniques, there are some that work very well with Agile and SharePoint and others that don’t.

  • Sprints, almost a given, they focus the mind so well and keep things manageable.
  • SCRUMs, not absolutely necessary and often hard to get business buy in but if you can do them they work very well.
  • Pair Programming, definitely worth it, the quality increase is startling.
  • Unit Testing, works well but beware mocking SharePoint objects for that way madness lies.
  • Test Driven Design, less suitable due to the problems of mocking SharePoint but worth considering for small tasks.
  • Continuous Integration, if you have multiple developers its a must, if you are on your own, it’s still a must.
  • Continuous Deployment, this is hard especially if you are updating multiple sites as the time to do it for a reasonable sized farm can easily run into the hours, however ‘automated’ or ‘scripted’ deployment a pre-requisite for this is an absolute must.
  • Kanban Board, if you are doing Business as Usual or lots of small enhancements this is fantastic in terms of keeping it all flowing.

So that’s a quick round up, next is a set of case studies showing how we do this in practice.

Cheers

Sebastian