locked
Client Object Model and Web Service Limitations RRS feed

  • Question

  • Does anyone have a list of things that CAN NOT be accomplished using the Client Object Model or the SP Web Service.  This would be things that can only be done by code installed by feature to the hive (Is it still called the 12 Hive?) 

    We are putting together an architecture for a new project and the rules of the corporate farm are restrictive.  We are trying to determine which functions ie. programatic application of permissions will be limited by the restrictions.

    Thank You

    • Edited by Jerry Lanp Monday, May 3, 2010 3:19 PM Misuse of the word "governance" we do not have a "governess"
    Sunday, May 2, 2010 8:19 PM

Answers

  • The following link is an exhaustive list of things you can do with the client object model. It also has additional resources at the end. Hoping for a complete list of things that were left out compared to server side object model is asking for a lot. The server side model is huge in SP2010. Unfortunately, developing remote SharePoint applications that rely on remote calls is like being "Thomas Edison" and having to do a lot of experimenting to determine capabilities. This should be handled in the prototype phase of development. Iterative cycles can help a lot to mitigate design risk especially in regards to sandbox solutions.  Hope this helps some.

     

    http://msdn.microsoft.com/en-us/library/ee857094.aspx


    certdev.com
    • Marked as answer by Jerry Lanp Monday, May 17, 2010 1:15 AM
    Sunday, May 16, 2010 11:05 PM

All replies

  • I do not know of a documented list of specific items that are not in the remote APIs, however the majority of the things you can do in the UI can be done through the Client Object Model or Web Services.  I would start by looking here http://msdn.microsoft.com/en-us/library/ee557253(office.14).aspx

    Regards


    BradP
    Friday, May 14, 2010 8:31 PM
  • That was indeed interesting, Brad.  However, it would seem to me that with as much thought as went into the new version of SharePoint there would be some sort of paper trail to explain what features were left out (blocked) and why.  Just a quick "for instance". Using the PageViewer web part we still have no way to call the site and communicate parameters with the web site which is being displayed even with full control of the server on which the page is being displayed.  Also, when we use the "log on as another user" feature it still displays the page in the PageViewer webpart with the credentials of the user who logged onto the machine, not the impersonated user who logged in to the site. 

    Someone made a consious decision to block these features. 

    The web service in Moss 2007 allows an authorized user to set permissions on a list, but not on individual list items, or more importantly individual documents in a document library.  I don't know if SPS 2010 has added this as a feature.

    It seems that somewhere these things need to be documented.

    Saturday, May 15, 2010 5:12 AM
  • This is not (yet?) documented; but keep in mind that even if there are some limitations in the Out of the box web services, you can still extend the existing functionalities by creating custom (asmx or wcf) web services...

     


    Serge Luca; blog: http://sergeluca.spaces.live.com Devoteam Belgium
    Saturday, May 15, 2010 5:24 AM
  • Serge,

    Yes, indeed you are correct.  I can extend with features and I know how to do so.  However, I put the entire farm at risk each time I install something, and it seems that sandbox applications are very limited in what they can do.  In fact the governance at the corporate level is highly restrictive and so should it be.  My client wants firm estimates when I venture out to do something and unfortunately I run into too many instances where I just didn't know that there was an intentional wall put up blocking me from doing something out of the box. 

    All I am asking for is a list of the things that I can't do.  That way I can show the client when they don't understand why I have to build a custom feature to do something.

    Saturday, May 15, 2010 8:01 AM
  • The following link is an exhaustive list of things you can do with the client object model. It also has additional resources at the end. Hoping for a complete list of things that were left out compared to server side object model is asking for a lot. The server side model is huge in SP2010. Unfortunately, developing remote SharePoint applications that rely on remote calls is like being "Thomas Edison" and having to do a lot of experimenting to determine capabilities. This should be handled in the prototype phase of development. Iterative cycles can help a lot to mitigate design risk especially in regards to sandbox solutions.  Hope this helps some.

     

    http://msdn.microsoft.com/en-us/library/ee857094.aspx


    certdev.com
    • Marked as answer by Jerry Lanp Monday, May 17, 2010 1:15 AM
    Sunday, May 16, 2010 11:05 PM