Monday, October 26, 2009

New in SharePoint 2010 Lookup fields

SharePoint 2010 introduces some new features in the lookup fields area.

The bad news are, I'm afraid, that still all lookups are restricted to the same site collection.

But, from now on you will be able to include more then one field in the remote list when creating a lookup. So that if you are creating a lookup to "customers" list, you can ask to see customer's first name, last name, company and email instead of just "full name" or "customer name" as before.

Another new feature allows you to enforce your lookup data integrity, meaning you can either prevent deleting an item that has other items connected to it, or cascade the delete action to delete all dependant items.
This is good for customers who has "project" list and "project tasks" list, where a task is connected to a project.
So, by deleting a project you can make sure that all that project tasks are also deleted.
Or - if you'd like, to prevent deleting a project wiht active tasks! which is also cool.

Finally, there are some news on reverse lookup. Although SharePoint 2010 does not fully support reverse lookup fields it has a new API for getting all related items for a specific list items.
This means, that this new API will get all items in SharePoint that has a lookup that is connected to the current item. This new API also comes with a new web part OOTB you can just drop at any list item view form to see its connected items.
But still, if you want real reverse lookup functionality you will have to go with a 3rd party solution like KWizCom's Cascading lookup plus field type currently available for SharePoint 2007 but will be upgraded as soon as there is a public release of 2010.

Another thing that is greatly missing (and is available in our cascading lookup) is... Cascading feature! :) I mean the option to filter items in one lookup field based on one or more other fields on the same page. Thus creating a 2 or more levels of dependant fields (Country/City/Street fields for example)
Well, good thing SharePoint 2010 is not perfect - gives us more work to do, right? :)

Enjoy your migraion!
If you need help, feel free to contact us,

Using LINQ and REST in SharePoint 2010

Among the new APIs available for SharePoint 2010 developers the 2 new most significant ones are LINQ and REST.

