Why jQuery Plugins Use String-Referenced Function Invocations

by Jon Davis 25. September 2012 10:52

Some time ago (years ago) I cobbled together a jQuery plug-in or two that at the time I was pretty proud of, but in retrospect I’m pretty embarrassed. One of these plugins was jqDialogForms. The embarrassment was not due to its styling—the point of it was that it could be skinnable, I just didn’t have time to create sample skins—nor was the embarrassment due to the functional conflict with jQuery UI’s dialog component, because I had a specific vision in mind which included modeless parent/child ownership, opening by simple DOM reference or by string, and automatic form serialization to JSON. Were I to do all this again I would probably just extend jQuery UI with syntactical sugar, and move form serialization to another plugin, but all that is a tangent from the purpose of this blog post. My embarassment with jqDialogForms is with the patterns and conventions I chose in contradiction to jQuery’s unique patterns.

Since then I have abandoned (or perhaps neglected) jQuery plugins development, but I still formed casual and sometimes uneducated opinions along the way. One of the patterns that had irked me was jQuery UI’s pattern of how its components’ functions are invoked:

$('#mydiv').accordion( 'disable' );
$('#myauto').autocomplete( 'search' , [value] );
$('#prog').progressbar( 'value' , [value] );

Notice that the actual functions being invoked are identified with a string parameter into another function. I didn’t like this, and I still think it’s ugly. This came across to me as “the jQuery UI” way, and I believed that this contradicted “the jQuery way”, so for years I have been baffled as to how jQuery could have adopted jQuery UI as part of its official suite.

Then recently I came across this, and was baffled even more:

http://docs.jquery.com/Plugins/Authoring

Under no circumstance should a single plugin ever claim more than one namespace in the jQuery.fn object.

(function( $ ){

  $.fn.tooltip = function( options ) { 
    // THIS
  };
  $.fn.tooltipShow = function( ) {
    // IS
  };
  $.fn.tooltipHide = function( ) { 
    // BAD
  };
  $.fn.tooltipUpdate = function( content ) { 
    // !!!  
  };

})( jQuery );

This is a discouraged because it clutters up the $.fn namespace. To remedy this, you should collect all of your plugin’s methods in an object literal and call them by passing the string name of the method to the plugin.

(function( $ ){

  var methods = {
    init : function( options ) { 
      // THIS 
    },
    show : function( ) {
      // IS
    },
    hide : function( ) { 
      // GOOD
    },
    update : function( content ) { 
      // !!! 
    }
  };

  $.fn.tooltip = function( method ) {
    
    // Method calling logic
    if ( methods[method] ) {
      return methods[ method ].apply( this, Array.prototype.slice.call( arguments, 1 ));
    } else if ( typeof method === 'object' || ! method ) {
      return methods.init.apply( this, arguments );
    } else {
      $.error( 'Method ' +  method + ' does not exist on jQuery.tooltip' );
    }    
  
  };

})( jQuery );

// calls the init method
$('div').tooltip(); 

// calls the init method
$('div').tooltip({
  foo : 'bar'
});

// calls the hide method
$('div').tooltip('hide'); 
// calls the update method
$('div').tooltip('update', 'This is the new tooltip content!'); 

This type of plugin architecture allows you to encapsulate all of your methods in the plugin's parent closure, and call them by first passing the string name of the method, and then passing any additional parameters you might need for that method. This type of method encapsulation and architecture is a standard in the jQuery plugin community and it used by countless plugins, including the plugins and widgets in jQueryUI.

What baffled me was not their initial reasoning pertaining to namespaces. I completely understand the need to keep plugins’ namespaces in their own bucket. What baffled me was how this was considered a solution. Why not simply use this?

$('#mythingamajig').mySpecialNamespace.mySpecialFeature.doSomething( [options] );

To see about proving that I could make both myself and the “official” jQuery team happy, I cobbled this test together ..

