Not enough to read?

Posted in Uncategorized by Kris Gray on April 28th, 2007

Try out these guys, who read an obscene amount of blogs and post the cream of the crop on their own blogs.

And of course which is where I get about 90% of my traffic.

No comments

Javascript and CSS Compression in MSBuild

Posted in development,javascript by Kris Gray on April 20th, 2007

Want to compress your CSS and Javascript files during your build process? Here is what you need.

Download CSSTidy, and add the executable somewhere on your build machine.

Download and install the MSBuild Community Tasks, or you can do just the Jazmin JSCompress task, though I didn’t do that so I don’t have any source XML for that.

To be clean, I added a Property for the location of CssTidy


Also I registered the MSBuildCommunityTasks

<!-- Required Import to use MSBuild Community Tasks -->
<Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\

Then, build a list of all the files you want to compress.
<CssFiles Include="$(websitedir)\**\*.css"/>
<ScriptFiles Include="$(websitedir)\**\*.js"/>

$(websitedir) is just a variable for where the website is, obviously I could have used c:\inetpub\wwwroot or whatever instead.

Then I build two tasks, one that calls CssTidy…
<Target Name="compress_css">
<Attrib Files="%(CssFiles.FullPath)" ReadOnly="false"/>
<Exec Command="$(CssTidy) %(CssFiles.FullPath) %(CssFiles.FullPath) --template=highest" />

If your not familiar with the %() syntax, this causes MsBuild to iterate over each item in the CssFiles collection and run this tag for each instance. Otherwise I would get a semi-colon delimited list which nothing handles that well.

The Attrib tag makes everything write-able thus the ReadOnly=”false” attribute, this didn’t seem to be an issue for CssTidy, but it was for JSCompress and I put it here just incase it becomes an issue one day.

The Exec Line executes the CssTidy program, with the FullPath of the searched file (this is meta-data of the item), its included twice to represent the input and output. The –template=highest portion just says do your absolute best!

Then the you add one for JSCompress…
<Target Name="compress_js">
<Attrib Files="%(ScriptFiles.FullPath)" ReadOnly="false"/>
<JSCompress Files="%(ScriptFiles.FullPath)"></JSCompress>

Attrib we’ve been over, this is really important here, as JSCompress was failing on readOnly files.

Then I tell it to run the JSCompress tag for each of the ScriptFiles. I feel like I’m explaining exactly what your seeing and already understanding. I hate it when people do that.

Then you need to call these targets.
<CallTarget Targets="compress_css"/>
<CallTarget Targets="compress_js"/>

Not much to it. Hopefully this helps you bring quick loading times to all the web surfers of the world.


Jason Haley, you suck!

Posted in Uncategorized by Kris Gray on April 18th, 2007

Seriously, you stink, your blog is ugly, and I’ve enjoyed your daily reading updates for far to long.

Its likely the rest of you are curious why I’m using my blog to Flame and smear Jason Haley. Well, if you didn’t notice, first read this post…

Were through Jason Haley

Then check out Jason’s post the following day.

04/15/2007 Interesting Finds

Hmmm, so you flame him, then you get on his daily blog read list. Hey I can do that! So if you ever read this Jason, you can bite me! Which shouldn’t be all that unpleasant after that kick ass salsa recipe you helped me find.

To continue the trend, if you flame me, I’ll add you to my OPML!


Advancing Javascript with libraries + 1

Posted in Uncategorized by Kris Gray on April 18th, 2007

In a short but sweet post over at Ajaxian, Dion Almaer interviewed John Resig, of Mozilla and jQuery about Javascript Libraries, and the reasons for said libraries.

  • Avoid repetition
  • In JavaScript: Distance from browser differences
  • In C: stdlib distances itself from the platform differences

First of all, whats up with #3? Secondly, I’m totally digging points #1 and #2 in the current construction of the library at eProject. Refactoring old code to new code thats twice as good makes me feel so good, like some kind of Ego Building Sundae.

So what do I have to add? That #3 should have been easy test injection.

We’ve been struggling how to implement JSUnit at work for quite some time, testing a function on an ASPX page just isn’t very practical, and a lot of the functions in the old files were intended for a specific usage. Yet, once all the logic from the old pages has been moved to the library, it has been written with re-usability in mind, and writing a JSUnit test page turns out to be just another page in the system.

No comments

Dynamic Package Inclusion

Posted in Uncategorized by Kris Gray on April 18th, 2007

If you don’t know much about the Dojo toolkit, its a vast Javascript library with some very cool framework features. One feature I liked was the ability to add packages to a page depending on your need, so if you needed ajax, you could add the following script.


This way you only get the bits necessary per page, this doesn’t make sense for something as small as Prototype but as I was building the JS Library for eProject it made sense to include this feature since we have so many packages available.

I’ve just recently been running into a problem implementing a Dojo style dynamic package inclusion system in our companies new JS Library. I didn’t want to dig into the Dojo source code to much, so I implemented a rather crude solution of taking the string to require, converting it to a file system path and appending a script element with that path to the page.* would become dojo/io.js

This was a really simple solution and worked great in FireFox, but in IE (eProject is only concerned with these two browsers at the moment) , there were loading issues. It appears that unless the file is cached, it took its own sweet ass time loading. Annoyingly this made it seem that all my unit tests were passing when in fact, they only were passing because the dynamically included packages were already cached in most cases.

So after some digging into the dojo source a bit, I’ve discovered how they avoid this irritating little “feature”. The dojo toolkit uses an XML HTTP GET (for cache support of course) call to retrieve the contents of the file from the server, and eval()’s the returnText.

Ever since I read this, I’ve been trying to avoid it, it means I have to write custom XML HTTP Logic in the base framework level, and I have to do eval()’s on large blocks of text, but because I don’t fully yet understand why IE isn’t loading the script files as the DOM elements are being added to the DOM, I’ll need to implement this for now. It does give me the advantage of knowing that any logic I do include via the package inclusion system, will be available after I have exited the call for that package.

If you have any idea behind the lower level occurrences here, please share. Till then, I got some re-writing to do.

No comments

Next Page »