In the first entry to this series, I demonstrated how you can use a data view web part (DVWP) to emit SharePoint® calendar events as JSON that the FullCalendar jQuery plugin can use. Although it works fairly well, there are some limitations to the solution. It doesn’t handle recurring events, it doesn’t retrieve all events, it doesn’t support pagination/bookmarking, and it doesn’t provide a way to connect the calendar to Outlook® or create alerts.
This post will overcome the first two limitations by borrowing most of the code posted in this discussion thread on CodePlex and doing away with the DVWP altogether. Jim Bob Howard provided a lot of great information, but it’s broken up over several replies and is a bit difficult to follow. I also wanted to expand on the functionality of his solution by displaying events in the local time zone instead of the web server’s time zone and optimizing the web service calls by retrieving as few events at a time as possible instead of getting a month’s worth of events at a time.
I’ve been using jQuery UI in a few recent projects on my department’s SharePoint® site. In order to provide a consistent user experience, I used the excellent ThemeRoller to create a custom theme that matched our branding. We have a custom master page, custom page layouts, and our own color scheme, fonts, etc. so I wasn’t trying to match the OOTB look and feel of SharePoint.
However, it recently occurred to me that although I’ve seen a few articles about people using jQuery UI to enhance SharePoint, they usually go with a pre-built theme that doesn’t quite blend with the rest of SharePoint. With that in mind, I decided to see how closely I could match the default SharePoint look and feel using ThemeRoller. I’m limiting this to just SharePoint 2007 for now, although I may do a follow-up for 2010 if enough people find this useful.
What if I don’t like the default look of SharePoint?
First, let me say that although I don’t think SharePoint looks terrible (although many would disagree with me on that!), it does look pretty dated. However, I would rather have a SharePoint site look consistently dated than have a cool-looking, modern tab widget in the middle of a SharePoint page; it would stick out and break the flow of the page design.
There is an argument to this of course—you might want your widget(s) to stick out so that users are drawn to them and don’t lose track of what they’re doing in a complex web application. I recognize the potential value in that. However, if that were the case for me, I’d still want the theme to blend, but I’d probably do something like reverse the primary and accent colors or find a complementary color scheme to use.
As part of a large department site redesign project, I wanted to implement a better calendar solution than what MOSS 2007 gives you OOTB. I remembered coming across the FullCalendar jQuery plugin a while back, so I decided to try using it with the calendar on my department’s site. I haven’t tested this in SharePoint 2010, but it should work just fine regardless of the version (just verify all of the column references in case any of them are named differently).
Prepping the Resources
Once the files were uploaded, I copied the calendar.aspx page and renamed it CalendarCustom.aspx in SharePoint Designer (SPD). Then I switched back to the web UI, went to the calendar settings, and modified the duplicate “Calendar” view so I could rename it and set it as the default (this is the view that will contain our custom calendar). Next I opened that view and hid the default list view web part for the calendar.
Setting Up the Data View Web Part
I didn’t want to bog down the browser by loading hundreds of really old events, so I set a filter on the DVWP so that only events with a start time greater than or equal to today minus 90 days would be displayed (see this post for more information on setting up CAML query offsets). This allows people to view events up to three months in the past, as well as current and future events. I also sorted the events by start time in ascending order.
The default rich text editor (RTE) in SharePoint® 2007 doesn’t quite cut it in my opinion, and here’s why:
It’s based on an ActiveX control, so it only works in Internet Explorer. This alone is reason enough to replace it.
When creating a multiple line of text column in a custom list, you can only choose between “Plain text,” “Rich text,” or “Enhanced rich text” as the format for the column—not a lot of options. What if you want your users to have access to headings or other HTML elements?
It generates horrible, deprecated code:
<DIV>Look at how <EM>bad </EM>this HTML is! If I start <SPAN style="color: #ff6600;">coloring things </SPAN>it gets really messy. I try to make sure I'm not getting too crazy with the content, but many users will select <SPAN style="font-family: 'Comic Sans MS';">their own fonts</SPAN>, <SPAN style="font-size: small;">sizes</SPAN>, <SPAN style="background-color: #33cccc;">colors</SPAN>, etc. instead of keeping things simple, which makes the markup even worse.</DIV>
<DIV>Why does it use <div> tags instead of <p> tags? Why are the elements in all caps?</DIV>
<DIV><SPAN style="color: #ff6600; font-family: 'Times New Roman'; font-size: medium;"><STRONG>Now if I try to make an entire section formatting differently, it gets weird with <font> tags and <span> tags.</STRONG></SPAN></DIV>
<DIV><SPAN style="color: #000000; font-size: xx-small;"> </SPAN></DIV>
<DIV><SPAN style="font-size: xx-small;">Users probably don't know about the Clear Format button, so when they want to add "normal" text after their crazy colored, centered, bolded text, they try to match the normal text with even MORE direct formatting.</SPAN></DIV>
<DIV><SPAN style="font-size: xx-small;"> </SPAN></DIV>
<DIV><SPAN style="font-size: xx-small;">Now try using this content in a branded site and see if your CSS holds up. Let a user edit this a few times and you'll have nested <span>s all over the place with all kinds of formatting.</SPAN></DIV>
Even the Full HTML RTE that you get on Publishing Pages (or if you create your own site column of this type) generates the same kind of markup. You have a few more options, like selecting basic HTML elements (paragraphs, headings, address, etc.), but you still can’t customize what appears.
A decade ago this RTE would have been really cool, but in today’s standards-compliant, feature-rich web, it just doesn’t hold up.
Enter TinyMCE, an open-source RTE with tons of customization OOTB, and even more thanks to numerous plugins (you can even write your own plugins if you need something that it doesn’t have). In this post I’ll show you how I replaced the SharePoint RTE with TinyMCE on my custom list forms using a little jQuery.
Note: This isn’t a tutorial about using TinyMCE for all rich text editing in SharePoint; it shows you how to use it on a per-form basis. (more…)
Note: This article was originally posted on NothingButSharePoint.com, but some of the code snippets were unescaped when it was published, so I decided to post it on my own blog with the correct code snippets.
I was recently tasked with finding a way to maintain an org chart for my department. If this were a single-use resource that didn’t need to be updated frequently, I would have chosen to create it in a program such as Visio or Adobe Illustrator (even PowerPoint would work well with its SmartArt capabilities). However, this is something we want to be as maintenance-free as possible so we aren’t rebuilding it as people come and go.
The department’s operations team already maintains a list of everyone in the department by using a SharePoint Contacts list, so we can pull data from that and build the org chart dynamically. This method does not require any custom code or web parts, so there’s no need to deploy anything on the server!