PDA

View Full Version : Should GXT implement HasHandlers interfaces?



d95sld95
7 Aug 2009, 9:01 AM
Are there any plans to implement the HasHandlers interfaces to GXT Button (HasClickHandler) and other GXT components like the native GWT widgets?

Example:

TestView.java


Button button = new Button("Test button");

public HasClickHandlers getTestClickHandlers() {
return button;
}

TestPresenter.java


public TestPresenter(View view, final EventBus eventBus) {
view.getTestClickHandlers().addClickHandler(new ClickHandler() {
public void onClick(ClickEvent event) {
eventBus.fireEvent(new TestAlert());
}
}
}

mraible
25 Aug 2009, 5:40 PM
I'm interested in this as well. Are there plans to make GXT more MVP-friendly?

sven
25 Aug 2009, 10:27 PM
I'm interested in this as well. Are there plans to make GXT more MVP-friendly?

The hasHandlers interface are not making GXT anymore MVPfriendly. You can do the same with GXT since the beginning. There are no plans to add them

mraible
25 Aug 2009, 10:46 PM
The hasHandlers interface are not making GXT anymore MVPfriendly. You can do the same with GXT since the beginning. There are no plans to add them as that would change the hole system GXT works.

Pardon my ignorance, but how would you suggest the above code be written when using GXT's Button class?

sven
25 Aug 2009, 11:31 PM
public TestPresenter(View view, final EventBus eventBus) {
view.getComponent().addListener(Events.Select, new Listener<ComponentEvent>() {
public void handleEvent(ComponentEventce) {
eventBus.fireEvent(new TestAlert());
}
}
}

sven
25 Aug 2009, 11:33 PM
Instead of the eventbus from GWT you can even use the Dispatcher that is shipped with GXT, also since very long ;)

sandlee
26 Aug 2009, 5:13 AM
GXT should use interfaces like GWT does. Not implicitly HasClickHandlers, but there are much other which were easy to implement: e.g.


HasValue
Focusable
HasText
HasCaption
HasEnable
...

this would allow us to mock the widgets for unit-tests.
(At the moment, this is impossible. see http://www.extjs.com/forum/showthread.php?t=76756 and http://www.extjs.com/forum/showthread.php?t=63053)

mraible
27 Aug 2009, 9:27 AM
GXT should use interfaces like GWT does. Not implicitly HasClickHandlers, but there are much other which were easy to implement: e.g.


HasValue
Focusable
HasText
HasCaption
HasEnable
...

this would allow us to mock the widgets for unit-tests.
(At the moment, this is impossible. see http://www.extjs.com/forum/showthread.php?t=76756 and http://www.extjs.com/forum/showthread.php?t=63053)

I believe the easiest solution to solve this problem is to subclass GXT's Widgets and implement the interfaces. Has anyone done this? If not, maybe we should start an open source project that does this for everyone.

Thoughts?

abickford
8 Sep 2009, 12:22 PM
This would go a long way towards integrating GXT with other 3rd party GWT libraries.

misqu
21 Oct 2009, 12:07 PM
I also vote for implementing those GWT interfaces in GXT.

As long as MVP pattern becoming more popular in let say "GWT world", different aproach to handling events and obtaining values from GXT widgets seems to be not very practical and confusing, especially when using other widget libraries.

GXT should help us to apply good programing patterns.

flashcloud
30 Dec 2009, 12:58 AM
public TestPresenter(View view, final EventBus eventBus) {
view.getComponent().addListener(Events.Select, new Listener<ComponentEvent>() {
public void handleEvent(ComponentEventce) {
eventBus.fireEvent(new TestAlert());
}
}
}

but, this is not conducive to MOCK testing:(

mabco
7 Jan 2010, 12:11 AM
BUMP


I believe the easiest solution to solve this problem is to subclass GXT's Widgets and implement the interfaces. Has anyone done this? If not, maybe we should start an open source project that does this for everyone.

Thoughts?

Sounds good, I'll help!

deanna
7 Jan 2010, 6:40 AM
Let me add my vote in favor of the Has... interfaces. Right now GXT has a different paradigm than GWT making coding for GXT difficult if you want to use the GWT paradigm, and the GWT paradigm is well defined and documented with tutorials. It hurts the value of GXT to not be compatible with GWT at every level.

dardison
7 Jan 2010, 9:10 AM
It would be nice to know the opinion of the people within Ext on this issue. Darrell are you out there monitoring this? Please make a comment about the issue.
By the way, don't you think these forums have been a little quiet, of official voices, lately?

Thanks.
Daniel

chalu
2 Feb 2010, 4:08 PM
GXT's lack of compatibility with GWT and almost no documentation is worrisome, if there are ways of doing these GWT stuff in GXT then we'd like to know how to implement them, and I'm hoping that the GXT-way will actually for third party library integrations e.g GILEAD.

eugenparaschiv
8 Feb 2010, 2:31 PM
Quick through about the idea of extending all GXT components for the purposes of mocking, testing in a VM and just because it's good practice. I've been struggling with the inherent limitations of GXT in this area for a while now, and I've taken the time to subclass each and every GXT component, extracting interfaces from them. The interfaces have the same hierarchical structure as the GXT components, and are simply implemented like so:


public class VButton extends Button implement IButton{
// no implementation
}
This approach has worked just fine...the code is easily maintainable as it doesn't really change that much (perhaps a method signature from time to time, but nothing major). It has allowed a very good level of mocking and testing (it has also kept my presenters clean).
Perhaps a next step is to start integrating GWT components, but that would mean to start adding logic, and I'm still in the planning stages with that.
There is a necessity for some simple manual mocks of these visual components, to complement what Mockito (or another mocking framework) cannot do. This also works well.
I will probably start a google project based on this, and I will probably post the link here or in a new thread. Hope this is what some of the previous posters had in mind.
Also, a link to one of my previous posts on the subject: http://www.extjs.com/forum/showthread.php?t=84928
Cheers.
Eugen

misqu
9 Feb 2010, 4:04 AM
I am also writing my own implementation of the GXT widgets.

But I'm trying to implement standard gwt Has* interfaces. So here is a bit of the my button implementation :



public class Button extends com.extjs.gxt.ui.client.widget.button.Button
implements HasClickHandlers, HasState, HasText {

@Override
public HandlerRegistration addClickHandler(ClickHandler handler) {
return addHandler(handler, ClickEvent.getType());
}
}


I'm using mvp library (gwt-presenter + gwt-dispatch) with gin so I can easily switch the view implementations.

But anyway I'd like to not doing this. I hope that some day GXT will be 100% compatible with GWT.
GXT looks great but the design of the library isn't very impressive (like my english :) ).

For example in one of or project we are using the webdesktop feature. In gxt class desktop is the container of other widgets such as startmenu. The problem occurs when I want to provide my own implementation of the StartMenu I can't simply call setStartMenu on the desktop instance or pass the implementation in the desktop constructor.
There are also other bizarre classes, one of them is MessageBox.

I don't get it why it is not a subclass of the dialog with some predefined styles and static methods for displaying message boxes ?

eugenparaschiv
9 Feb 2010, 4:27 AM
That's cool, and I see it as very useful, but a simple layer that just sits on top of the GXT widgets shouldn't add logic. Over this simple layer, you can add another that does what you're saying, but for simple usage, they shouldn't be bound together. This way the migration path should be is very easy and straightforward, as you would only have to change some references to variables, some instantiations and no more. That being said, the idea of integrating the GWT interfaces has added value. Cheers.
Eugen.

nwallman
15 Feb 2010, 10:43 AM
It would be nice to know the opinion of the people within Ext on this issue. Darrell are you out there monitoring this? Please make a comment about the issue.
By the way, don't you think these forums have been a little quiet, of official voices, lately?

Thanks.
Daniel

I too would be interested to hear what people within Ext are thinking. Things like are they planing on implementing this stuff in GXT 3.0. The library is great and I think it would be by far the best option if it was more in line with how GWT did things. Thats my one hang up right now. If I at least had an idea of their plans it would make the decision much easier.

eugenparaschiv
10 Mar 2010, 5:11 AM
Ok, as a result of this discussion and some other threads all over the GXT forums, I created a google code project to address the problem. It is a thin layer of interfaces and simple implementations that sits on top of the GXT framework. The main purpose is to provide a simple way of creating code that is completely testable and mockable via mocking frameworks (such as Mockito).
http://code.google.com/p/gxt-interfaces/
I will try to upload the artifact on some public maven repos as well, but in the meantime, just import the code. Hope it helps. Eugen.

jorel2
3 May 2010, 7:42 AM
I too would be interested to hear what people within Ext are thinking. Things like are they planing on implementing this stuff in GXT 3.0. The library is great and I think it would be by far the best option if it was more in line with how GWT did things. Thats my one hang up right now. If I at least had an idea of their plans it would make the decision much easier.

I totally agree. When I jettisoned Flex for GWT, my first task was to learn GWT, not GXT. Learning GWT involved reading their tutorials and learning what Google recommends for GWT usage. Along the way I watched the famous GoogleIO May 28, 2009 presentation by Ray Ryan (http://www.youtube.com/watch?v=PDuhR18-EdM). I think that any widget set that wants to really attract developers by the thousands will design their widgets accordingly - with support for these best practices built in so that we can use them with minimal ramp-up time.

So, I would like to 'officially' add my vote for GWT-style MVP support for GXT. I really think this would be a big win for all involved. For the GXT users, it would allow us to develop our code based on GWT best practices like MVP and unit testing. For EXT, they would become the most popular GWT widget library in the known universe.

In the interim I would like to collaborate on a clean wrapper to accomplish this with minimal complexity. Towards that goal, we should avoid inheritance and embrace composition - basically we need to follow the advice from Joshua Bloch's book, "Effective Java 2nd edition", item 16.

dardison
3 May 2010, 8:34 AM
Hey guys, they said they would on version 3
checkout this: http://www.extjs.com/products/gwt/roadmap.php

eugenparaschiv
4 May 2010, 11:05 PM
Yes, very cool, but when?

micgala
4 May 2010, 11:41 PM
Unfortunatelly there is no time frame...

Being a little bit speculative, I would expect something for End 2010/Beginning 2011... but that's only MY thought.

phyto
31 May 2010, 8:43 PM
+1 on Has interfaces in GXT. I am starting a GWT project and was totally sold on GXT. Now looking into making MVP work and it's not as glamorous. Very glad to see it's on the roadmap. In the mean time I will check out that gxt-interfaces project.

owenmohd
4 Sep 2010, 7:37 AM
Ok, as a result of this discussion and some other threads all over the GXT forums, I created a google code project to address the problem. It is a thin layer of interfaces and simple implementations that sits on top of the GXT framework. The main purpose is to provide a simple way of creating code that is completely testable and mockable via mocking frameworks (such as Mockito).
http://code.google.com/p/gxt-interfaces/
I will try to upload the artifact on some public maven repos as well, but in the meantime, just import the code. Hope it helps. Eugen.

Awesome work here.