Ok I am now done with the Javascript refactorings,
there is probably still some room for improvement, but I think
the code now is a solid foundation for the next enhancements.
Here is a full list of what has been done
a) Namespace cleanup
b) Introduction of a base _Runtime class which provides basic functionality
like namespacing, inheritance and browser detection
c) Cleaned up the entire utils part, we are mostly down to Dom and Lang
utils classes (and one AjaxUtils class)
d) Cleaned up the Ajax part and queuing part, the code now should be
easier to maintain, and pluggablet transports now should be easier to
implement
e) Introduced a speed optimized base queue for all our queuing needs
f) Introduced browser optimized dom traversal routines which use the
latest tech available - if available
g) Added some basic integration unit testing and logging functionality
which utilizes what the browsers have
h) Added special fixes for update parts with embedded forms (typical
dialog case)
i) Cleaned up the entire manual evalution of javascript code, way more
readable now, by shifting the recursions into our optimized dom walking
routines
j) Improved the error handling, the error messages should trigger now
always if one occurs with a correct line number and function of the
issuing class
(there is still some work to be done in the future however, we have
cases where the error handlers are called multiple times)
g) Wrote a bunch of unit tests, which in the long run will be committed
once we have a good place for it (for now I use it privately to nail
down bugs upfront)
Anyway I think our codebase now is in an excellent state, and I hope I
did not introduce any new errors, so far everything runs fine here,
including Trinidad and the code scales very well back down to ie6.
Have a look at it and if you still think it needs improvement somewhere
please tell me.
Cheers
Werner
Am 14.05.10 14:33, schrieb Jakob Korherr:
That's great news, Werner!
Regards,
Jakob
2010/5/14 Werner Punz <[email protected] <mailto:[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]>
<mailto:[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]>>
<mailto:[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
