I had an idea at the beginning of the year. I am the Site Collection Administrator and am only responsible for administering and developing solutions for my SharePoint site collection in my office (about 2000 employees). I do not have access to the SharePoint servers to install WSP’s, use STSADM, or even PowerShell.

I am in charge of all development for my Site Collection but getting a custom SharePoint web part or WSP solution into production takes weeks….and sometimes months. So, i began working with the Content Editor Web Parts (CEWP’s) to see if I can use the SharePoint Web Services and Javascript as a “Poor man’s” web part. My “Poor man’s” web parts are only CEWP’s which don’t have to go thru a special code review and approval process before being moved into the production SharePoint farm.

If you are under these same kind of restrictions, maybe you’d like to consider this approach as well. However, this isn’t the best approach in that things can ‘break’ easily if someone modifies your code in the CEWP’s.
 
(more…)

Believe it or not, this is a very useful piece of code. I use it often in my content editor web parts to get the URL of the site I’m currently on.

To be more specific, I use this code to get the URL of the site, then modify it to dynamically create a URL that points to the LISTS.ASMX web service. Why is this useful? Consider the following:

1. I have a custom list at the root site collection that is readable by everyone.
2. The list contains a link to a custom web part page that is located on each site (subsite) in my site collection. The web part page is just a blank page that has a few CEWP’s (content editor web parts) in different zones.
3. One of the CEWP’s only function is to get the URL of the site, then does a javascript ‘split’ to get each element of the URL. This is necessary to build a custom URL that points to the ‘LISTS.ASMX’ web service for the site I’m on.
4. Once I have the new URL (that has been modified to point to the ‘lists.asmx’ web service), I can then query my sites schema (including list schema) for the site.

I find this to be VERY useful in that I can get a listing of all lists and libraries for a site and view the XML schema behind them, all bundled up in a single report. Instead of going thru each site and each site’s lists one at a time, I can view the XML schema from a single ‘web part page’.

So, to get started, I’m going to show you how to get the URL from a site. Let’s begin by assuming you are on a SharePoint site at this URL: (more…)

I often use query strings in SharePoint web parts, links, lookup columns, etc., and have found this bit of code to be very useful when having to display content on my page based on the value of a query string parameter. Here’s an example of how to get the value of a query string parameter by using JavaScript:

(more…)

When I create web parts for my SharePoint sites, I try to make it a good practice to detect what browser is viewing my site and then display a message if it is not supported.

For instance, the company I work for only supports Internet Explorer. I am able to use other browsers in my organization but the content on any web page is only guaranteed to be displayed correctly within IE. All other browsers may or may not display the information correctly, so IE is the only option I have to work with.

So, I often use Content Editor Web Parts to display content on my site, especially if I am using javascript to query my SharePoint sites for data (using the SharePoint web services). However, if a user goes to one of my sites and gets errors or has improperly formatted data, I have to instruct them on the company’s policy to use IE only to view the site. In most cases, this doesn’t go over well.

To use this code example, add the code to a Content Editor Web Part on your site (I usually put it at the top): (more…)