(function($) {
    
    $.fn.myNamespace = function() {
        var fn = 'default';
        
        var args = $.makeArray(arguments);
        if (args.length > 0 && typeof(args[0]) == 'string' && !(!($.fn.myNamespace[args[0]]))) {
            fn = args[0];
            args = $(args).slice(1);
        }
        $.fn.myNamespace[fn].apply(this, args);
    };
    $.fn.myNamespace.default = function() {
        var s = '\n';
        var i=0;
        $(arguments).each(function() {            
            s += 'arg' + (++i).toString() + '=' + this + '\n';
        });
        alert('Default' + s);
        
    };
    $.fn.myNamespace.alternate = function() {
        var s = '\n';
        var i=0;
        $(arguments).each(function() {            
            s += 'arg' + (++i).toString() + '=' + this + '\n';
        });
        alert('Alternate' + s);
        
    };

    $().myNamespace('asdf', 'xyz');
    $().myNamespace.default('asdf', 'xyz');
    $().myNamespace('default', 'asdf', 'xyz');
    $().myNamespace.alternate('asdf', 'xyz');
    $().myNamespace('alternate', 'asdf', 'xyz');
    
})(jQuery);

Notice the last few lines in there ..

    $().myNamespace('asdf', 'xyz');
    $().myNamespace.default('asdf', 'xyz');
    $().myNamespace('default', 'asdf', 'xyz');
    $().myNamespace.alternate('asdf', 'xyz');
    $().myNamespace('alternate', 'asdf', 'xyz');

When this worked as I hoped I originally set about making this blog post be a “plugin generator plugin” that would make plug-in creation really simple and also enable the above calling convention. But when I got to the some passing tests, adding a few more tests I realized I had failed to notice a critical detail: the this context, and chainability.

In JavaScript, navigating a namespace as with $.fn.myNamespace.something.somethingelse doesn’t execute any code within the dot-notation. Without the execution of functional code, there can be no context for the this context, which should be the jQuery-wrapped selection, and as such there can be no context for the return chainable object. (I realize that it is possible to execute code with modern JavaScript getters and setters but all modern browsers don’t support getters and setters and all commonly used browsers certainly don’t.) This was something that I as a C# developer found easy to forget and overlook, because in C# we take the passing around of context in property getters for granted.

Surprisingly, this technical reasoning for the string-based function identifier for jQuery plug-in function invocations was not mentioned on the jQuery Plugins documentation site, nor was it mentioned in the Pluralsight video-based training I recently perused. It seemed like what Pluralsight’s trainer was saying was, “You can use $().mynamespace.function1()” but that’s obscure! Use a string parameter instead!” And I’m like, “No, it is not obscure! Calling a function by string is obscure because you can’t easily identify it as a function reference distinct from a parameter value!”

The only way to retain the this context while removing the string-based function reference is to invoke it along the way.

$().myNamespace().myFunction('myOption1', true, false);

Notice the parenthesis after .myNamespace. And that is a wholly different convention that few in jQuery-land are used to. But I do think that it is far more readable than ..

$().myNamespace('myFunction', 'myOption1', true, false);

I still like the former, it is more readable, and I remain unsure as to why the latter is the accepted convention over the former, but my guess is that a confused user might try to chain back to jQuery right after .myNamespace() rather than after executing a nested function. And that, I suppose, demonstrates how the former pattern is contrary to jQuery’s chainability design of every().invocation().just().returns().jQuery.

Currently rated 5.0 by 2 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , ,

Javascript

AJAX Deferred Loader for ASP.NET

by Jon Davis 11. April 2009 14:19

Here’s a simple ASP.NET control that takes a URL parameter, renders a placeholder on the page, and uses Javascript to “lazy-load” the view content for that placeholder area. It basically does what my sprinkle.js did a long while back, but it takes advantage of ASP.NET controls and jQuery simplicity with its load() function.

It also has self-refreshing. This is good for updating a section of a page with progress information, without refreshing the entire page.

