I've been unhappy with jquery's class syntax and suggestion of using a method parser to find methods in a class. I took a stab at coming up with a familiar but more strict pattern. I understand jquery is designed to work with anonymous functions and all that, but I have found it leads to some poor developer choices and barely maintainable code.

First add a way to access the controller class via the jquery object that doesn't require a string comparison:

$.fn.extend({ controllers:{} });

Then you can add your old prototype classes with a small jquery snippet at the top of the class:

(function( $ ){ $.fn.someClass = function(arg,arg){ this.controllers.someClass=new someClass(this.get(0), arg1, arg2); return this; }

})( jQuery );

function someClass(div,arg1,arg2){ this.myDiv = div; this.arg1 = arg1; this.arg2 = arg2; } //the properties vars are probably better with an encapsulating object so you can use extends to replace default values. someClass.prototype.myDiv = {}; someClass.prototype.arg2 = ""; someClass.prototype.arg1 = ""; someClass.prototype.doSomething = function(){ alert(this.myDiv); }

Then you can use the jquery chain:

$("#someDiv").someClass(arg1,arg2).appendTo($("#someOtherDiv"));

Then you can access your proto by accessing the element:

var mySomeClass = $("#someDiv").controllers.someClass; mySomeClass.doSomething();

You can add multiple controllers to any jquery element.

You can do this with blind libraries as well: Here's a simple way to add googleMaps v3 to the scope chain:

$.fn.extend({ controllers:{} });

$.fn.googleMaps = function(mapOptions){ var map = new google.maps.Map($(this).get(0),mapOptions); this.controllers.map = map; return this; }

You could make a for each loop in the fn, but it seemed redundant.

Then you can access maps API as

var map = $("#mapHolder").googleMaps(myOptions).controllers.map;

or

var map = $("#mapHolder").controllers.map;

Since it returns "this" you can keep trucking with the scope chain:

$("#mapHolder").googleMaps(myOptions).appendTo(whatever)

To me this seems like a much tighter, ram friendly way to apply true template classes within jquery for plugins than jquery's recommendation of plopping functions directly on members and passing method names as strings to do any work.

And also, it makes it easier to reuse your own classes with other libraries later if you decide to jump from jquery to something else. You haven't put all your egss in the jquery basket.

I would be interested to know if these ideas were still relevant or needed if you coded in haxe javascript. I found when trying a haXe javascript experiment that I probably would not need something like jquery, maybe feffects to help tween, but since haxe smoothed over browser issues, and alowed me to code at a higher level there was less need for javascript 'magic fix' libraries.

Some related haXe librarieshttp://lib.haxe.org/p/jqueryhttp://haxe.org/com/libs/jeash

Sorry off on a tangent but just wondering if you had seriously tried haxe and could say all this jquery hacking was really a better approach, because i am not currently convinced.

Ah, I see the advantage. Unfortunately we need to keep in mind a wide range of developers who can inherit the code. And I understand Haxe and it's standard syntax, but simply saying the word Haxe, and adding a relative unknown into the mix can/will scare many of the pool of available developers. It's a simpler matter to say jquery/css/xhtml and not scare away the more timid who would, frankly, need to work their way up to more advance concepts like a haxe solution.

It is a neat idea though, abstracting all of it out.

:beer:

Honestly, I think you're looking for this:http://twelvestone.com/forum_thread/view/44779

I know!

:grumpy:

I even had a conversation with coworkers about how I was trying to solve the very problem when I mentioned that you had linked to backbone.

I even have a robust data model class that can go buh bye if we adopt backbone or something like it.

We're a year into development on our current project, so I'll have to approach things carefully, but the environment is certainly changing fast enough, and more importantly well enough to reassess the open source options.

I can't wait to shift HF over to Backbone, I went a bit haphazard with the JS just out of expediency (there's just too much going on to get everything right from the get-go, as one person anyway.) But now I am really feeling the pain of jQuery sprawl.

Still, I've started to divide some pages up into live content areas and have added a custom sync plugin in preparation. That way when something updates I can have it grab the newest version of itself from the server without chasing state all around the page. For instance on the photo album editing page I have a view of the albums/index which is a list of your photo albums, and an albums/show which is the gallery that you are currently on. When something is edited I tell both of those content areas to sync with their URL and presto—shit just works.

Getting that out of the spaghetti that's currently my JS and into a nice MVP (Model/View/Proxy) will be awesome.

yeah currently I have a bunch of developers working fairly independently on a project, and to be able to do that I created a simple set of tools which extend jquery as I have above.

Rather than worry about manual data binding, everyone can make a data request to a single model class, which I mentioned, and define a callback function. If no one else has made the request before, it works like a regular ajax request. However...

If someone else makes the same uri/param set call later, the model class's work kicks in. ( they can force a no-cache if they want.) If there is a no-cache preference, The model class will compare the new return result with the last result for that uri/param set in a static data store class used by the model class. If it's indeed different it fires the callback of anyone who has called that uri/param set and still has an active callback. If it was the same uri/param set and the no-cache preference was ignored, the new subscriber gets the data which exists in the data store. Since the callbacks are just a method of the instance of the model class used by the developer, the dispatcher can automatically kill off listeners if they no longer exist.

If a uri/param set is in-flight pending a return from the server, any new subscribers added during the latency condition are handled as if the eventual result is new data since the new data won't equal null. No one misses out.

A nifty thing is it even works with post requests, so it works with data services we don't own, which drastically cuts down hit counts on costed per hit api services.

So anyways it allows everyone to work like they're working independently without having to worry if they're going to trample one another or make a redundant data call, since the uri and any parameters are used to make a unique id hash for the request.

Since all the data exists in only one store with a peachy automated result dispatch, the javascript is reduced to asking a model for data and then instantiating a ui or modifying a ui for display without having to worry about persistence management. So we have discreet ui modules in our CMS which each have an associated js class. Also the service uri isn't obfuscated in some magic box, so a new developer can look at a class and see what uri is being used right away.

blah blah blah.... anyways you can see why backbone tickled my javascript banana and got me thinking about push.

I think haxe probably has some of this stuff? Like you mentioned jquery chainshttp://github.com/0b1kn00b/arrows/blob/master/README

async callbackshttp://github.com/jdonaldson/sugar-async

signalshttp://code.google.com/p/hxhsl/wiki/PrefaceAndIntroduction#Preface

I probably don't understand your details so wont try to find links for all the bits but I expect if you asked the haxe list you would find there are probably libraries and solutions already.