myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Punz <werner.p...@gmail.com>
Subject Re: proposed: myfaces jsf.js refactorings
Date Tue, 11 May 2010 16:03:17 GMT
No worries the first part of the refactorings is almost done
however I need to run additional tests (I am low on unit tests
here for the javascripts, only a couple of pages testing
the protocol on http level)

So the commit probably will happen tomorrow.

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



Mime
View raw message