21 Nov 2012 11:48 AM #1
Building Custom Component using gxt 3
Building Custom Component using gxt 3
As per our client needs, we want to build some custom widgets using GXT 3.x with GWT 2.5. Is there any forum/blogs on reusing the custom widgets. I started with ListGrid but I could not achieve due to ValueProvider and ColumnConfig is not able to declare as Type parameter and pass on to custom widgets.
I would highly be appreciated if you could show help/forum/blogs on this.
26 Nov 2012 8:17 AM #2
I recall seeing something in the forum here about using both 3.x and 2.5 together but don't recall where or in what context.
I suspect you may run into some trouble with some widgets because some were completely rebuilt between the two version.
3 Dec 2012 7:07 AM #3
You shouldn't see any major issues, provided you aren't doing anything that doesn't already make sense (like drawing two Viewports, not assigning sizes to a Grid, etc). Each GXT 2 and 3 consider the other's widgets to just be generic widgets - no specially handling is or will be included by either library.
4 Dec 2012 11:59 AM #4
4 Dec 2012 4:26 PM #5
We have run across z-indexing issues when mixing 2.2.5 components with 3.0.x windows (and vice-versa), and it has caused us a bit of grief.
The issue arises in the two different WindowManager classes;
We have been meaning to write this up as a bug, but were trying to head Sven off at the pass with the "supply entry point example where the problem exists". We just haven't had the time to put the example together.
4 Dec 2012 4:58 PM #6
It isn't going to be perfect unfortunately - the whole premise of a single WindowManager is that it owns and tracks all the windows.
The bug seems valid, but the trick is that to fix it, we'd need one XDOM to know about the other, and we don't want to require GXT 2 to use 3 or vice versa. The changes in the package structure, the existence of the legacy jar are all things we did to smooth the process, but it cannot be all things to all people.
Two basic strategies for workarounds:
* Add listeners/handlers to the windows of one version of GXT on the show event, and synchronize the z-indicies stored on both XDOM classes at that point. There may be other hooks you need to place to perform this update.
* Always use either GXT 2 or 3 windows, but then populate the content of that window with the desired version. This has a higher up-front cost (modifying all existing GXT 2 Window instances), but will probably make things easier in the long run, as you'll have already started to make 3.x changes, and won't need to mess with XDOM and WindowManager internals.
We've already created on more idea that will be available in 3.0.3 and beyond - you can create your own subclass of WindowManager and register it with a <replace-with> rule in your module file. GWT will then create your instance instead, which can have whatever overrides you need to write to help solve this issue and more.
And in cases where bugs aren't truly self-evident (this might be one where it is), working test cases save us an unbelievable amount of time. First in terms of getting the exact conditions (if it was easy, you'd have done it, so we can assume it isn't easy), then the steps themselves to reproduce (I'm sure you've seen at least one 'works on my machine' issue in your own team), the GXT/GWT versions, and vagaries of the html page and module file. If we can at least get a simple class that either works or doesn't, we can start pointing at other causes, or get on to fixing the bug.
With a somewhat minimal test case already present, we can make it even more minimal, and add it to our unit test suite to ensure that it doesn't break again. If we're spending all our time trying to reproduce cases, other things end up getting left by the wayside, so we need to prioritize somehow.
5 Dec 2012 7:58 AM #7
I'm not sure if you are being defensive, but there is no need to be.
I was simply remarking on a hiccup in backwards compatibility, which is good to know about before you run into it. If anything, we are feeling a little guilty about not posting about this issue sooner.
Yes, there is a clear workaround to this, and we are using it.
We have been synchronizing the z-indices between the two XDOMs, similar to what you've described.
It's not elegant, but it works just fine and is simple enough to document.
I'm all for asking for simple examples which illustrate the bug one is trying to describe. We are not sitting in the same office, so there is no pair/armchair debugging. Providing a working example is the next best thing, IMHO.
That being said, we will put an example of this together and post the bug.
5 Dec 2012 8:03 AM #8
Thanks - I might be a bit defensive on the 'working entrypoint' bit, as I really hate telling people their bugs are incomplete, or worse, ignoring them, but a lot of people repeatedly ignore our requests for reproducible issues...
In this case though, even if you file a bug, there isn't a lot we can do, short of making GXT 2 depend on GXT 3 or vice versa, and we are not going to do that. We can suggest more workarounds, and provide sample code, but that's about the limit of what the libraries can do.
As I mentioned, in the next GXT 3 release there will be the ability to subclass and takeover the WindowManager, allowing a subclass to call into the 2.x code, but this is really just another workaround.
5 Dec 2012 8:11 AM #9
When I post the bug (with the example ), I'll post a link to it in this thread for good measure.