Client side scripts: packaged Web Part vs. Content Editor Web Part

A couple days ago, there was an awkward moment while I was working on a new project.

I was on a video conference with a customer who already had a SharePoint site set up – actually a whole application including CRM, project management, etc. And he was happy to show me that my Easy Tabs were part of his solution, and had been installed by his developer.

Naturally, I was interested to see if the script was implemented correctly, so I asked him to edit the Web Part. Surprise! Instead of an out of the box Content Editor Web Part (or Form Web Part, or PVWP, etc.), I discovered a custom Web Part, with no option whatsoever to edit or link to an external script.

The customer was not able to tell me what the developer had done, but apparently the guy had embedded the script in a custom Web Part. This is a standard practice, and you can for example see it explained in this recent post from the SharePoint Developer Team Blog  (one of my favorite SharePoint blogs of the moment btw). But for me, it was the first time to actually see it, and done to my very own script…

A glass of cognac and a couple nights of rest later, it is time for me to try and understand the respective benefits of the two techniques.

This is actually a topic I discussed six months ago with SharePoint MVP Sean Wallbridge (the discussion was already around the Easy Tabs). I submitted to him this idea of wrapping my Easy Tabs in a Web Part. At that time his advice was that I should not bother to do that, and that the CEWP approach was more convenient.

I’d be interested in hearing from others who have applied the technique described in the SharePoint Developer Team blog, to try and understand possible benefits. At this point, I don’t see any, but maybe I am missing some specific use cases. One interest of packaging the script is that if you update it on the server side the changes will apply to all the Web Parts. But AFAIK you can have the exact same effect by linking a CEWP to a central script.

Developer approach vs. User Managed Solution, what’s your take on this?

15 thoughts on “Client side scripts: packaged Web Part vs. Content Editor Web Part

  1. Pingback: Tweets that mention Client side scripts: packaged Web Part vs. Content Editor Web Part « Path to SharePoint --

  2. The primary reason for going with the custom web part method is user convenience.
    With the custom web part users can just select it from the add web part popup and they are done. Doing it as a CEWP you have to deal with instructions involving cut and pasting, hidding the web part,etc.

    • Well, not necessarily. You can link the CEWP to the script, set the display to hidden, and then add the Web Part you created to the Web Part gallery. Then it becomes available to users from the Add Web Part menu, just like the custom Web Part.

  3. I think there are a lot of reasons he did this. Chiefly I’d say it was so that the client would have to come back to him for any modification. He’s effectively locked them out of the script, no? There might be durn good reason for this. For one, if they break something and cannot get it to work the right way, and identify it the “developer” that originally set it up, he looks like the bad guy. I’ve taken to asking my customers to just send me their list views when they need a cross site list snapshot for this reason. Now I’ll just package the CEWP linked to the script. But I don’t really want to spend a lot of time explaining how it works, repeating myself and dodging scope creep on what should be a really brief fix for them. I’ll also put the script in a library everyone can obviously read but only a few folks can contribute to. This also helps them really do what they should be doing, tweaking the view of the list.

  4. From my position as a SharePoint evangelist internal to (HumongousGlobalCo.), I prefer the CEWP solution, linked to a central script. Maybe it’s because I come originally from the user side, but our position has always been to educate people on how SharePoint actually WORKS, and encourage them to embrace and extend it. I’ve seen power uses do really interesting things as a result of examining how the EasyTabs part(s) work – and that to me far outweighs the two or three times I can recall someone messing with the setup enough to actually make it stop working. It’s not like it’s hard or time-consuming to repair it, after all.

    • Richard, thanks for the note. Several people (including Sean Wallbridge) have told me that they come from the same background and share your views.

  5. I’m with Richard on this, but I suppose you’d expect that. A little education goes a long way to helping people USE SharePoint rather than just having access to it.

    Of course, there’s a third option, which is adding the scripts directly to pages using SharePoint Designer. It’s sort of a middle ground in that the access can be controlled even more than with a CEWP. It’s sort of a Middle Tier thing.


    • Middle what? 😉

      Right, the script could also be attached to the page itself. But it won’t work well for a plugin approach, like for the Easy Tabs or a cross-site snapshot, where the user needs control over where the script runs. The purpose of the post was to compare two Web Part solutions.

      It’s very interesting to read the comments, and see that the choice is based on the interaction with the users, not technical criteria.

  6. It is obviously related to “Job Security”…..

    And we all know that “compiled code” far outperforms interpreted Javascript, so adding some C# will speed things up…. 😉

  7. Pingback: Client side scripts: packaged Web Part vs. Content Editor Web Part … | Web Scripts Maniacs

  8. The advantage is now when an end-user or site owner decides to add a web part to their page they don’t have to know about the CEWP part, what it is, how to use it, etc. People are more scared of the word “Script” than we think. By adding it to the page with simple prompts on the RH side I imagine it streamlines the process for the end user and gives them the confidence to be able to execute on their own.

    Further, as an installed web part it would be easier to get a count of how many folks are using it and ensure that key functionality can be upgraded when the time comes. CEWP parts are harder to track I imagine.

    For the power user or the site owner looking to extend functionality this will be incredibly frustrating but then they can always just do it themselves.

    (I’ve decided to ignore the lock-in reasoning and assume that developers are always working in the best interest of the customer since I don’t know the person and would rather not make assumptions)

    • Just noticed Christophe’s above comment on the page gallery which may invalidate my argument. Does that provide the same ease of data entry or will folks still be copying / pasting from source?

      • Once the CEWP is saved back to the gallery, users don’t need to do any copy/paste anymore. It works the same as the packaged Web Part, except that the users still have the option to edit it.
        I didn’t know you could get a count of how many folks are using a given Web Part. Interesting.

        • On the “counting” piece – after doing some further digging on how best to quantify usage it looks rather expensive so you wouldn’t want to do it much and I’m not sure how much adding it to the central server would improve your metrics vice a page gallery. Here’s a link to a thread about how you might be able to get better item level metrics:

          There’s still value in centralizing management from a configuration management perspective but not what I had hoped SharePoint could do… perhaps a future feature request 🙂

          That said – if you’re using a CEWP you could always just hook into a 3rd party counter or metrics package that would probably get you more fidelity so… perhaps disregard everything after “hello” hehe.

  9. Well in my case we are not allowed to use SharePoint designer nor are we allowed to add customer 3rd party web parts. So using your code in the CEWP works fantastic. It also allows for me to make edits if needed to customize it for a given site. I think there are advantages of both sides but if you put yours in a custom web part I would just look to others for support. So I am hoping you continue your creative work and sharing with others and not embed them into custom web parts.

Comments are closed.