While developing server side code, you can now make use of LINQ to query your lists instead of using CAML.
The benefit of using LINQ is clear, working with strong typed objects and cutting down the development effort by a lot.
The problem comes when you are not sure what type of lists you are going to work on, and if you wish to support custom lists created by customers.
Before you can use LINQ on SharePoint you need to create an object that represent that list structure, and once the list changes (the fields you are querying are removed to renamed) you will not be able to use it anymore :(

But - remember, working on the server site with the SPList object is dengerous as well, as all you get are item[field_name] resutls, which is not strongly types and requies many validations to be done!

While working on the client side, you will be able to work using the client side object model (much like the server side, using Site/Web/List instead of SPSite/SPWeb/SPList we have on the server) but still that will not be strongly typed for you.
The news are that you will be able to use LINQ in the client side, that will allow you to automatically render the correct proxy objects in the client side (accessible from javascript / silverlight) and will be strongly typed!

So, by all means - start learning SharePoint REST syntax and commands...
here are some available commands to get you started:
$metadata – bring all metadata of that object

These commands are accessible under the REST service URL which includes (sometimes) the entity name you wish to run against, like so:
http://site/subsite/_vti_bin/ListData.svc/{Entity Name}/{Options...}

This service URL can be registerd to the client using the standard ASP.NET AJAX way for registring services, and everything is made simple after that!

(If you need more info on ASP.NET AJAX you should definitly check these how-to's by Joe Stagner here: and specifically on registring services here:

Well, are you excited as I am to move onto SharePoint 2010 yet? :)

Tuesday, October 20, 2009

How to override the sandboxed current site execution limitation

When you publish a solution in SharePoint as a sandbox solution, we already talked about that the proxy API will block any access to other remote site collections.

An easy override to this is simple - simply use the client API and you will be able to access any share point site you wish without going through the proxy API that a sandboxed solution uses.

Client API in SharePoint 2010

This is what I picked up in todays great session on client code;

Basically, Microsoft.SharePoint.Client is a wrapper that you can use at the client side (silverlight or javascript) to add get and update information.
Migration of code will require start using the Client API objects instead of the current API we all know in the server, but most objects are similar to help us update our code easily.
So - SPWeb will be web, SPList will be list etc...
Event SPContext exists as ClientContext!
the only difference is, that you run all your code on the clientContext object in the client side, and once you have a set of operations you wish to submit to the server you can do that by calling "clientcontext.ExecuteQuery()" or "clientcontext.ExecuteQueryAsync()" if you want the UI not to wait for the result.
If you wish to retrieve data form server to your client you can use the “Load” or “LoadQuery” methods. LoadQuery will return a result collection and will use method syntax or linq query syntax. It will build you XML query and will send them to the server next time you call “ExecuteQuery”.
Using the "Execute" or "Load" methods actually help reduce the number of trips done from the client to the server to reduce server load, bandwidth and improve responsiveness.
Nothing new, except you don't have to build your own wrapper and web services if you want to run some code on your SharePoint from the client. Basically this will communicate with client by dropping JSON code from the server to the client, the client will use the JSON to work with and send queries to the server in XML format.
I guess this will help us do less post back, as this will not be supported in wiki pages (no post back support).
A new cool thing is the SP.CamlQuery.CreateAllItemsQuery() method that renders a CAML that returns all items for a list. This will surly get you started with CAML query – the last stand of CAML in 2010 since views and forms are now defined by XSL.

More news from the SPC2009 will follow!

Upgrading SLFE from 2007 to 2010

** Updated: **

This morning KWizCom’s VP R&D, Shai Petel, hosted an extremely well received session at Microsoft’s SharePoint 2009 conference in Vegas.

The session covered three topics: building a new solution, upgrading an existing solution and version management. Rather than speak about theory, Shai’s presentation gave attendees a firsthand perspective, based on an actual migration he did himself.

Read more and/or see the presentation Shai gave at SPC ‘09 here.

Monday, October 19, 2009

News on SharePoint 2010 from SPC09

Here are some things i picked up at the SharePoint conference 09 (announcing SharePoint 2010):

* No more SharePoint "hive" (12 folder)... from now on say SharePoint Root! VSeWSS2010 will redirect it to 12 folder or 14 folder or any other folder used based on your current running version of SharePoint.

* VSeWSS (Visual Stuio extensions for WSS) 2001 supports 1 and only 1 package per project. But in each project you can have as many features as you like.
The cool thing is that the features are shared between projects in the same solution! So you can include a feature from 1 project in several other deployment packages with all of its resources.

* Sandbox solutions
Now you can deploy solutions in a site collection, and not on the farm.
This means that the solution will be deployed and installed on that specific site collection.
Code in sandboxed solution runs inside a seperate process - not on W3WP, and has no direct access to SharePoint API. Instead it uses another proxy process that provide it with limited access to the SharePoint API. You will be able to do almost anything within your site collection, while you will have no access to remote site collections and read only acccess on your current web application and farm.
Some customizations are not supported within a sandbox solution, like code based workflow, site definitions etc.
Installing a sandbox solution is very simple - i will publish a how to with images soon but for general idea, you just need to upload it to your site collection solutions gallery (library) and activate it!
Sandbox solutions do not deploy any files anywhere! On first access to the solution code the SharePoint will load its code and resources into memory and will run it from memory.

* VSeWSS allows you to select if you want to allow the solution to be sandboxed. Choosing so will make visual studio validate that all my elements are supported within a sandbox solution - and promt me if I add something that is not supported.

* Visual web part - or is it?
The good: This is a new VSeWSS 2010 project template that allows you to create a user control as a web part. Simple, easy and long overdue.
The bad: This is not really a visual web part, its just a good old web part that loads a user control as its only child. At least all files (web part, user control files) are created, grouped and deployed for you.
The ugly: our old web parts we designed without a UI editor... we did our best though :)

I will post more as the SPC09 continues,
Shai Petel.

Client API in SharePoint 2010

With REST, ASP.NET Ajax, Microsoft.SharePoint.Client.dll new API - and of course silverlight all built into the new platform, our next generation of applications will have to have a major UI facelift.

You can expect much less page refreshes, more responsiveness and easier development proceess for more complex UI scenarios.

You have to keep in mind that SP2010 wiki pages do support web parts, but do not support postbacks!

So using these client-side calls will be almost mandatory if you wish to provide advanced controls and feature rich compoents in your pages.