Blog of an overweight SharePoint addict

Tue 24 Nov 09

Should I change the name?

To once a month updates?

I haven’t stopped since I got back from SPC and have been dashing around between clients working on SharePoint 2007 issues. Doesn’t anyone understand I want to play with SharePoint 2010 now? Or more to the point, I need to upskill in some areas very quickly to get the most of SP2010 and all the goodness it brings.

Looking at whats coming in SP2010, I honestly think the IT Pro’s have got it easy.. You guys just have to learn one new application, Us Devs have to learn at least 2, SP2010 and Visual Studio 2010!

Then on top of that, we have an updated object model to contend with, along with a brand new object model in the form of the SharePoint Client OM!

Add to this the requirements to use XSLT for almost every list view in SP2010, SPLinq (Call it SPlinq, MS hate that!!), Silverlight and a lot more Javascript than before, all adds up to a lot of skill-up time!

So here’s to spending many evenings and train journeys in front of Visual Studio, playing with Silverlight 101 and all the new Sharepoint tools that now come out of the box with VS!

I’m booked up in December as solidly as November was, so i wouldn’t expect too many posts on here just yet, although I am planning to extend the piece I wrote on KPI’s to give more ideas and hopefully present on this at a SUG do in the early new year.

Regards

Paul.

Thu 7 May 09

Using JQuery to remove Linked List Items Hyperlinks – Revisited

Filed under: JQuery, Javascript, Programming, SharePoint, Uncategorized — Reginald @ 11:36 am

So in an earlier post I talked about using JQuery to remove the A tag that is automatically included in the rendering of a linked list item in display mode.

I really liked this solution as it avoided having to go to the lengths of writing a custom field to solve this and can be targetted at a single page, or a whole site by embedding the code in the Master Page.

So, anyway, it’s worked quite nicely at the client that instigated the investigation, so I decided to re-use the code for a new client. This has functioned perfectly, right up to the point where they used a list view with a Group by in the selected view.

So, why does this cause different behaviour? Well the answer is in how the ListView web part handles the hiding and revealing of the grouped data. When you click on the expand link, the page performs a partial postback to SharePoint to get the missing data, before returning a block of HTML to display.

As this happens during the partial postback, the already registered code on the page doesn’t run a second time as the jQuery event $(document).ready doesn’t trigger again.

I tried various methods before placing a post on the EndUserSharePoint.com StumpThePanel Q&A forum in the hope that “JQuery in SharePoint” god Paul Grenier would be able to answer my timing issues, which he did very nicely!

So how did we resolve it.. The answer is to replace the MicroSoft function that handles the posted back data within the listview ExpGroupRenderData() with a JQuery version.

function ExpGroupRenderData(htmlToRender, groupName, isLoaded) {
	$("#tbod"+groupName+"_").attr("isloaded",isLoaded)
		.html(htmlToRender)
		.show("fast",HideLinkedListItems());
}

HideLinkedListItems() is the previously created function to strip the A tag frm linked list items, wrapped in a function wrapper so that it can be called frm either the update, or the Document.ready as per the original post.

The result, expanding the listview now presents the list view items, nicely stripped of their links.

I hope this helps someone achieve the same..

Paul.

Wed 22 Apr 09

Overriding Core.JS functions

Filed under: Javascript, Programming, SharePoint, Troubleshooting — Reginald @ 2:30 pm

A client of mine recently required adding an additional E-Mail link adding to the Item Drop Down menu that drops off of the ECB menu within Document Libraries and Lists.

Now this functionality is provided by the function AddSendSubMenu(m,ctx) within Core.JS. Editing this file is NOT SUPPORTED (You all know this by now I’m sure!). So what to do? Well the answer is make use of Javascript’s natural override.. I.e. If you declare a function twice, the last declaration is the one that gets used.

So, Seems simple huh? We copy the function we want out of Core.JS and stick it into our own NewSendToMenu.js file in /TEMPLATE/LAYOUTS/1033

We then place a standard little script tag into the Head of the Master Page and bobs your uncle, the code gets loaded quite happily on each page.

Or does it? Well yes it does always get loaded.. I proved this by putting a document.write(”Hello World”) in front of the function and this got displayed every time without fail, And yet my customisations weren’t there.

I remembered reading somewhere that Core.JS has a habit of hanging around and getting executed last, My original method using the SharePoint:ScriptLink tag seemed to support this, so I dropped back to using the standard Script tags.. same problem though..

I then stumbled across a small article on the MSDN forums that pointed out the use of the Defer tag in the Core.JS script block. (You can see this if you view the page source in IE..) This means that the execution of Core.JS is deferred until the rest of the page is loaded, thus overriding my own override..

So the solution appears, Declare my script lower down the page than the Core.JS, and tag my Script block with the Defer option also.. This appears to execute my code AFTER core.js has completed.

Now, I’m not 100% how often this will be the case.. looks like this may need some load testing, but I think it’s fair to say that if one script is deferred higher up the page, than another lower down, they should be deferred into the same execution order that they met during page load?

Or am I being too simplistic? Never mind.. for now this works and resolves the client issue!

Paul

Powered by WordPress