That's great news, Werner! Regards, Jakob
2010/5/14 Werner Punz <[email protected]> > Ok guys it is done for now. I ran a load of new tests on the codebase and I > hope I have caught most if not all errors. > > I think our _Runtime.js is now solid enough to be reused by Tomahawk and > co. > > What you can do with it: > a) Real prototype inheritance dojo style > b) Namespacing > c) some smaller helpers which are delegated to the other utils classes like > byId as a document.getElementById shortcut. > d) Browser detection. > > In the utils classes you get extended dom walking functionality (no query > api, that would have been too big for what we try to achieve here) > > some language shortcuts like equalsIgnoreCase, > also a basic unit testing and logging framework is in place there > to at least have some basic functionality in place > > (the unit testing framewor is hosted in UnitTest.js which is not linked in > the final build) > and the logging functions are in _Lang.js and route to the standard logging > output or to a div with a special identifer if present. > > I can heavily recommend to use that functionality improve it fix it if you > encounter a bug than to roll your own solution, in the end it helps all our > codebases and keeps code duplication down. > > > Werner > > > > Am 12.05.10 20:11, schrieb Werner Punz: > > Ok I have everything up and running, but I have not finished my tests yet. >> The commit has to be postponed to friday. >> >> For Mark Li, the good news is I have now the dialog example fully up and >> running with the latest codebase: >> >> http://pastebin.com/TmFGtQyv >> >> Werner >> >> >> Am 12.05.10 00:36, schrieb Werner Punz: >> >>> 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 >>>> >>> >>> >>> >>> >> >> >> > > -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
