Hia I now have moved about 90% of the codebase to the new class structure here is an example:
http://www.pastebin.org/222860 For everyone familiar with dojo, this looks very familiar. Werner Am 11.05.10 14:48, schrieb Jakob Korherr:
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] <mailto:[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]> <mailto:[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
