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.
Have you ever tried something with qooxdoo. I know that you do not like the build system. But it really might be a good try instead of fixing and fixing ExtJs over and over again ;)
ReplyDeleteThe application is huge, it is not possible right now to change ... and there's no time to do it as well. I simply hope we'll migrate to version 3 ASAP!
ReplyDeleteI know qooxdoo is a good project, but I would give a try to YUI before because is ready to run. Guys, you should really consider "the root stack to go" cause you are "scaring" developers to use your framework. Not everybody is under Linux and Python is something I use locally (version 3 though) but I cannot force a Visual Studio Team System based development team to use a completely "out of control" stack to manage client builds. Got the point?
Have you ever tried smartclient.com ?
ReplyDeleteWhy don't you address this in the ext forums and get someone like Animal or the core devs (guys who understand the library) to help you?
ReplyDeleteSure, you can't easily switch technology in a already huge project. That for sure. I mainly mean for some kind of new projects when you have them.
ReplyDeleteI got the point Andrea regarding the build system. I don't know though how to deliver qooxdoo the best for people without a build system. It might be possible to pre-package qooxdoo in some kind of modules. But that always result into overhead as classes or functionality is loaded which is used nowhere. And this is also true for your own application. In my current company I use the same source code for douzens of delivery platforms. Some kind of auto-dependency tracking works wonders here. Please tell me what you think would work for guys like you - or projects like yours.
I would be really interested where you think YUI is better than ExtJs. I think that ExtJS GUI-technology is still ahead of YUIs. Not sure about 3.0 though. qooxdoo and YUI (and even ExtJS) play in completely different classes regarding UI creation. qooxdoo is by far the most abstracted way as there is no DOM visible - even when creating new widgets or building a custom theme.
@ClaudeFR, as I said it's too late to switch UI framework but interesting project, thanks.
ReplyDelete@mankz, the application is huge which means no way to replicate the scenario. Moreover, I am mainly paid as JavaScritp developer and as developer I found problems, I solve them, quicker than Ext JS team avoiding application deadlines slowdown. Then, when and if there is time, I try to post an answer, to file a bug, or I write an entry in this blog. Ext JS developers do not read this blog? It cannot be my problem :P
@wbpasti, dojo style, as YUI style, would be a good way to include incrementally. qooxdoo is actually the only FW I know that to be usable requires other installations. The full inclusion problem? 90% of people do not care if it is 300Kb or just 90Kb, specially for intranet based project where right here I am managing more than 2 Mb of client code ... think about it. qooxdoo is good but its "to go" plus the build system is the less flexible I know. I've personally created a build system here so when necessary, developers know how to implement one.
Ext JS developers do not read this blog? It cannot be my problem
ReplyDeletewhat I means is that they are not more animal than me or others out there ;)
@Andrea: Less flexible? Do you really have seen the build system of 0.8? I hope you can explain this. I think it is pretty flexible. You can configure everything as you like even adding new jobs/targets and calling external applications to e.g. build stuff for Adobe AIR or PhoneGap. I got your point with intranet applications though. It may be right that size-wise it makes no difference. Though it might still matter regarding execution/load time.
ReplyDeleteLess flexible "production environment" speaking, like my case where we do not use Python and we want to manage/track in Visual Studio Team System everything
ReplyDeleteIf this is not possible, qooxdoo could have the best build system ever but we'll never use it. Just consider an easy way to use qooxdoo, just create a nightly with everything (a la ext.all.js) without compression (no packer, no compressor) and let people test it. Mine is only a suggestion
What a load of old toss.
ReplyDeleteYou are probably right, it was just an outburst ... but seriously, you cannot imagine how many silly problems I have and specially the grid one is quite annoying cause cellclick, rowclick, and others could be useless in certain situations while rowmousedown works but to know which cell was the target is truly difficult.
ReplyDeletehttps://developer.mozilla.org/en/CSS/-moz-user-select
ReplyDelete<div style="-moz-user-select:none;">
<div style="-moz-user-select:text !important;">
abc
</div>
</div>
abc should not be selectable. If you wanted that, then this should be used:
<div style="-moz-user-select:-moz-none;">
<div style="-moz-user-select:text !important;">
abc
</div>
</div>
None is supposed to never allow any children selection (visually). -moz-none is the same but can be overwritten. That is how I understand it anyhow.
@Stevem, Directly from Mozilla MDC
ReplyDelete-moz-none
The text of the element and sub-elements cannot be selected, but selection can be enabled on sub-elements using -moz-user-select:text
Which part is not clear?
Hi
ReplyDeleteI agree 100% with Andrea Giammarchi (and not only because I'm italian too.... :) .
I'm a newbie of ExtJS and I'm migrating my actual web application ( a very big J2EE application) to extjs..
And I'm very amazing that for very simple application purpose I must override standard ExtJS function
Many ExtJS Team people also provide workaround, but at the end they are not part of the standard.
E.g.
In every web application usually a mandatory or readonly field should have a way to identifier it... this is for usability. ExtJS doesn't have it.. do you want it ? use same example.. but why? all people need it! put in the standard.
A field is reaonly ? and it have a picker ? you must disable it directly .E.g. for DateField... another override.. (and for ExtJS team this is the right behaviour...)
Ok... all can be done.. but so it is not a ready to use framework to build for example ERP web application.. You must customize a lot of component.
Bye
It is surely wtf situtation. We are big company and its a big project and things are getting really difficult to manage this app which is written in extjs. Too many css overides, javascript hacks. Now they realize it was a wrong decision to have chosen extjs. extjs is good for simple apps and for addons but certainly not for big apps. What a mess extjs is
ReplyDeleteDon't feel too bad. I've hacked the crap out of Ext 2.0. My ext_overides.js file is 500 LOC.
ReplyDeleteI'm in the middle of a 3.0 upgrade. It's better but still crawling with issues.
This comment has been removed by the author.
ReplyDeletedude, I have almost an thousand of lines of overrides 8-)
ReplyDeleteOK, it is not only hacks, I put BJSpell in the HTMLEditor for IE too, as example, but please do not tell me Ext 3 is bad as well :(