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!
Tuesday, October 20, 2009
Upgrading SLFE from 2007 to 2010
** Updated: http://kwizcom.blogspot.com/2010/08/upgrading-customized-solutions-in.html **
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.
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.
* 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.
Subscribe to:
Posts (Atom)