You can drop almost any piece of HTML, CSS, JavaScript, jQuery, etc. you want on to a SharePoint page. As long as you possess Designer permissions or better, you can drop this code on to a page or pages and provide your users a richer UI experience while sparing you the headache of placing files on the server file system. It’s extremely easy to drop a Content Editor Web Part (CEWP) onto the page and plop your code down. But there are 2 inherent problems with this approach:
- Zero Source Control
- Difficult to repeat
So how do you solve these 2 problems?
- Save your code in a text file
- Place the text file in a separate, dedicated document library for these snippets
Once the file is in the doc library, you can paste a link to the text file in the CEWP. By creating one single source of the code, you ensure consistency amonth other CEWP(s) that call the same text file. It’s just good coding practice and it’ll make your life a lot easier in the long run.
The CEWP has been capable of linking to a text file since at least MOSS. SharePoint 2010 has just made it slightly more difficult on developers to drop code on the page by hiding the HTML editor in the ribbon. This is a change that I welcome and have come to appreciate.
One last note, make sure that your users have at least Read access to this text file doc library. Generally, I break inheritance on this specific library and add domain/domain users with Read permissions. Just one less thing I have to manage.
Adventures in Tech 
Ouch. We should look at TFS or SVN.. 🙂
LikeLike
Why bother with TFS or subversion when SP provides it’s own brand of source control?
LikeLike
Because every developer or tech SP dude will tell you don’t use SP for source control? Also you lose many many features
other solutions bring..
LikeLike
What SharePoint IT Pro would disagree with my post? You find one and I’ll show you someone who isn’t a true SP IT Pro.
LikeLike
Steve – I believe you’re incorrect. I’ve never heard of anyone locking down source files in a way other than what’s described here; Breaking inheritance at the code’s doc library will do the trick just fine. To my knowledge, this is regarded as a SP best practice. It’s not like we’re securing Fort Knox.
LikeLike
2 second search on iPad. http://bytes.com/topic/c-sharp/answers/768883-sharepoint-2007-version-control
LikeLike
Maybe in this given scenario it’s ok, but I’d have to look at in action. Also, it depends what you are source controlling
LikeLike
Ah I see now. We’re arguing 2 different points here. For true source control of application development TFS and subversion are THE only options I would EVER feel comfortable using. In the case of SharePoint (and web development in general), ideally you would point to one single source. Take the case of images in web design for example. You put your image in your images folder and point to that one image every time you referenced it. In old skool SP, you would, in effect, place that image (or HTML in this case) on each individual page when you referenced it. Sometimes you’d have 5, 6, 500 different versions of the same thing every time you called for it. A poor practice regardless of the context. Does that help clarify?
LikeLike
Yep, makes sense. Now move your comment system to disqus so I don’t have to fill in the blanks every time. And drink a beer.
LikeLike