GXT rant in general and ComboBox in particular

[eugenparaschiv]

I've been looking at the code in ComboBox and it seems to me that it tries to do way to much all at once. I propose a more natural approach to implementing it, and many other widgets in GXT.
First the ComboBox: if you need a simple ComboBox, static (no data loading), no backing model, no store, just a simple combo box, there is no way to do it. Most of the time, no data mapping is required, and GXT forces you to do it anyway. Now don't get me wrong, I love the data mapping stuff and sometimes I do need it, but this should be additional, in another class extending the basic ComboBox not included in one single implementation.

ComboBox is in fact is one of the most basic things you can do in a web page, even with HTML and in the API, it's all the way down, extending: Widget-Component-BoxComponent-Field-TextField-TriggerField-ComboBox? That a 7 level hierarchy (not taking into acount the fact that Widget is at level 3 already) for a simple combo box. Even with the GWT compiler optimisations, there must be some code bloat for a class this far down the hierarchy.
I thing it would be more natural to have simple widgets with no data mapping and place the advanced features in extensing classes. ListBox (which is the GWT combo box) is only at level 2, and so is simple to use and very lightweight. Now if this would be the case in GXT, the API would simply be so much better and what's more, the class hierarchy would be more natural as well.

One last thought. By doing this, perhaps some GWT widgets could be extended; the simple widgets could be used as basetypes and do that data loading and additional stuff could be built on top of that.

The benefits would be huge: tacking advantage of the maturity of the GWT widget library more natural interoperability with GWT, tacking advantage of an already existing code base instead of doubling the work, not having to learn two API's, and many others.

Perhaps the class hierarchy originates from the actual overall structure of Ext-JS, which is more mature. But EXT-JS is not build ON TOP of anything, and GXT is. It makes no sense to try to mirror that hierarchy exactly.
There is another post that touches on this:
http://extjs.com/forum/showthread.php?t=46922
OK, any thought? Perhaps even from Darrell, about the structural choices of the API, now and in the future.
I would really like to know what Darrell thinks about this, in terms of the probability that a change like this will be realized (or at least realizable).
Thanks.
Eugen.

[gslender]

Eugen,

I'm replying mainly because I'm not in total agreement with some of the points you've raised nor the tone and manner.


I've been looking at the code in ComboBox and it seems to suffer for the same problem many other GXT widgets seem to suffer: it wants to do WAY TO MUCH all at once.

SimpleComboBox exists in the 1.1 alpha version so I guess most of your complaints are addressed there /:)


I would really like to know what Darrell thinks about this.

I'd suggest your overly critical approach is not likely to result in much response - you probably should consider that paid support results in better response to requests, whereas community support relies on people like me to volunteer their time to help - being overly critical in your approach doesn't always result in the best outcome... try to be a little reasonable 8-|

Now if you have any problems with using SimpleComboBox in 1.1 alpha 4, then I'm more than happy to help - if you just want to rant and rave about how bad the toolkit is, then I'm guessing this won't always result in people rushing to respond.

Cheers,
Grant :)

[eugenparaschiv]

I see what you mean. I read my post and I do come off kind of pissed. Don't think I was being overly critical though (minus the tone which I will edit now :)). The problems I was trying to point have to do with the overall structure of the GXT API, and ComboBox is just an example. Briefly, the class hierarchy would be more natural (at least in my view) if some changes would be made to encapsulate the advanced functionality (data mapping, validation and such) in extending classes and to keep the simple stuff separate, in base classes.
For instance, it strikes me as a tad convoluted to first have ComboBox in the hierarchy, whith all the functionality in it, and then to try to provide a simpler version of it by further extending it. This places the SimpleComboBox at level 8, after the full ComboBox.
Anyways, you're right about the tone, I'll do some changes to my post. And thanks for the telling me about the SimpleComboBox (I did not see it until now)