Sounds great, Werner! Regards, Jakob
2010/5/10 Werner Punz <[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
