[Gwt-openlayers-devl] Fwd: GWT-OpenLayers Showcase

[Edwin C. <com...@gm...>]

Hi Andrew,

Maybe it is a nice time to stop supporting the Ant build. At the time
Ant was the fastest way that I could get the test cases running and
there already was an Ant script. The Ant script can be used to build
the GWT-OpenLayers jar, but IMHO Maven is the preferred way. With
Maven we do not need to worry about setting paths to any dependencies
as it can pull GWT jars from the Maven repos :). I will try to get the
test cases running with Maven (possibly using Ant runner), so we can
get rid of the Ant script and stop maintaining different ways to build
GWT-OL, as that is extra work + possibly confusing.

Nice to hear about your experiences with GWT MVP. We are using Spring
for depency injection on the server side, but I have no experience
with GIN DI on the client side. I looked it up and there is some very
minimal mentioning of GIN on the two articles about large scale
application development in the GWT documentation, but no code
illustrations. I probably have to look at the Google IO 2009
presentation for mo re info, or look at some blog posts. For now
Ext-GWT MVC works fine, but on future projects I would like to try
MVP.

Greetings,
Edwin

On 25 May 2010 17:20, Andrew Hughes <ahh...@gm...> wrote:
> Success, but I'm going to bed in a minute - it's very late here!
> I moved the source beneath ./gwt-openlayers, created a new module
> ./gwt-openlayers-showcase and have setup all of the maven dependencies
> gwt==2.0.3, java==1.6, openlayers==2.9.1. There is a stubb project
> in gwt-openlayers-showcase. Everything builds+runs e.t.c.
> The big question is, what should we do about ant support? What I have done
> will most likely break the ant scripts :/ But the showcase did look like it
> was dependent on maven to build gwt-openlayers.jar anyway.
> Very tired, happy to checkin once the ant stuff is confirmed either way :)
> Cheers,
> AH
>
> On Tue, May 25, 2010 at 10:27 PM, Andrew Hughes <ahh...@gm...> wrote:
>>
>> Hi Edwin,
>>
>> On Tue, May 25, 2010 at 6:01 PM, Edwin Commandeur
>> <com...@gm...> wrote:
>>>
>>> Hi Andrew,
>>>
>>> Moving the code base down a directory as you suggest is definitely a
>>> good idea! It was a mistake to have the src dir at the same level as
>>> the showcase dir.
>>
>> Excellent!
>>
>>>
>>> Better a long descriptive name (gwt-openlayers-showcase) than a short
>>> name that is less descriptive :).
>>
>> Agreed!
>>
>>>
>>> Are you taking the actual GWT showcase code as a skeleton? Is that
>>> code free to use that way? The showcase makes use of generators,
>>> aren't those generating stuff you are missing?
>>>
>>
>> I believe it's free for use, but do not remove the copyright comments from
>> the source. I am missing the generator code. Generators look amazing, but I
>> don't fully understand them and don't have the time to learn them :(
>>>
>>> There are two things that would be nice to have, which are not in the
>>> standard GWT showcase: 1) Tooltips over the tree items to provide a
>>> short description of the example; 2) A search function for easily
>>> looking up examples.
>>>
>>
>> Tooltip's would be nice. Perhaps it is possible to add a google search to
>> the site to search the examples? I am not sure but that might be easiest,
>> self updating and work best.
>>
>>>
>>> Interesting that you are using the Google/IO MVP solution. Is that the
>>> solution that is explained on the GWT tutorial? I have been using
>>> Ext-GWT's MVC, which I found very easy to use in practice and it seems
>>> to require a lot less boilerplate code. The major thing I dislike
>>> about using Ext-GWT's MVC is that logic ends up in classes that extend
>>> Ext-GWT classes. However, it seems a bit painful excercise to tear
>>> apart the View and the Presenter, as in the plain GWT solution. Do you
>>> really benefit from that in practice? Acting upon the view appears to
>>> be very tied to the view implementation. Also, the GWT solution seems
>>> to be more abstract, leaving the developers to implement Presenters
>>> and Views in their own ways (which may be a good or a bad thing). In
>>> our apps the models are the data transfer objects, there are
>>> controllers for each cluster of functionality (controllers register on
>>> a dispatcher), and the controllers know about the different views,
>>> which may update themselves in response to events dispatched by the
>>> controller. They views have a method for creating the UI and methods
>>> for acting upon it. The controllers contain stuff that you might want
>>> to unit test. It does seem that it is easy to create an Ext-GWT like
>>> MVC framework using HandlerManager, Handlers and adding simple
>>> abstract View class.
>>>
>>
>> The Google MVP pattern is pretty simple (we're using gwt-presenter). The
>> bit you need to understand is how it's NOT boilerplated together. All of the
>> GWT "best practices" use Gin to @Inject class constructors with what they
>> need to exist. They call it "the new new". To be blunt, Gin is really a way
>> (using annotations and generators) to produce factories, but obviously
>> without the work. I am very happy with it - it only has one known drawback..
>> you still need to boilerplate views to view's via presenters when using the
>> uibinder. But that's a worthwhile trade off.
>> I might get working on the moving e.t.c in a minute and see if I can get
>> something working tonight.
>> Cheers
>> Andrew
>>
>>>
>>> Greetings,
>>> Edwin
>>>
>>> On 25 May 2010 01:42, Andrew Hughes <ahh...@gm...> wrote:
>>> > Hi Edwin,
>>> > The 2.1-M1 "MVP" *looks* to target developers on the google app engine
>>> > who
>>> > want a sping backend. We are using the Google I/O 2009 MVP solution -
>>> > it's
>>> > really really good! I'm trying hard to get the gwtshowcase working -
>>> > but
>>> > they have some classes that aren't released with the user or dev jars!
>>> > I
>>> > will probably raise this as an issue with GWT as I feel they are
>>> > releasing
>>> > reference/source code that won't work against any gwt releases.
>>> > Do you think we can move the current code base down one directory?
>>> > So that this gives...
>>> > ./pom.xml (parent pom)
>>> > ./gwt-openlayers (gwt-openlayers jar)
>>> > ./gwt-openlayers-showcase (gwt-openlayers-showcase war) this is a long
>>> > name
>>> > but it is consistent with other things like the app engine url e.t.c.
>>> > This will make it easier for me to get to work :)
>>> > --AH
>>> > On Tue, May 25, 2010 at 6:14 AM, Edwin Commandeur
>>> > <com...@gm...> wrote:
>>> >>
>>> >> Hi Andrew,
>>> >>
>>> >> Couldn't find any good info on the new MVP either. I hoped it wasn't
>>> >> the MVP they describe in the GWT tutorial
>>> >> (http://code.google.com/webtoolkit/articles/mvp-architecture.html),
>>> >> because I don't think that is a nice solution. I was more hoping that
>>> >> they had a proper eventBus instead of hijacking HandlerManager for
>>> >> that, and a little less convoluted solution.
>>> >>
>>> >> Greetings,
>>> >> Edwin
>>> >>
>>> >> On 23 May 2010 12:49, Andrew Hughes <ahh...@gm...> wrote:
>>> >> > Hi Edwin,
>>> >> > Thanks heaps for your reply :)
>>> >> > FYI:
>>> >> > The 2.1-M1 MVP looks nothing like the existing "MVP Best Practices"
>>> >> > we've
>>> >> > seen come out of google. The only doco I can find is
>>> >> >
>>> >> > this http://blog.springsource.com/2010/05/19/spring-google-appengine/
>>> >> > and it
>>> >> > looks to me like it's about data retrieval from the server! Perhaps
>>> >> > I am
>>> >> > wrong, we will have to see.
>>> >> > I'll try and update the showcase once I find out where the GWT
>>> >> > missing
>>> >> > classes are!
>>> >> >
>>> >> > Cheers.
>>> >> > --AH
>>> >> >
>>> >> >
>>> >> > On Sat, May 22, 2010 at 8:23 PM, Edwin Commandeur
>>> >> > <com...@gm...> wrote:
>>> >> >>
>>> >> >> Hi Andrew,
>>> >> >>
>>> >> >> Great you are putting effort into the showcase. The showcase was
>>> >> >> put
>>> >> >> together a long time back and with the new MVP framework in GWT 2.1
>>> >> >> I
>>> >> >> was thinking of trying that out, but you already have something
>>> >> >> going.
>>> >> >> One thing I would also like to put in the showcase is a working
>>> >> >> 'show
>>> >> >> source panel' that uses a syntax highlighting lib like
>>> >> >> http://alexgorbatchev.com/wiki/SyntaxHighlighter
>>> >> >>
>>> >> >> As you know, the showcase was not setup as a Maven project, but as
>>> >> >> a
>>> >> >> GWT Eclipse plugin project so it would easily run in Eclipse. Right
>>> >> >> now you can just open it as an existing GWT Eclipse project,
>>> >> >> possibly
>>> >> >> change the version of GWT your using and code away. However, I am a
>>> >> >> big fan of Maven and would be in faovour of Maven if it can work in
>>> >> >> such a way that is easy to run and debug the showcase using the GWT
>>> >> >> development mode.
>>> >> >>
>>> >> >> Having the showcase in the cloud would be a big plus! +1 for that
>>> >> >>
>>> >> >> +1 for the zero-arg constructor (if Javadoc explains the how and
>>> >> >> why)
>>> >> >>
>>> >> >> RPC of geometry objects would be possible if
>>> >> >> a) if we create a GeometryFactory which can take an OpenLayers
>>> >> >> geometry, copy all the content to a GWT-OL geometry object
>>> >> >>
>>> >> >> b) if we create geometries that do not wrap Javascript objects, but
>>> >> >> that are converted to OpeneLayers geometry objects when they are
>>> >> >> provided as arguments to GWT-OL functions.
>>> >> >>
>>> >> >> Option b) would be very nice. We should investigate if we can use
>>> >> >> the
>>> >> >> current objects and no longer let them extend
>>> >> >> OpenLayersObjectWrapper,
>>> >> >> but let them be native GWT classes implementing IsSerializable (all
>>> >> >> the implementations of the methods would change as well). Anywhere
>>> >> >> the
>>> >> >> objects would then be provided to OpenLayers as arguments there
>>> >> >> should
>>> >> >> be some GeometryConverter under the hood that copies all properties
>>> >> >> to
>>> >> >> an OL geometry.
>>> >> >> See also:
>>> >> >>
>>> >> >>
>>> >> >> http://code.google.com/webtoolkit/doc/latest/FAQ_Server.html#Does_the_GWT_RPC_system_support_the_use_of_java.io.Serializable
>>> >> >>
>>> >> >> Greetings,
>>> >> >> Edwin
>>> >> >>
>>> >> >>
>>> >> >> On 22 May 2010 10:26, Andrew Hughes <ahh...@gm...> wrote:
>>> >> >> > Hi Edwin,
>>> >> >> > I'd really like to do some work on the showcase. What I would
>>> >> >> > like is
>>> >> >> > too...
>>> >> >> >
>>> >> >> > Take the GWT Showcase application source and replace their
>>> >> >> > examples
>>> >> >> > with
>>> >> >> > ours
>>> >> >> >
>>> >> >> >
>>> >> >> >
>>> >> >> > (see http://ongwt.googlecode.com/svn/trunk/com.google.gwt.sample.showcase.Showcase/Showcase.html)
>>> >> >> > I'm close to getting this working but the (compile time
>>> >> >> > annotations
>>> >> >> > for
>>> >> >> > the
>>> >> >> > generators are relying on gwt classes that aren't in the OEM jars
>>> >> >> > -
>>> >> >> > should
>>> >> >> > be able to get this working soon enough).
>>> >> >> > Deploy the GWT-OpenLayers Showcase to the google app engine. I
>>> >> >> > took
>>> >> >> > the
>>> >> >> > liberty of registering "gwt-openlayers" (and I need to find out
>>> >> >> > how I
>>> >> >> > can
>>> >> >> > share this with you).
>>> >> >> > Populate the showcase with examples....
>>> >> >> >
>>> >> >> > This might be just me but I really do feel this should also be a
>>> >> >> > maven
>>> >> >> > module. I find it very difficult to work with the showcase
>>> >> >> > project in
>>> >> >> > it's
>>> >> >> > current state.
>>> >> >> > Just a few other things...
>>> >> >> > We need client/server rpc serialization of geometry objects. I
>>> >> >> > know
>>> >> >> > you
>>> >> >> > said
>>> >> >> > you had been working on this, any chance I could see how you're
>>> >> >> > trying
>>> >> >> > todo
>>> >> >> > this?
>>> >> >> > We use the UiBinder heaps in our app, the way it applies styles
>>> >> >> > and
>>> >> >> > layout
>>> >> >> > means that the MapWidget should offer a zero arg default
>>> >> >> > constructor.
>>> >> >> > I
>>> >> >> > don't believe there is any requirements from OpenLayers for width
>>> >> >> > and
>>> >> >> > height
>>> >> >> > on init. I think a zero arg constructor might be a good idea (I
>>> >> >> > do
>>> >> >> > have
>>> >> >> > a
>>> >> >> > workaround)
>>> >> >> > Cheers.
>>> >> >
>>> >> >
>>> >
>>> >
>>
>
>