It would be nice to extends existing patchers.

[GoogleCodeExporter]

It would be nice to extends existing patchers.
For example if the patcher for class X just exist you can not add new patcher 
with the same X class. You will receive exception - "Patcher for class X 
already exist"

Problem is mainly for gxt classes (new version 2.2.4 contains new methods). Gwt 
patchers are up to date.

Original issue reported on code.google.com by Andrzej....@gmail.com on 2 Jun 2011 at 10:01

[GoogleCodeExporter]

I'm really not sure if give the possibility to extend existing gwt-test-utils 
patchers would be a good idea. 

native patchers are supposed to simulate the GWT basic behavior. When they 
don't, it probably is an "bug" and the framework community should open an issue 
(and, in the most beautiful world, provide a nice patch ;-)).

Despite gwt-test-utils is currently not designed to allow such extensions 
(@PatchMethod are static, and the order of patcher loading is not known), it 
would be possible with some refactoring. But the danger here is the 
multiplication of forks, which would not help to get gwt-test-utils better ?

What do you think ?

By the way, gwt-test-utils-gxt should be updated with gxt-2.2.4 and I will do 
that :

http://code.google.com/p/gwt-test-utils/issues/detail?id=47

Since I'm not very used to GXT, could you help me by identifying which patchers 
are out of date ? Thank you very much !

Original comment by gael.laz...@gmail.com on 3 Jun 2011 at 4:36

[GoogleCodeExporter]

GXT library has a lot of native javascript code. It is easy to stub the methods 
(what I mainly need), but it is hard to translate existing javascript to java 
method.

Some patched used by us internally:
----------------------------------
WidgetComponentPatcher.java
    @Test
    public void testSetParent(){
        ContentPanel panel = new ContentPanel();
        panel.add(new Button());
        panel.removeAll();
    }
----------------------------------
WindowPatcher.java (com.extjs.gxt.ui.client.core.XDOM class should be patched, 
but patch already exist)
    @Test
    public void testWindow(){
        Window window = new Window();
        window.show();
    }
----------------------------------
JSONObjectPatcher.java - I do not have test for it. It patch gwt class 
com.google.gwt.json.client.JSONObject
----------------------------------
JsObjectPatcher.java - It is mainly stub for com.extjs.gxt.ui.client.js.JsObject
JsUtilPatcher.java
    @Test
    public void testChart(){
        Chart chart = new Chart("Url");
        chart.setChartModel(new ChartModel("title"));
    }
-----------------------------------------------------------

Original comment by Andrzej....@gmail.com on 7 Jun 2011 at 8:57

Attachments:

• WidgetComponentPatcher.java
• WindowPatcher.java
• JSONObjectPatcher.java
• JsObjectPatcher.java
• JsUtilPatcher.java

[GoogleCodeExporter]

Thank you very much. I'll add those unit test and make them work by adding your 
patches (just note that such unit test should have some assertions to actually 
"check" something, not only the fact that gwt-test-utils allow widget 
instanciation correctly in the JVM).

I know it's hard to get what happen in javascript happen in java, it's the 
trickiest part of gwt-test-utils ^^

By the way, do you have some maven public repository where I could find 
gxt-2.2.4 ?

Thank you again !

Original comment by gael.laz...@gmail.com on 7 Jun 2011 at 11:25

[GoogleCodeExporter]

We used special version for us. The one of public repository is (I do not use 
it, we installed it in our internal archiva):

http://maven.alfresco.com/nexus/content/repositories/public/com/extjs/gxt/2.2.4/

The unit test which I included are the place where tests fail. We use mvp4g and 
all logic are in presenters.

Best regards,

Original comment by Andrzej....@gmail.com on 7 Jun 2011 at 2:32

[GoogleCodeExporter]

Thanks !

I'll work on the GXT 2.2.4 migration very soon. I've also started a big 
refactor of the patcher mechansim to enable developers to extend gwt-test-utils 
patchers since they may want to override the default behaviour for performance 
issue or whatever.

But I hope gwt-test-utils users will still report bug and not patched standard 
method even if they could override them easily.

The feature will be available and announced on the user mailing list very soon 
:-)

Original comment by gael.laz...@gmail.com on 14 Jun 2011 at 10:20

• Changed state: Started
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

The patch overriding feature is now available on lastest snapshots 
(0.30-SNAPSHOT for GWT 2.3, 0.28.4-SNAPSHOT for GWT 2.2)

I also started the documentation of the patching mechanism. It can be read here 
: http://code.google.com/p/gwt-test-utils/wiki/HowToWriteCustomPatchers

Could you please give it a try before the release of the 0.30 version ?

Original comment by gael.laz...@gmail.com on 16 Jun 2011 at 4:22

[GoogleCodeExporter]

I've also add a few patch for GXT (see WindowPatcher and WindowTest in the 
source code).

I'll release the 0.30 version in a few hours. It would be nice if you could try 
some patch override before that !

Original comment by gael.laz...@gmail.com on 21 Jun 2011 at 11:26

• Changed state: Fixed

[GoogleCodeExporter]

Now is very nice. 

I added new class - reload method was not patched before (XDOM.class just has 
patcher XDOMPatcher.class):

@PatchClass(XDOM.class)
class XDOMPatcher2 {

    @PatchMethod
    public static void reload() {
        //
    }
}

So now you can add second Patcher class for not patched methods. Or override 
existing one.

Original comment by Andrzej....@gmail.com on 22 Jun 2011 at 9:37