The Daily Ext JS WTF!
I am getting bored ... the cost per use enterprise ready UI library we all heard about has some intrinsic, internal, illogical logic!
I already wrote how to hack JsonReader to obtain expected behavior.
I have already posted how to solve the TreePanel arrows inconsistency ... what I have never said is that my version of Ext JS is 30% hacked via overrides, extends, or directly in the core and 70% hacked in my application code to make it widely work as expected.
I am constantly trying to fix missed rendered components, layout problems, not visualized stuff ... I am hacking the entire layout process in Ext JS 2. Apparently version 3 with about 1000 fixes and enhancements should have solved layout problem but what I think is: how can be possible that probably the only library with a license for commercial purpose has to be that problematic with layout? The answer is that to make things "delayable" layout s not synchronous. I had then to hack with my timeouts automatic selections, forcing for example a grid to have first row selected 'cause if you use the specific method you do not obtain what you expect: a selected row!
Does it make any sense? Down to hack the behavior changing classes manually and run-time ... Cheers!
Today during a presentation the impossible happened: a click between two rows, probably in the border, probably in that pixel that should not be there, or better, is not logically managed!
The GridPanel, and this time it is the same for both version 2 and 3, has an horrible bug. If you click exactly in the middle of two rows it could select one of them without firing the rowclick event.
How can be possible? It is simple: they decide to manage rows differently between the SelectionModel and the GridLayout so that the selection model could be "activated" accidentally highlighting the row without firing the rowclick/rowmousedown event. Are you kidding me?
Let's explain to a customer that that row was not truly selected ... and after you receive hundreds of insults, let's go in the forum to see if anybody was brave enough to admit that the logic behind the Grid is absolutely a joke.
I had to file a bug for Firefox after I spent half a day to hack the grid to simply make text selection possible and I had to recursively hack the element style parent after parent to force MozUserSelect="text" in order to make that selection possible. I had to hack the grid via an asynchronous event in the selection model, rowselect, finding manually the incriminated div and manually firing the rowclick event when it is not fired because of the "selection model border" ... BLOODY HELL!!!
I still think Ext JS is one of the best "ready to use" UI libraries but I am truly annoyed by silly logics/stuff like the one described. I am day after day regretting I did not choose the YUI Library which is similar, component speaking, free, and event handling speaking definitively more reliable ... if you guys in Ext need some help from a JS developer give me a shout, I have dunno how many fixes for you, but please, if not, do not rush with releases and make everything as robust as you can.
Best Regards
P.S. to be honest, I would like to have time to develop my UI project, but apparently nobody pays me enough time to do that and everybody wants quick solutions. These are results, I wonder not that skilled web developers what they do when they have a problem, probably they simply wait next release ... how can you call this Enterprise? Ext GWT guys, I am talking with you as well ... bear in mind JavaScript is nor a toy neither a joke, JavaScript is a language and as programming language it requires a proper programmer.
I already wrote how to hack JsonReader to obtain expected behavior.
I have already posted how to solve the TreePanel arrows inconsistency ... what I have never said is that my version of Ext JS is 30% hacked via overrides, extends, or directly in the core and 70% hacked in my application code to make it widely work as expected.
The Layout Problem
I am constantly trying to fix missed rendered components, layout problems, not visualized stuff ... I am hacking the entire layout process in Ext JS 2. Apparently version 3 with about 1000 fixes and enhancements should have solved layout problem but what I think is: how can be possible that probably the only library with a license for commercial purpose has to be that problematic with layout? The answer is that to make things "delayable" layout s not synchronous. I had then to hack with my timeouts automatic selections, forcing for example a grid to have first row selected 'cause if you use the specific method you do not obtain what you expect: a selected row!
Does it make any sense? Down to hack the behavior changing classes manually and run-time ... Cheers!
The Grid Row Inconsistency
Today during a presentation the impossible happened: a click between two rows, probably in the border, probably in that pixel that should not be there, or better, is not logically managed!
The GridPanel, and this time it is the same for both version 2 and 3, has an horrible bug. If you click exactly in the middle of two rows it could select one of them without firing the rowclick event.
How can be possible? It is simple: they decide to manage rows differently between the SelectionModel and the GridLayout so that the selection model could be "activated" accidentally highlighting the row without firing the rowclick/rowmousedown event. Are you kidding me?
Let's explain to a customer that that row was not truly selected ... and after you receive hundreds of insults, let's go in the forum to see if anybody was brave enough to admit that the logic behind the Grid is absolutely a joke.
I had to file a bug for Firefox after I spent half a day to hack the grid to simply make text selection possible and I had to recursively hack the element style parent after parent to force MozUserSelect="text" in order to make that selection possible. I had to hack the grid via an asynchronous event in the selection model, rowselect, finding manually the incriminated div and manually firing the rowclick event when it is not fired because of the "selection model border" ... BLOODY HELL!!!
Sorry For This
I still think Ext JS is one of the best "ready to use" UI libraries but I am truly annoyed by silly logics/stuff like the one described. I am day after day regretting I did not choose the YUI Library which is similar, component speaking, free, and event handling speaking definitively more reliable ... if you guys in Ext need some help from a JS developer give me a shout, I have dunno how many fixes for you, but please, if not, do not rush with releases and make everything as robust as you can.
Best Regards
P.S. to be honest, I would like to have time to develop my UI project, but apparently nobody pays me enough time to do that and everybody wants quick solutions. These are results, I wonder not that skilled web developers what they do when they have a problem, probably they simply wait next release ... how can you call this Enterprise? Ext GWT guys, I am talking with you as well ... bear in mind JavaScript is nor a toy neither a joke, JavaScript is a language and as programming language it requires a proper programmer.
Comments
Post a Comment