Thursday, November 29, 2012

Binding Event Handlers to SharePoint Content Types (Sandbox)

Fiddling around in SharePoint's Sandbox land can and will test your sanity.  There are things that are the way they are and you just have to deal with it.  All in all, a learning experience indeed...

Here's some key takeaways from my current project:
I opted not to bind this to the Content Type because I didn't want the Event Handler's behavior to persist on any other list.  I doubt the CT will be reused, but if it is, I know my code will not run erroneously.

Once that is added to your list, then you can dive into the properties and detect the Content Type GUID for the item that was just added.  A simple example:

       public override void ItemAdded(SPItemEventProperties properties)
       {
           base.ItemAdded(properties);
           if (properties.ListItem.ContentTypeId.Parent.ToString().ToUpper() == Constants.ctGuid.ToUpper())
           {
            // Snipped
           }
This is only a small part of what I'm in the middle of building.  Hopefully, I can abstract more out and show off some of the innards.

Cheers!

***Update***
Shortly after posting this @SharePointAlex and I started to discuss binding Event Handlers to lists.  Based on my tests, I've confirmed that using a Site-scoped solution does in fact fire the Event Handler on all lists in your web.  Using the same technique but having the solution Web-scoped will only bind the Event Handler to the list you declare.  Thanks Alex for making dig a bit deeper to further get better documentation.

Monday, November 26, 2012

CEWP Usage in SharePoint

While I absolutely loathe the term "Best Practices", it's time to dive into a topic that really hasn't been talked about but should have by now.  I'm *not* going to label this post as a "Best Practice", although I'd like to, but label it more like: this is what I do and why...

Adding Script to Pages

It's well known that most of the front-end developers favor using CEWP's to inject script into our pages.  Many well known webparts use this technique.  This is great!  We can add functionality to my pages with a small amount of work and without using SharePoint Designer.

Page Weight

What happens when you add scripts to your page using a CEWP?  This is a very much a misnomer because you really aren't adding scripts and instead are adding HTML.  CEWP's only interpret HTML and as such, they DO NOT cache any of the HTML added to the page.  To take advantage of caching these resources, you must use write the HTML correctly.  Adding <script> tags with a src attribute will tell the browser to cache your JavaScript files.  If you avoid doing this, your HTML will have to be sent to your browser each time, causing your page to load slower than it really has to.  Using a script tag correctly to call your .js file, your script will be cached by the browser and will not have to be downloaded for each page load.

Considerations

Reading over an excellent write up about page weight got me to thinking about what I've seen blogged in the SharePoint space.  Most solutions have you connect a pseudo .js file to a CEWP.  In actuality, this isn't a JavaScript file at all.  It's a file that contains HTML.  So that's quite confusing, not to mention, adds to your page weight.  The post linked above says to keep your inlined CSS or JavaScript to < 1 ~ 4 KB.  

Here's my list of considerations when adding a new CEWP to my page.
  • What will this script potentially do over the life of this application?
  • Do I think this could grow over 1 KB?
  • Does the page weight even matter for this application?
  • Will I gain anything by caching these resources?

What I Do

Mostly, I create a .html file wherever I store my assets.  I write HTML in that file.  Generally speaking it's <link> tags and <script> tags that reference my resources.  Doing so, will allow these files to be cached by the browser.  Page weight and load times are very important to me, so this is generally what I do.  However, I will write CSS and JavaScript in my .html file if I know there will be a very small amount of HTML going into that file.

Using this technique, I feel less confused overall.  When I open a .js file, I'm actually looking at JavaScript and not CSS or HTML or both.  Maybe it'll do the same for you, who knows?!?  

This is what I do though.