3 Nov 2008 11:58 AM #1
why most member data private?
before i write my issue just a remark: i find gxt a great lib!
i have a general question to the implementation of gxt :
why most member data is kept private?
this makes me copy/paste code... duplicate and duplicate class by class.
ComboBox ... in initList() you create a PagingToolBar. i cannot override or customize it as it is not created in overrideable method. i cannot access it. i cannot even override the initList() as it is worthless without getting access to the members.
at least members should be kept protected to allow workarounds.
sometimes i think on copy the source of gxt into the project and replacing all private to protected :-)
thanks for your efforts!
4 Nov 2008 12:40 AM #2
4 Nov 2008 12:52 AM #3
result is copy/paste programming
e.g. ComboBox has some bugs - e.g. in the height caluclation of the list. i could override the restrict() method but it is private:
private void restrict() ....
i have fallen over so many cases that i really get frustrated on gxt. even copy/paste programming does not lead always to success as there are dependencies.
on the other side: try to change the footer for paged ComboBox. current footer doesnt fit fully if the list is too small. but how can you customize the footer? through all the private stuff there is no possibility.
again copy/paste copy/paste copy/paste. every bug or design problem inside gxt gets a big big pain.....
4 Nov 2008 1:06 AM #4i find gxt a great lib!
why most member data is kept private?
But I'm facing the same problems with private methods. I'm working on a Portal where you can add, remove and resize columns. To do so I have to override the onDrag.. methods. But since onDragStart is private, I copy the Portal class and just change the modifier of onDragStart . After that I can derive from my new Portal and build the mutable upon it. Not really the best practice.
4 Nov 2008 1:07 AM #5
Maybe it should for some specific points you are talking about (with ComboBox), therefore I suggest you to ask for specific points and not for the whole API. On the other side, don't forget that the best long term solution is to post issues in the Bugs forum and get them fixed by GXT team.
4 Nov 2008 5:30 AM #6
but we will have to live that each gxt will also have bugs (i can live with them) and design flaws (i also can live with them as gxt team cannot guess all use cases). no fix can be a long time solution, so bugs and flaws will be reported here......
so just please let us developers also be part of the game and not knock us out
"protected" means: usage only by people who wanna change any behavior and not for normal users of a class. i think this should be protection enough.....
4 Nov 2008 9:04 AM #7
I agree with the points stated. The GXT developers shouldn't try to guess how the controls will be inherited. Doesn't it not make sense to make the class members protected instead of private?
10 Nov 2008 7:02 AM #8
i'd agree, make things accessible to the developer. when i need a fix, i need it now, not when the GXT team can get it fixed. i'm currently left w/a copy and paste (i.e. fork) that i have to manage just to fix stuff. if i break something in my subclass, too bad for me. i broke it, i'll fix it.
12 Nov 2008 10:41 AM #9
We will not make all private members protected as it is not a good idea for many reasons. If you have a specific requests around visibility, you can post what you would like changed and in most cases we will make the change if it makes sense.
13 Nov 2008 2:25 AM #10
you can easily see what should be protected.
1) if you use eclipse, just move subclasses to other packages and see what is broken. e.g. GridView and its subclasses and nested classes etc.
2) just make a copy of your class to another package. if this works, it allows as at least copy paste programming without moving class by class often full hierarchies and dependencies to other packages - this softens the big pain.
3) try to make sample subclasses of your classes and use a different package and see.... i wanted to change history behavior... but you can try make any change in your dispatcher with a subclass.... this was a never ending copy paste story until i had to realize to give up - i ended in switching off history completely.
generally: if in development mode gxt team uses other packages and then migrate to distination package, and if they make a sample subclass of all classes, then most things should work for us too.
for me it is a big frustration. never had any project in my 25 years of oo design and development where i was so far from schedule as this project. the server (great groovy/grails but with terrible eclipse plugin) and client (great gxt but with copy paste programming as nearly all is private) both are very nice technologies, but still not mature. and my hands are bound....
darrell - we are willing to migrate our code with each gxt coming. we have to adopt as some things just will break and some simply will not run after an update. but private leads to real frustration.
what if you make all protected and mark them as depricated? when programmers are using them, they ask here for removal of depricated for next release..... this would give us the ability to fix bugs on the fly, write them here and immediately continue working.... this would avoid copy/paste programming completely.
in all cases, regardless how you decide, i would like to thank you for your work. i think this has a nice future beside flash and silverlight.