Corey Roth [MVP]

As a developer, I have to admit I have always had a love / hate relationship with InfoPath.  It worked well for some things but once you reached that point where you needed more, you had to scrap your entire solution and start over with something else.  Although I haven’t built solutions with InfoPath in quite some time, back in the da,y I did a number of projects that involved them from a workflow perspective.  Thinking back to the 2007 era as a power user, InfoPath was fairly straight forward to integrate when it comes to workflow.  However, as a developer, if you wanted to use InfoPath for a workflow association or initiation form, the process was quite involved (and well painful).  You had to create that XML file manually to map your fields, wire up a bunch of code to handle correlation tokens, and all of that fun stuff.  I can’t say I miss that at all.

For the last few yeas, we have been dancing around the future of forms.  It was apparent there was nothing new with InfoPath 2013, but the direction just wasn’t known.  Even now, we still don’t know yet, but Microsoft has told us something new is coming.  I am looking forward to a future where forms meet the needs of business users across multiple products.  Since Microsoft has announced the EOL of InfoPath, I’m excited to see what the future of forms will be.  Although the use of forms has always been centered around the use cases of the business user (as it should be), we developers have been able to make use of them too.  I am hopeful as a developer, that we get a solution that meets some of our needs too.

I have no idea what is coming, but from the development perspective, I hope whatever comes out of forms technology in the future meets the following requirements from a developer’s perspective:

• The more end users can do the better – ideally, a developer never has to touch a form.  End users should be able to create rules, enable conditional formatting, and change the look and feel within reason.
• Forms should be portable – if you build a form on one site or web application, you should be able to move it to another.  Lists should be referenced by name or relative URL as opposed to GUID.
• Mobility is key – A user should be able to complete a form regardless of the device they are using.  Forms should automatically employ RWD patterns similar to Cloud Business Applications to render the form appropriately on mobile devices. If the forms worked offline, that would be a huge value-add.
• Forms should be extensible – Code could be added to InfoPath forms, but that made deployment complicated.  Ideally, forms could be extensible using the Cloud Application Model (CAM).
• Workflow is required – Access 2013 provides a lot of value in the forms world but you can’t associate anything there with a workflow.  It’s rare that a business user makes a form that doesn’t have some business process represented by a workflow associated with it.
• Full support of managed metadata – The InfoPath story with managed metadata has never been complete.  Whatever the form solution ends up being, we should be able to bind form fields to managed metadata fields.
• Good story with external data – the forms solution should integrate well with external data coming from Business Connectivity Services as well as REST data sources.
• Support for cascading drop-downs – the new forms solution should allow for cascading drop-down lists.  This has always been a challenge with InfoPath
• Painless transition to developers – when an end user reaches the point that they need a developer to assist with a form.  The developer should pick up where the end user left off without starting over.  Ideally, this means developers can deploy these same forms with the app model using Visual Studio.

I’m quite excited about what’s in store for forms with SharePoint.  Meeting the business user’s needs will always come first, but I hope that some of these things will are on the radar from a development perspective.  I am sure we will here more of what is in store at #SPC14.  If you are going, be sure and attend the session SharePoint Forms Roadmap (#SPC348).  It is sure to be a packed one so you best arrive early.

Ok, so I know I can’t speak for all developers.  What do you want in the next forms solution?  Leave a comment!

I’ve been doing some content analysis with PowerShell lately and I thought it would be useful if I could query SharePoint search.  With the addition of Search to the Managed Client Object Model this task is pretty easily.  I have already written a post on how to do this in a console application.  Let’s adapt that code for use in PowerShell.

Create a new script using your favorite script editing tool such as PowerShell ISE.  We’ll call mine SearchQuery.ps1.  The first thing we want to do in this script is add a parameter so that the search query can be passed via command line.  We’re going to give this parameter a name of $queryText.  The second parameter is a path to a site collection.  We need this for our ClientContext object.

Now we need to load the following assemblies like we did with our console application.

• Microsoft.SharePoint.Client.dll
• Microsoft.SharePoint.Client.Runtime.dll
• Microsoft.SharePoint.Client.Search.dll

To do this in PowerShell, we use the following statements:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Client")

Now, we get a reference to a ClientContext object to handle all of our client side requests.  W

$clientContext = New-Object Microsoft.SharePoint.Client.ClientContext($siteCollectionUrl)

Once we have this object, we can use it to get a KeywordQuery object.

$keywordQuery = New-Object Microsoft.SharePoint.Client.Search.Query.KeywordQuery($clientContext)

We then use the QueryText property to specify our search query.  In this case, we are just passing the value of $queryText received from the command line.

$keywordQuery.QueryText = $queryText

If you haven’t used PowerShell ISE, it will also provide you IntelliSense on your objects similar to Visual Studio.

Now, we need a SearchExecutor class to execute our query.  It requires a ClientContext as well.

$searchExecutor = New-Object Microsoft.SharePoint.Client.Search.Query.SearchExecutor($clientContext)

To execute the query, we use the ExecuteQuery method.  It will return us a $results object which we will access in a similar manner as we did with our client application.  Pass it our KeywordQuery object.

$results = $searchExecutor.ExecuteQuery($keywordQuery)

This doesn’t execute the query though.  Since this is a client object model, we still need to call ExecuteQuery() on our ClientContext object to make the query happen.

$clientContext.ExecuteQuery()

Just like in other examples, the individual results are buried in $results.Value[0].ResultRows.  What’s also unfortunate is that each row comes back with a series of Key / Value pairs which makes binding this data in bulk somewhat painful.  We can example the object and format it in a table but it doesn’t give us much to work with.

$results.Value[0].ResultRows

If you know exactly what fields you are looking to access though you can just iterate through the results with a foreach statement.

foreach($result in $results.Value[0].ResultRows)

{

It’s not ideal, but it works alright for small batches of results.  Here’s what my results look like now.

This gives us some search results that we can work with.  Now you use them in PowerShell as you need.  It should even work on remote servers provided the user account you are running under has permissions to the SharePoint site.

In the last few months, I have noticed some new acronyms creep up in the SharePoint community.  What is it?  Well as a developer, it’s stuff you’re probably already doing.  You take a search in your favorite search engine and you won’t find the terms mentioned much with the earliest mention I could see starting around October of last year.  The definitions will seem obvious when you see them.

• CAM – Cloud App Model.  This is basically referring to the new SharePoint app model introduced with SharePoint 2013.
• FTC – Full Trust Code.  The way you have been developing with previous versions of SharePoint using solution packages and server side code.

More recently I also saw a reference to PTC as well in a post by @mkashman.  What’s that?  Partially trusted code.  In this case, we are talking about Sandboxed solutions.  When I think of PTC, I still think of partially trusted code using CAS policies.

Any how, it’s no secret that there is a big push for us to transition our code to the new cloud app model.  You’ll see more and more references of “FTC to CAM”.  There is even a session or two on this at SharePoint Conference 2014.

What do you think?  Did you have any idea what these acronyms were when you first saw them?

@coreyroth