To use it,

  1. Compile the source code (below) to your Web Application project’s assembly, or create an assembly and reference the assembly in your project. You should put this control in its own namespace or in a “.Controls” namespace because of #2 below.
  2. Add a header to any page that would use it to explicitly import all controls under the namespace for which you’re using this control.
    <%@ Register Assembly="MvcApplication1" Namespace="MvcApplication1.Controls" TagPrefix="demo" %>
  3. Be sure jQuery is referenced on the page, ideally in the <head> tag. If you’re using Web Forms and <head runat=”server”>, the process of getting it in there is a little complicated but that’s a different topic. I’m using ASP.NET MVC and I just put it in the Master page. Ultimately, jQuery needs to be loaded before anything else loads, that’s your objective, so you figure it out.
    <html><!-- ... -->
    <head>
      <!-- ... -->
      <script language="javascript" type="text/javascript" src="../../Scripts/jquery-1.3.2.min-vsdoc.js"></script>
      <script language="javascript" type="text/javascript" src="<%=ResolveUrl("~/Scripts/jquery-1.3.2.min.js") %>"></script>
      <!-- ... -->
    </head>
    <body><!-- ... -->
    </body>
    </html>
  4. Now you can reference inline. Note the “RefreshInterval” setting, which is an integer that indicates, in seconds, how often to refresh the region. In this sample, it updates every two seconds. Note also that the HTML that comes back from the referenced URL can include script markup that cancels the interval, such as if a process has completed.
     
    <demo:AjaxDeferredView runat="server" ViewUrl="~/Deferred" RefreshInterval="2">
        <asp:Panel runat="server">Please wait ...</asp:Panel>
    </demo:AjaxDeferredView>
  5. This is what gets outputted with the above tag. Note the “undefined, undefined” are there because the PostData and the Callback optional properties are not set on the control tag.
    <div id="ctl00_MainContent_ctl00">
        <div>
    		Please wait ...
        </div>
    </div>
    <script language="javascript" type="text/javascript"><!--
    $(document).ready(function() {
    	window['ctl00_MainContent_ctl00_interval'] = setInterval(function() {
    		$('#ctl00_MainContent_ctl00').load('http://localhost:5577/Deferred', undefined, undefined);
    	}, 2000);
    	$('#ctl00_MainContent_ctl00').load('http://localhost:5577/Deferred');
    });
    --></script>
  6. And finally, what the end user will actually see is a momentary, split-second, or too-fast-to-see placeholder being swapped out for the content at the loaded URL.
  7. Here’s an example of how to clear that interval in the sample ~/Deferred view that comes back, such as if a process has completed, or in this case after the 5th hit (from any visitor). This sample might be the actual page that is invoked from the AJAX call.  Note the ClearParentInterval control, and that the logic that changes its ClearInterval property precedes its position on the page.
    <%@ Page Title="" Language="C#" Inherits="System.Web.Mvc.ViewPage" %>
    <%@ Register Assembly="MvcApplication1" Namespace="MvcApplication1.Controls" TagPrefix="demo" %>
    <% Response.Cache.SetCacheability(HttpCacheability.NoCache); %>
    Welcome to my deferred content. 
    <%
        
        //live counter
        var i = (int)(Context.Application["defercnt"] ?? 0);
        i++;
        Context.Application["defercnt"] = i;
        %><%=i %>
        
    <% if (i >= 5) // shutdown interval after 5 views
     {
         ClearIntervalControl.ClearInterval = true;
     } %>
     <demo:ClearParentInterval runat="server" ID="ClearIntervalControl" />
    

    This outputs the following when ClearInterval is set to true. The point of the example is in the ID’ing of the <span> tag and in the <script> tag’s contents. It basically walks up the DOM tree by one parent to get the placeholder’s ID in the DOM, then tacks on “_interval” and assumes that to be the name of the interval (which it is).
    <div>Welcome to my deferred content. 5</div>
        
    <span id="ClearIntervalControl">
    </span>
    <script type="text/javascript" language="javascript">
    	var ClearIntervalControl_ClearIntervalParentRef = $('#ClearIntervalControl').parent().attr('id') + '_interval';
    	if (window[ClearIntervalControl_ClearIntervalParentRef]) {
    		clearInterval(window[ClearIntervalControl_ClearIntervalParentRef]);
    	}
    </script>
    

Here’s the control source:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;

namespace MvcApplication1.Controls
{
    public class AjaxDeferredView : System.Web.UI.Control
    {
        protected override void OnInit(EventArgs e)
        {
            if (string.IsNullOrEmpty(ContainerTag))
                ContainerTag = "div";
        }

        protected override void Render(HtmlTextWriter writer)
        {
            writer.WriteLine();
            writer.WriteBeginTag(ContainerTag);
            writer.WriteAttribute("id", ClientID);
            writer.Write(">");
            base.Render(writer);
            writer.WriteEndTag(ContainerTag);
            writer.WriteLine();
            writer.WriteLine("<script language=\"javascript\" type=\"text/javascript\"><!--");
            writer.WriteLine("$(document).ready(function() {");
            if (RefreshInterval > 0)
            {
                writer.WriteLine("\twindow['" + this.ClientID + "_interval']"
                    + " = setInterval(function() {");
                writer.WriteLine("\t\t$('#" + this.ClientID + "').load('"
                    + ResolveFullUrl(this.ViewUrl) + "', " 
                    + GetDataArg() + ", " + GetCallbackArg() + ");");
                writer.WriteLine("\t}, " + RefreshInterval * 1000 + ");");
            }
            writer.WriteLine("\t$('#" + this.ClientID + "').load('"
                + ResolveFullUrl(this.ViewUrl) + "');");
            writer.WriteLine("});");
            writer.WriteLine("--></script>");
        }

