Released: JsTrace.MVC

I just released the JsTrace add-on JsTrace.MVC as a NuGet package.

What is it?  It's a way to automatically proxy JsTrace messages from client-side JavaScript to your MVC application.

Basically, when you add this package, you get the following Area added to your ASP.NET MVC project:


The JsTraceController has a single "Index" method that receives a JsTraceMessage object.  All that contains is the module, level and message sent from the JavaScript side.
Given the following javascript:

var tracer = new Trace('TestModule');
tracer.error('testing: error message');

The default implementation just outputs to the console using Debug.WriteLine:

   JsTrace >> [error] Module 'TestModule' : testing: error message

All you need to do is use the included HtmlHelper extension method like this, depending on your syntax:

<%: Html.RenderJsTraceProxy() %>

or

@Html.RenderJsTraceProxy()

By default, the rendered script will proxy only messages that pass the “switch test”. If you pass “true” in the RenderJsTraceProxy(), it will send all of them, which might be a bit crazy in production.

The script uses the jQuery $.ajax() method to post a JSON object to the server asynchronously -- ignoring success or error as well.

I may have a follow up version that has more options for the Proxy, like being able to pass a predicate-style (returns boolean) method to determine whether or not to send the message to the server.  This way you could customize the logic yourself.

Check it out, and let me know what you think!

T

JsTrace 1.1.1 released

So, I released a new version of the JsTrace project.

This version basically includes rewriting things to be a little more "proper" in the JavaScript side of things. 

1. I removed things like the "with" keyword (reimplemented just using basic closure technique)
2. Turned on/Fixed a lot of JSHint restrictions (though I still don't dig the "use one var statement" thing, so I don't follow that – it's totally unnecessary in my opinion).
3. Updated the Intellisense comments so that we have as much info in client code as possible
4. Updated source code to have a test project and the NuGet package generation in it.

So, if you're using the NuGet package, you'll just get the update automatically, otherwise, go snag it on Codeplex: http://jstrace.codeplex.com

Happy Debugging!

Tom

Released: JsTrace - My JavaScript Diagnostics Module (NuGet Package too!)

I've been planning on this for a while, but, after my original post post about JsTrace, I wanted to make it easier for people to get to and use.

So, first of all, I added JsTrace to CodePlex.

Then, I wrote some pretty decent documentation for it.

Finally, I published it as a NuGet Package.

Use it at will and spread the word!

JavaScript Globalization

I am leading a project that is now going to go from running in the US to running across the world over the next 6+ months.

It currently uses a lot of different tech: ASP.NET MVC3, HTML5, jQuery, jQuery UI, KnockoutJs (w/Mapping), jQuery Templates, jQuery DataTables, EF4 and a host of other home-grown and one-off type technologies.

So, I started browsing the usual suspects, especially a previously bookmarked Scott Hanselman blog post (suspiciously a 7-month-old "part 1" with no "part 2" yet *holds breath*).

Well, the most confusing part I have run across so far is how to handle JavaScript and jQuery globalization.  There was one project by Microsoft that was donated/accepted/rejected by the jQuery folks (sounds familiar... jQuery Templates had the same problem) which, apparently went through a few renamings (one, two, three), the last of which was a renaming to "Globalize", total api change and removal of any dependency on jQuery (not sure if there was ever one, but didn't bother to get into it).

Confusingly, this library (not a plugin anymore) is maintained/developed by the jQuery UI team now, even though there's no dependency.

So, apparently, the supported(?), in-development code is now the "Globalize" library whose wiki is here (on the jQuery UI site, where else? ... O_o)

Hope that helps save someone else some time.

Modular JavaScript Tracing

UPDATE (2/18/2012) -- I have moved the source code to Codeplex

Much to my chagrin, I have been doing a LOT of JavaScript debugging lately.  In order to handle multple "levels" of debugging information, I started using Ben Alman’s “ba-debug” javascript library (http://benalman.com/projects/javascript-debug-console-log/).

ba-debug is really nice, but it's unfortunately "global", meaning that the setLevel() method and all the messages are switched with a single global switch.  After using it for a while, I decided I needed something more modular.So, I took his library and modified it heavily.

Being a fan of the .NET System.Diagnostics library, including the TraceSource/SourceSwitch objects, I decided to emulate that somewhat. result is the Trace file I’m including here.

Here’s a brief overview of how to use it.

(NOTE: When I say "module", I mean a closure/module as defined by this -- and many other-- article: www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth)

The idea is that, in some sort of module, you do this:

   var _trace = new Trace('ModuleName');

Then, when you want to trace out any level of diagnostics, you do:

   _trace.debug('ItemsListView - redrawing...');

Supported methods are: error, warn, info, debug, log
The current default level is “error” for all Trace objects.

If you want to increase that level for a particular module, you insert a line like this into your web page:

   Trace.traceLevel('ModuleName', Trace.Levels.log);

Trace.Levels contains all the method names and “off” as options.

Additionally, I continue the functionality that ba-debug gives you so you can set a callback function for Trace messages like this:

    Trace.setCallback(function (args) {
        // do something with the arguments array here.
    },
    true, // force it
    50); //  give me the last 50 at most 

Parameters:

1. A method that receives an array of the arguments that were passed to the trace message (the level should be the first argument in the array).  Pass null to turn it off
2. Boolean on whether or not to “force” the callback.  If this is true, it will always call the callback for every message.  Otherwise, it will only call the callback if the browser doesn’t support the “window.console.log” method (at the very least).
3. A limit to the number of messages to be given up front.  Since messages could have accumulated before you call the callback, there may be a flood of messages right away when you set the callback up, so this will stop you from getting too many messages in the beginning.

The 2nd and 3rd parameters are both optional.

The callback will be called for every existing message (up to the optional "limit") and for all subsequent trace messages.  Note also that the callback does NOT get filtered, so it receives all trace messages.

If there is any expressed interest, I can go over the implementation of the object in detail as well in a follow-up post.

T

Download the whole file here: