Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Here's my situation: I work in a user area and have been tasked with creating usable SharePoint sites for different areas. Some are doc management, some are collaborative work spaces, some are task and calendar-driven. Some are combinations of the above. My point is that I've got a very diverse group of sites to create.

Our IT department is unprepared to support SharePoint. Even though I can do the requisite .NET development necessary to create the feature-rich sites I envision, that's not something I've been cleared or given access to do. If I were to develop an application, the question "Who's going to support the application?" will inevitable arise, and it's back to resources again. Our limitation seems to be OOTB SharePoint Foundation, without any .NET development, AJAX, or other nifty tools to make it more usable.

As I ask questions looking for creative client-side only solutions, I see several comments from posters that suggest the folly in that approach. However, I also get responses that give me a workable client-side solution. While the latter gets me what I need, the former makes me question if my approach is the most prudent.

I see a lot of "no code" questions, but haven't really found any information about why server vs. clietn development is an issue. Apart from the usual standards issues when everyone's developing willy-nilly, what other considerations must I make? For me, the beauty of SharePoint is the dozen or so ways to do anything. When is it appropriate to make an application that uses ONLY OOTB client vs. server-side development? What questions do I need to be asking to ensure that I make the correct recommendations? If we jury-rig applications to run without any server development, are we setting ourselves up for problems in the future, and what sorts of problems might we encounter? Is it worth doing OOTB development now and 'upgrade' to a server-based solution when we can, or is it more prudent to wait until IT has their support infrastructure set up and can start coding? Is there a good rule-of-thumb for determining if an application should be server-based or OOTB SharePoint client functionality only?

share|improve this question
1  
Let the religious war commence... –  Ryan Jul 13 '12 at 7:48
    
Added (awaiting moderation/approval) Infopath tag since it is the main codeless paradigm, approach and development "platform" for sharepont –  Gennady Vanin Novosibirsk Jul 19 '12 at 22:09
add comment

5 Answers 5

up vote 3 down vote accepted

The client side (no-code as you call it) approach is non-destructive to the platform as it all happens with what SharePoint natively serves up. If something breaks, you remove the problematic script and you're back functioning natively without any fancy customizations. If done right, this can still be very powerful and SharePoint gives you native version control. So your JS files can be versioned and rolled back quickly if there is an issue.

The coded approach is modifying what the server is sending to the user, so it's much more destructive in that if you don't have something right, i can cripple the site and or farm as a whole.

The client side approach is harder to deploy to multiple instances unlike the coded solutions which are deployed as features and can easily be activated anywhere.

I am in the former (no-code) with some spatterings of code (data view web parts, some custom CSS and master pages) and we can still deliver rich, specifically targeted applications.

share|improve this answer
    
for future readers, I took your client/server-side semantic suggestion and updated my question to be, I hope, clearer. I'd be interested to know how JS works on SP...would one just edit the HTML on a page and cut and paste the code? Anything else special to do with that? –  dwwilson66 Jul 12 '12 at 15:10
    
I do it as a document library to hold my version controlled JS files. Then in the page(s) I need to use them, add Content Editor web part(s) pointing to the desired script(s). –  PirateEric Jul 12 '12 at 15:38
add comment

Probably, most questions will arrange in more system if you look at Sharepoint from the point of view of cloud technologies and specifically of using Sharepoint Online (Office 365).

There:

  • there is no access to Central Administration and. hence, administrator-approved forms or disabling notorious Loopback Security Check or using/administering AD, et., etc.
    In Sharepoint Online, the server-side dev is simply does not have much sense
  • you can create code-behind for Infopath 2010 forms in VSTA (Visual Studio for Applications) but that VSTA is really Visual Studio 2005 for Applications with .NET 2.0 no higher than 2.0
    The latter should be considered in order to not break development solutions a-la VS2005/.NET 2.0
    But if you deepen in client coding then you understand soon that it is mostly a waste of time and better to spend your time to know well what can be done codelessly and OOTB
  • client solutions (like Infopath client/Filler Forms) are cheaper and, surprise-surprise, is richer in functionality and easier to configure (do not have double-hop authentication issues) than Infopath browser-based forms requiring Infopath Form Services from Enterprise Sharepoint Server 2010 plans, etc.

BTW, I am developing on Windows XP SP3 32-bit computer using Sharepoint Designer 2010 and Infopath Designer 2010 against Sharepoint Online 2010 (Office 365) site
This is cheaper, simpler. less intrusive and more maintainable than putting every developer on Windows Server 64-bit machine with farm or server privileges.

share|improve this answer
add comment

As @PlanetWilson wrote "It depends"

Here's my view on Server side/Client side/Sandboxed solutions. I only list the benefits of each, then you can extrapolate the drawbacks by looking at the benefits of the other parts or by thinking of when the benefit may be a bad thing.

Benefits of Server side

  • Can perform actions which the current user don't have permissions to do. Which means you protect list/items so they can only be updated/accessed through the code
  • Can get access to all of the SharePoint functionality.
  • Application lifecycle management. There are good tools/techniques for version control of code and for controlling the deployment/upgrade of solution in Dev => Test => Staging = Prod environments
  • "Easy" to develop/lots of examples
  • If well developed gives a lot of power to the users by allowing configuration/connection of web parts.

Benefits of Client side

  • Can be deployed to environments where you can't get Server side code for some reason
  • Often gives a better UI as we're doing AJAX anyway

Sandboxed solutions

  • Can add some functionality like event receives where Server side solutions isn't allowed
  • Can't bring the servers down
share|improve this answer
add comment

As I am in the exact same situation here in my company, I can imagine your situation. When I searched for answers I stumbled upon Marc D Andersons Blog and especially his Middle Tier Manifesto. These ideas helped me a lot to define my situation.

If you are all new to JavaScript in SharePoint and don#t know yet what you can do with it, I recommend you to take a close look at Marcs SPServices library. It is an abstraction of SharePoints Webservices and all about retrieving and sending data from and to SP lists and so on.

share|improve this answer
add comment

"It depends" :)

No code is great when you want to do something reasonably small, quick, not wide ranging on your site. You can do a fair bit with JavaScript, content editor webparts and client object model.

It isn't particularly scalable though. You end up copying a lot of stuff around, hacking away at master pages in notepad, that sort of thing just because you can't easily deploy code.

It comes down to whether you have complex systems which are maintainable because you follow decent solid software engineering principles, repeatable trustable deployment, source control, supportability etc

The fact that you create things through the UI and use JavaScript in CEWP, change master pages etc doesn't mean you don't have an application. You have still built one, just one which is harder to fix when it goes wrong.

share|improve this answer
    
Excellent point. I think one of the challenges is that the user areas are running with this a lot faster than IT expected...they've not even discussed governance for SP as far as I'm aware. Coming from a development background, I'm keenly aware of maintainability...but am kind of making up the rules on the fly as needed, in lieu of formalized standards and guidelines. –  dwwilson66 Jul 12 '12 at 15:13
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.