        [PersistenceMode(PersistenceMode.Attribute)]
        public object PostData { get; set; }

        [PersistenceMode(PersistenceMode.Attribute)]
        public string Callback { get; set; }

        [PersistenceMode(PersistenceMode.Attribute)]
        public string ViewUrl { get; set; }

        [PersistenceMode(PersistenceMode.Attribute)]
        public string ContainerTag { get; set; }

        [PersistenceMode(PersistenceMode.Attribute)]
        public int RefreshInterval { get; set; }

        private string GetDataArg()
        {
            if (PostData == null) return "undefined";
            // todo: convert complex class to JSON
            return PostData.ToString();
        }

        private string GetCallbackArg()
        {
            if (string.IsNullOrEmpty(Callback)) return "undefined";
            return Callback;
        }

        private string ResolveFullUrl(string url)
        {
            var ret = new Uri(Request.Url, Page.ResolveUrl(url));
            return ret.ToString();
        }

        private HttpResponse Response
        {
            get { return HttpContext.Current.Response; }
        }

        private HttpRequest Request
        {
            get { return HttpContext.Current.Request; }
        }
    }

    public class ClearParentInterval : Control
    {
        protected override void OnInit(EventArgs e)
        {
            base.OnInit(e);
            if (string.IsNullOrEmpty(ContainerTag))
                ContainerTag = "span";
        }
        protected override void Render(HtmlTextWriter writer)
        {
            writer.WriteBeginTag(ContainerTag);
            writer.WriteAttribute("id", this.ClientID);
            writer.WriteLine(">");
            base.Render(writer);
            writer.WriteEndTag(ContainerTag);
            writer.WriteLine();
            if (ClearInterval.HasValue && ClearInterval.Value)
            {
                writer.WriteLine("<script type=\"text/javascript\" language=\"javascript\">");
                writer.WriteLine("\tvar " + ClientID + "_ClearIntervalParentRef = $('#" + this.ClientID +
                                 "').parent().attr('id') + '_interval';");
                writer.WriteLine("\tif (window[" + ClientID + "_ClearIntervalParentRef]) {");
                writer.WriteLine("\t\tclearInterval(window[" + ClientID + "_ClearIntervalParentRef]);");
                writer.WriteLine("\t}");
                writer.WriteLine("</script>");
            }
        }
        [PersistenceMode(PersistenceMode.Attribute)]
        public string ContainerTag { get; set; }

        public bool? ClearInterval { get; set; }
    }
}

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: ,

Web Development

New Javascript Library: jqDialogForms

by Jon Davis 5. January 2009 02:52

