[Geoserver-devel] Quick Wicket component interactive tester

Andrea_Aime3 · March 16, 2009, 1:22pm

Hi,
working on Wicket UI reminds me a little of my old times
building Swing desktop apps.
One thing that occurred to me is that I used to start
working on a new component by fleshing it just its structure,
and started testing right away by placing a little "main"
directly in the component to run it in isolation.

This of course worked only in the initial phases of development,
once I started hooking the component on the persistence backend
that became harder and harder (unless one mocked per persistence),
but it was a nice way to quickly check the basics of the component
itself.

I was wondering if anything similar was possible for Wicket
webapps, and after some fiddling, I concluded that yeah,
it was.
So I put togheter the attached classes that allow one to
just add a main and run a very quick Wicket webapp around
a single, still non Catalog dependent component.

I used it to quickly test a server side file browser
I'm building in my spare time and it worked nicely.
All I had to do in order to check interactively my
file list viewer was to add the following to its code:

public static void main(String args) {
WicketTestApplication.start(new IComponentFactory() {

         public Component createComponent(String id) {
             FileProvider provider = new FileProvider(new File("c:/progetti/gisData"));
             provider.setSort(new SortParam(FileProvider.NAME, true));
             return new FileDataView(id, provider) {

                 @Override
                 protected void linkNameClicked(File modelObject,
                         AjaxRequestTarget target) {
                     System.out.println(modelObject.getAbsolutePath());
                 }

             };
         }
     });
}

And voilà, you run it, you have a file browser on the specified
path that responds to the user clicks.

I was considering contributing this back to GeoServer:
- do people want it
- where do we put it?

The second question is a harder one, as it requires jetty
in the classpath. Maybe we can roll a module of its own,
and people add it as a provided dependency?
The testing "main" are imho to be removed or commented out
once they served their purpose, but in the meantime the
modules do need those classes and Jetty in the classpath.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

(attachments)

IComponentFactory.java (534 Bytes)
TestHomePage.java (1.03 KB)
WicketTestApplication.java (2.7 KB)
TestHomePage.html (75 Bytes)

Justin_Deoliveira · March 16, 2009, 2:08pm

I definitely think this would be useful. I am currently working on a re-usable widget to be used for bounding boxes and this sort of mock up wold be really useful.

As for where to put it what about just in the same place as Start.java, under web-app/src/test, since the dependency on jetty is already there? And all the components should be available on the classpath.

Andrea Aime wrote:

Hi,
working on Wicket UI reminds me a little of my old times
building Swing desktop apps.
One thing that occurred to me is that I used to start
working on a new component by fleshing it just its structure,
and started testing right away by placing a little "main"
directly in the component to run it in isolation.

This of course worked only in the initial phases of development,
once I started hooking the component on the persistence backend
that became harder and harder (unless one mocked per persistence),
but it was a nice way to quickly check the basics of the component
itself.

I was wondering if anything similar was possible for Wicket
webapps, and after some fiddling, I concluded that yeah,
it was.
So I put togheter the attached classes that allow one to
just add a main and run a very quick Wicket webapp around
a single, still non Catalog dependent component.

I used it to quickly test a server side file browser
I'm building in my spare time and it worked nicely.
All I had to do in order to check interactively my
file list viewer was to add the following to its code:

public static void main(String args) {
    WicketTestApplication.start(new IComponentFactory() {

        public Component createComponent(String id) {
            FileProvider provider = new FileProvider(new File("c:/progetti/gisData"));
            provider.setSort(new SortParam(FileProvider.NAME, true));
            return new FileDataView(id, provider) {

                @Override
                protected void linkNameClicked(File modelObject,
                        AjaxRequestTarget target) {
                    System.out.println(modelObject.getAbsolutePath());
                }

            };
        }
    });
}

And voilà, you run it, you have a file browser on the specified
path that responds to the user clicks.

I was considering contributing this back to GeoServer:
- do people want it
- where do we put it?

The second question is a harder one, as it requires jetty
in the classpath. Maybe we can roll a module of its own,
and people add it as a provided dependency?
The testing "main" are imho to be removed or commented out
once they served their purpose, but in the meantime the
modules do need those classes and Jetty in the classpath.

Cheers
Andrea

------------------------------------------------------------------------

------------------------------------------------------------------------

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com

------------------------------------------------------------------------

_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Andrea_Aime3 · March 16, 2009, 2:25pm

Justin Deoliveira ha scritto:

I definitely think this would be useful. I am currently working on a re-usable widget to be used for bounding boxes and this sort of mock up wold be really useful.

As for where to put it what about just in the same place as Start.java, under web-app/src/test, since the dependency on jetty is already there? And all the components should be available on the classpath.

Ok, so in this case you'd have to create a temporary class with
a main to start the component, instead of adding it to the
component under test itself.
On the bright side, that would help reminding people of getting rid of
that test code before committing.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Justin_Deoliveira · March 16, 2009, 2:55pm

