Yes, sure. However it is important to have these refactorings on core first. Then we can adopt them to Tomahawk 2.0! I am sure we will find a way ;)
Regards, Jakob 2010/5/11 Werner Punz <[email protected]> > Hi Jakob, the namespacing, dom and inheritance features might be useful > also for Tomahawk 2.0. > I am however not sure how we can manage it buildwise to get it in. > > We might drop some of our files buildwise from the api also into tomahawk. > > A double include is not really that bad because due to the namespacing it > cannot happen. > > > Werner > > > Am 11.05.10 13:21, schrieb Jakob Korherr: > >> Sounds great, Werner! >> >> Regards, >> Jakob >> >> 2010/5/10 Werner Punz <[email protected] <mailto: >> [email protected]>> >> >> >> Yes definitely, the exception handling can be done better, but one >> step after the other... >> >> I already cleaned up some exception handling stuff in the utils >> classes, there are no more direct references to our impl exception >> delegation code. >> >> >> There are several things which can be improved, but cleaning up the >> namespacing, and utils classes was the part with the highest >> priority for me (And also to get some inheritance in, because we >> will need it probably for 2.1 already, when we have to cover iframe >> transports as well hopefully) >> >> I am almost done with the initial refactoring, I will commit the >> code probably around wednesday. >> >> >> >> Werner >> >> >> >> >> >> Am 10.05.10 18:38, schrieb Ganesh: >> >> This is cool! Isn't the exception handling another place to >> clean up? >> >> Best regards, >> Ganesh >> >> Werner Punz schrieb: >> >> Hello everyone, I have started somewhat of a cleanup >> regarding the >> jsf.js codebase which will be done in the following weeks. >> >> First of all after fixing the bugs (which I will commit >> today), I came >> to the conclusion that our utils classes are somewhat in >> need of a >> fixup and generally some structures can be solved better. >> >> What I want to do is following: >> >> a) Split the utils classes into: >> _Lang (former _LangUtils) >> _Dom (former mostly utils) >> _Communications (former AjaxUtils) >> >> move some of the methods around and add a bunch of new ones >> regarding >> dom traversal (mostly iterators utilizing filter closures, >> which can >> be browser optimized, due to most browsers already have dom >> level 2 >> filtering iterators in place). >> >> Also we will add a new class _Core or _Runtime wich will >> initialize >> the basic runtime stuff, like namespacing, browser detection, >> configuration binding (which our system is more or less >> coupled with >> loosely) >> etc... >> >> Note, most of this stuff already is in the codebase, but >> grown into >> the wrong place of the _LangUtils, or _Utils classes. >> >> There also will be changes to the namespacing itself >> currently we have the usualy if cascades to check for >> namespaces >> >> I want to move that into something like >> _Core.reserveNamespace, so >> that the code will look like: >> >> if(_Core.reserverNamespace("my.name.space")) { >> my.name.space = function() {}; } >> >> This is very close to what dojo.provide("my.name.space") does. >> >> >> Also what I want to do to ease future development is to add >> prototype >> based inheritance which follows very closely the dojo pattern. >> >> which means: >> >> _Lang.extends("my.new.MyClass", parentClass, { >> /*note we have to rename the constructor name a little bit >> due to >> javascript limitations in prototype inheritance*/ >> constructor_:function (arg1) { >> //we have to do it that way due to javascript limitations >> this._callSuper('constructor', arg1); >> .... >> }, >> myNewFunc: function(arg1, arg2) { >> //basically the same as this._callSuper("myNewFunc", arg2) >> this._inherited(arg2); >> .... } >> }); >> >> >> Now for now I also would leave following option open if you >> want to do >> it in a more ide friendly way: >> if(_Core.reserverNamespace("my.new.MyClass")) { >> my.new.MyClass = _Lang.extends(function (arg1) { >> this._callSuper('constructor', arg1); >> }, parent); >> my.new.MyClass.prototype.myNewFunc = function(arg1,arg2) { >> this._callSuper('myNewFunc', arg2); >> ... } >> } >> >> The second option is easier to grasp for IDEs, but the >> this._inherited() call will not be possible. But I want to >> support >> both options because the first option is much more dense and >> does not >> need a separate namespace checking, while the second one is >> more >> friendly to ides. >> As for now inheritance is not used, we use delegation over >> loose >> coupling but for future extensions it would make sense to >> have it in. >> Especially since a load of stuff from the transport layer >> can be reused. >> >> Anyway: >> >> I do not want to go for a full blown framework here, to keep >> the >> codebase as tight as possible. I just want to add >> the needed stuff to make future extensions easier. >> >> (Which will probably different transports like iframes, and >> websockets, queue control and timeout (which we already have >> in our >> codebase)) >> >> Problem is by using an existing js library (and that was the >> major >> reason why I did not do it firsthand) we will add around >> 20-100kbyte >> of extra code which is mostly pointless. Although I am a >> huge fan of >> dojo (less of jquery due to its structure), if we integrated >> dojo >> under our own namespace, we would need the core (50kbyte + xhr >> + >> probably 1-2 other modules) which would add 50-70 kbyte in >> compressed >> form, 80% of stuff which we will never touch) >> >> I however opted for a loose binding of the layers so that >> people can >> rip out our implementations of the layers and use whatever >> they like >> in a configuration manner. (it is possible to replace the >> entire xhr >> transport by your own implementation without overwriting the >> entire >> xhrCore classes for instance so that dojo or other transports >> theoretically could be plugged in) >> >> >> >> Werner >> >> >> >> >> >> >> >> >> >> >> -- >> Jakob Korherr >> >> blog: http://www.jakobk.com >> twitter: http://twitter.com/jakobkorherr >> work: http://www.irian.at >> > > > -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