(Note: If you link to this blog entry, please use the URL: http://www.jondavis.net/codeprojects/jqDialogForms/ which only temporarily links back to here.)

I'm releasing a v1.0 v1.1 beta build of jqDialogForms, a DHTML-based dialog windows library based on jQuery and jqDnR. This is something I started to build during my free time at my last job (it was never used there) and then continued development and completed it on my own (at home). Since I'm no longer at the job where it would have been useful had it been completed there, I do not have a lot of real-world samples to demonstrate here, but I'm releasing it now in hopes that it can continue to evolve.

There are other libraries out there that produce dialog windows that are completely modal. Modal dialogs are important, but I quickly ran into problems when, for example ...

  • A dialog window spawns a child dialog window
  • I want to see behind the child's parent's window (move the window)
  • I want to open multiple dialog windows at once
  • I'm using any modern browser, including IE 7 in quirks mode
  • Dialog windows are very large, and users are browsing with small monitors or browser windows
  • The user has scrolled down beyond the fold and absolute positioning is used

jqDialogForms has a placeholder for modal dialogs but it's not implemented. The focus instead was on parent disabled+modeless+serializeable windows, meaning the ability to have a child window have a parent window, which forces the child window to retain a top-most z-index over the parent window, while the parent window's form fields are disabled, but you can still access the parent window and even drag it around. None of the windows in this scenario need to be modal; they just retain z-index. You can click on each open window and it acquires "activation", which moves its z-index to the top and then moves all of its child windows above it, and there is also an "active/inactive" titlebar color. It's a Windows 9x multiple app windowing behavior, within the browser. The window is also serializeable, meaning that it is a self-contained <form> with fields that serialize using either jQuery serialize() or using a JSON serialization. It is important to note that I made a point to be ASP.NET Web Forms compatible. jQuery's serialize() function doesn't work well with ASP.NET Web Forms unless the <form>'s are dynamically generated and appended to the body as this library does.

Because it is for dialogs, it assumes Apply and Cancel behavior and the presence of buttons. (OK is Apply+Close. Cancel is Close without Apply.) So there are assignable event handlers for before-show, showApply click, and hide. The default layout implements OK/Cancel and a close box on the top right.

There is a simple test document included with this release that I used to develop the the script, but it is an awful presentation for demoing purposes. The test document and the script itself are complete enough, though, for a knowledgeable Javascript developer to read and understand how it works without documentation. But next on my to-do list is to produce some documentation and samples, but except for modal mode the script itself it pretty much feature-complete, if not quite 100% tested, as a v1.0 beta release.

Features:

  • Modeless+parent disabling+serializeable dialog form windows
  • Reference a DOM element or a string of HTML as the message or form fields to be displayed
  • Automatically switch from fixed positioning to absolute positioning when in quirks mode IE7, and position to the current vertical scroll position
  • jqDnR enabled: Resizeable, Windows 9x style
  • jqDnR enabled: Drag around the screen via the title bar
  • Activateable; show multiple windows, and activate/focus each window as it is clicked on (Windows 9x application windows activation behavior)
  • Lacking CSS conformance of a dialog window container, a prefab one is used that includes a title bar, a close box, and OK/Cancel buttons.
  • OK button invokes Apply event handler and then, if not invalidated, closes the window.
  • Dirty state detection; on editable forms, OK/Apply buttons are disabled unless a field is changed
  • Exposes form serialize functions that outputs name/value HTML/querystring encoding (in the style of jQuery serialize()), or JSON serialization.
  • "Smart" top positioning for oversized dialogs
  • CSS-driven layout

Among the several known issues:

  • Multiple windows do not retain their activation order.
  • No fully modal dialog or truly modeless (non-disabling) support
  • No demo No extensive demos
  • No documentation

A few months back I released a Javascript library called jqAlert. I will probably rewrite jqAlert to use jqDialogForms.

It's NOT perfect, there are a few missing parts and pieces, but as far as I know it's a stable beta and can probably be used in production environments (I think). If you have any comments or suggestions, please use the Comments herein on this blog or e-mail me.

 

Download: 

http://www.jondavis.net/codeprojects/jqDialogForms/ 

 

kick it on DotNetKicks.com

 

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , ,

Web Development

jQuery Has Won The 3+ Year Javascript Framework Battle (As Far As I'm Concerned)

by Jon Davis 28. September 2008 15:33

It's official. jQuery has become the new de facto standard for the web development community. By rolling jQuery in with Visual Studio and the ASP.NET core tools pipeline, a whole new precedent has been set in the software industry.

jQuery was already supported in many major IDEs, including Aptana Studio (which is built on Eclipse), but usually only sharing with other frameworks like prototype. But there are two IDEs that have pretty much ruled the software industry for the last several years: Visual Studio and Eclipse. Neither one has chosen any particular "favorite" Javascript open source framework. You usually get a bundle of different frameworks being supported or nothing at all (import something yourself or roll your own).

But Microsoft's decision to adopt a third party software framework, bundle it, and make it a foundational component of its own, is an earth-shaking paradigm shift. This is something that will turn the software industry on its head. There is a whole industry carved out from the trenches that Microsoft dug. Giving a third party framework the honor of being placed into the middle of it all and running half the show, so to speak, is absolutely breathtaking, a moment to be awed. Right now everyone should take a moment and let their mouths gape because this is just short of bizzare.

And I mean that with no pretentions. I'm not saying that "this is unlike Microsoft", although it is, because there really is no precedent for this. The only precedents I can think of have been support for open standards--support for HTML (Internet Explorer), HTTP, FTP (bundled in Explorer), the TCP/IP stack, OpenGL, keyboard/mouse standardization, compact disc file system support, and standard driver support. But all of those things have traditionally always had, with very few exceptions, a proprietary implementation of software of Microsoft's own making or bought out. Most of the exceptions come from third parties such as Intel, who licensed technology, which is not the same as bundling open source code.

jQuery is licensed on the MIT license. Microsoft will be a "normal" participant with the jQuery community just like anyone else; they will introduce ideas, report bugs, and propose bug fixes, but they will go through a QA and approval process just like everyone else.

The closest thing I can think of that even remotely equates to Microsoft getting this involved with and supporting of outsiders in the web community was back in the late 90s, when Microsoft got very involved with the W3C and helped shape the directions of Dynamic HTML and the DOM, not to mention their extensive involvement with the XML and then SOAP initiatives and the insanely detailed UDDI [dis]proving that followed. But once again, those are standards / protocols, not code. So even though Microsoft has done amazing shifts in supporting the open source communities with CodePlex (bravo!), I'm curious if this really is the first time, ever, that Microsoft has done this on behalf of their proprietary development platforms (Visual Studio, ASP.NET).

On a final note, I must say that I absolutely adore jQuery and what it does for web development. jQuery working with Microsoft's ASP.NET MVC and C# 3.0 w/ LINQ are all a match made in heaven. Knowing that Microsoft is going to build on top of jQuery is almost like getting a wonderful new programming language akin to C#, but built for the web. So really, my day just went from being depressed from the last week to being literally overjoyed like I just got engaged to marry someone or something.

jQuery Flexigrid

by Jon Davis 27. March 2008 12:17

Ooohh.. I was digging the grid at http://www.extjs.com/ but we're already using jQuery, and wow this is really nice. http://webplicity.net/flexigrid/

I love the excellent pagination implementation at the bottom. And I love how little code it takes to make it "go". I love jQuery!

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , ,

Web Development

Introducing jqalert - The jQuery-empowered alert() replacement

by Jon Davis 22. March 2008 16:59

I'm releasing a beta build of something I've been working on called jqalert. It's basically a nice, skinnable modal dialog box that defaults to have a certain "fade-in" feel I wanted to have.

Here's the current project URL:

http://www.jondavis.net/codeprojects/jqalert/  

.. or on cachefile:

http://cachefile.net/scripts/jquery/plugins/jqalert/0.9/

I built this having been inspired by a few other similar libraries out there, including:

What sets jqalert apart is that it is a) specifically an alert() replacement, b) prefab'd to be functionally comparable to Visual Basic's MsgBox, which allows the user to set the title and the icon (and the buttons, too, but jqalert currently only supports OK), while c) also adding a lot of customizeability.