Ok, so in this case you'd have to create a temporary class with
a main to start the component, instead of adding it to the
component under test itself.

I think I am missing something. I was thinking just add the class with the main method into svn and then perhaps just comment out the call to WicketTestApplication.start() ? Apologies if I am mis understanding.

On the bright side, that would help reminding people of getting rid of
that test code before committing.

We could add an svn:ignore that would prevent any commits?

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Andrea_Aime3 · March 16, 2009, 2:58pm

Justin Deoliveira ha scritto:

Ok, so in this case you'd have to create a temporary class with
a main to start the component, instead of adding it to the
component under test itself.

I think I am missing something. I was thinking just add the class with the main method into svn and then perhaps just comment out the call to WicketTestApplication.start() ? Apologies if I am mis understanding.

In order to do that the testing classes I provided earlier should
be in the component classpath, not vice-versa (the Eclipse module
containing the component won't see the testing classes otherwise).

On the bright side, that would help reminding people of getting rid of
that test code before committing.

We could add an svn:ignore that would prevent any commits?

Could be a way, yeah.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Justin_Deoliveira · March 16, 2009, 3:08pm

Andrea Aime wrote:

Justin Deoliveira ha scritto:

Ok, so in this case you'd have to create a temporary class with
a main to start the component, instead of adding it to the
component under test itself.

I think I am missing something. I was thinking just add the class with the main method into svn and then perhaps just comment out the call to WicketTestApplication.start() ? Apologies if I am mis understanding.

In order to do that the testing classes I provided earlier should
be in the component classpath, not vice-versa (the Eclipse module
containing the component won't see the testing classes otherwise).

I still don't quite understand. So the component being tested (or the module containing the component being tested) needs to be be able to see the test classes you provided? Ie needs to depend on them? I admit I did not look at the them, just the code snippet you provided.

Anyways, instead of continuing to annoy you with questions I will put aside some time to actually look at the classes you provided. Then hopefully it will make sense.

On the bright side, that would help reminding people of getting rid of
that test code before committing.

We could add an svn:ignore that would prevent any commits?

Could be a way, yeah.

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Andrea_Aime3 · March 16, 2009, 3:21pm

Justin Deoliveira ha scritto:

I still don't quite understand. So the component being tested (or the module containing the component being tested) needs to be be able to see the test classes you provided? Ie needs to depend on them? I admit I did not look at the them, just the code snippet you provided.

If you place the main inside the component class itself, yep.
That's what I wrote in my first mail:

"and started testing right away by placing a little "main"
directly in the component to run it in isolation"

But I'm ok in rolling out a separate class to contain just
the "main"

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Justin_Deoliveira · March 16, 2009, 3:27pm

If you place the main inside the component class itself, yep.
That's what I wrote in my first mail:

"and started testing right away by placing a little "main"
directly in the component to run it in isolation"

But I'm ok in rolling out a separate class to contain just
the "main"

Sorry I missed the subtlety. But yes the latter is what I assumed.

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Andrea_Aime3 · March 16, 2009, 4:15pm

Justin Deoliveira ha scritto:

If you place the main inside the component class itself, yep.
That's what I wrote in my first mail:

"and started testing right away by placing a little "main"
directly in the component to run it in isolation"

But I'm ok in rolling out a separate class to contain just
the "main"

Sorry I missed the subtlety. But yes the latter is what I assumed.

Ok, I committed the classes in the test package of web-app.
Let me know how they work for you.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

Justin_Deoliveira · March 17, 2009, 1:08am

Hi Andrea,

I tried the classes out and they work great... except with regard to some of the i18n lookups. When the key is one of the generic keys located in the root GeoServerApplication.properties file the look up fails and the component does to load.

I created a jira issue report and attached a patch:

http://jira.codehaus.org/browse/GEOS-2758

Let me know what you think.

I also noticed that the formatting of the WicketTestApplication is off and contains a lot tabs rather than spaces.

-Justin

Andrea Aime wrote:

Justin Deoliveira ha scritto:

If you place the main inside the component class itself, yep.
That's what I wrote in my first mail:

"and started testing right away by placing a little "main"
directly in the component to run it in isolation"

But I'm ok in rolling out a separate class to contain just
the "main"

Sorry I missed the subtlety. But yes the latter is what I assumed.

Ok, I committed the classes in the test package of web-app.
Let me know how they work for you.

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

Justin_Deoliveira · March 17, 2009, 4:30am

I just added some bits to the header of TestHomePage.html so that the same css and images (linked via an external) are used as when actually running GeoServer. Now tested components should look like the real deal.

-Justin

Andrea Aime wrote:

Justin Deoliveira ha scritto:

If you place the main inside the component class itself, yep.
That's what I wrote in my first mail:

"and started testing right away by placing a little "main"
directly in the component to run it in isolation"

But I'm ok in rolling out a separate class to contain just
the "main"

Sorry I missed the subtlety. But yes the latter is what I assumed.

Ok, I committed the classes in the test package of web-app.
Let me know how they work for you.

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.