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 <werner.p...@gmail.com>
> 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 <werner.p...@gmail.com <mailto:
>> werner.p...@gmail.com>>
>>
>>
>> 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
