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 Fri, 14 May 2010 12:21:50 GMT
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 <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