# Wednesday, 03 June 2009

I’ve been a fan of SharePoint since WSSv2 first came out.  Development on the platform wasn’t all that great though.  Things changed in a big way with WSSv3, and had I known just how easy things had become, I would have started this project a long time ago.

After being introduced to Trac a few years ago, I immediately set up a site and linked it to my private repository.  Having a wiki and source browser tied together can be immensely useful.  The one thing I’ve always had an issue with regarding Trac is how it supports documents (barely at all).  You can attach them to pages or put them in your repository, that’s it.  SharePoint, however,  was designed for document management; it just doesn’t have a way to browse a source repository.  I decided to fix that.

After fetching SharpSvn I set about figuring out how to get it integrated with SharePoint.  Eventually things came together, and I ended up with this:

wss-svn-browser

That wasn’t enough though.  I needed to be able to view those files too, and of course I wanted syntax highlighting.  I don’t remember how I found this, but it works great.  A bit more tinkering and…

wss-svn-file

Just need to do a bit of clean up and finish making the UI seamless with SharePoint.

posted on Wednesday, 03 June 2009 15:08:00 (Central Daylight Time, UTC-05:00)  #    Comments [0] Trackback
# Thursday, 22 January 2009

So a dev buddy popped a question in IRC the other day.  He was trying to host an ad/offer thing inside of an iframe, but the offer checked for this and redirected the top page to itself.  He had been wracking his brain trying to work around this, and it looked like an interesting problem, so I stepped up to the plate.

First we attempted to simply overwrite location.replace with an empty function.  This seemed to work on IE but did nothing on FF3.  It also became apparent that this method would fail as a subsequent refresh gave us different javascript that simply changed the location.href.  FAIL.

I did a bit of googling on the issue and stumbled across a forum post suggesting the use of onBeforeUnload on the parent page.  I played around with this idea, getting mixed results, but since there seemed like no other way, I dug a bit deeper.  I was trying to do this by hand, with no libraries, and decided to bring in a little help since I didn't care to handle all the x-browser event nonsense.  I loaded up prototype.js and reworked my code to use it.  The following emerged:

function windowUnload(evt) {
var ifr = $('ifr');

if (ifr == evt.element()) {
evt.stop();
}
}

Event.observe(window, 'unload', windowUnload);
$('ifr').observe('unload', windowUnload);

The id 'ifr' is the iframe holding the offer/ad.  This also manages to prevent any unload checks that the embedded page might popup.

Enjoy!

posted on Thursday, 22 January 2009 14:45:01 (Central Standard Time, UTC-06:00)  #    Comments [2] Trackback
# Monday, 17 September 2007

The ASP.NET AJAX UpdateProgress control is rather limited.  It only shows up for UpdatePanels and then only for one at a time.  This was highly annoying, since I needed it to display for the CascadingDropDown in particular.  After a few failed attempts, I found that it is very easy to create your own control that will work for any and all requests.

The secret for this method is found in Sys.Net.WebRequestManager.  This object contains two methods:  add_invokingRequest and add_completedRequest.  Using these two events, we can set a short timeout, and using a ModalPopupExtender, show a progress alert for every background action.

var wrm = Sys.Net.WebRequestManager;

wrm.add_invokingRequest(BeginRequest);
wrm.add_completedRequest(EndReqest);

function BeginRequest(sender, args)
{
setTimeout('ShowProgress()', 800);
}

function ShowProgress()
{
// show the modal
}

function EndRequest(sender, args0
{
// hide the modal
}

I leave the rest as an exercise for the reader.

posted on Monday, 17 September 2007 16:25:15 (Central Daylight Time, UTC-05:00)  #    Comments [0] Trackback