What does "specifically an alert() replacement" really mean, when other tools do the same basic thing? It's about the execution...

  • As quick and simple to use as possible: jqalert(message); or jqalert(message, title);
  • Predictable "windowing" appearance; universally recognizeable.
  • You get a titlebar.
  • You can drag the alert window around with the titlebar, for those "emergencies" where you might need to peek back behind the alert window, without closing out the message. 
  • You get an OK button.
  • The OK button claims focus, so that you can close it by just hitting spacebar or enter.
  • The OK button reclaims focus if it loses focus by clicking elsewhere in the alert window.
  • Modality blocks UI.

kick it on DotNetKicks.com

Currently rated 3.4 by 5 people

  • Currently 3.4/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , ,

Pet Projects | Open Source | Computers and Internet | Web Development

LINQ-to-Javascript

by Jon Davis 24. January 2008 15:28

I jumped onto codeplex.com for a random summary of the latest projects and stumbled across LINQ-TO-Javascript (JSLINQ). Pretty nifty idea.

Personally I'd like to see JSLINQ to be a jQuery overload -- that is, take the JSLINQ object definition and merge it with jQuery's object (at runtime) -- so that jQuery extensions can automagically work with JSLINQ objects. I suggested the idea here.

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , ,

Open Source | Cool Tools | Web Development


 

Powered by BlogEngine.NET 1.4.5.0
Theme by Mads Kristensen

About the author

Jon Davis (aka "stimpy77") has been a programmer, developer, and consultant for web and Windows software solutions professionally since 1997, with experience ranging from OS and hardware support to DHTML programming to IIS/ASP web apps to Java network programming to Visual Basic applications to C# desktop apps.
 
Software in all forms is also his sole hobby, whether playing PC games or tinkering with programming them. "I was playing Defender on the Commodore 64," he reminisces, "when I decided at the age of 12 or so that I want to be a computer programmer when I grow up."

Jon was previously employed as a senior .NET developer at a very well-known Internet services company whom you're more likely than not to have directly done business with. However, this blog and all of jondavis.net have no affiliation with, and are not representative of, his former employer in any way.

Contact Me 


Tag cloud

Calendar

<<  November 2018  >>
MoTuWeThFrSaSu
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789

View posts in large calendar