mraible wrote:

I was going to bring up this on the mailing list anyway, Matt, you've come up with one way of integrating GWT into a back-end - i.e. using RESTful services.

This is actually the way I initially investigated when going down the GWT route, I put it to one side in the end for a number of reasons: a. I didn't feel that there a stable Restful solution that was suitable for us (RESTlet has a GWT plug-in now, so that's possibly no longer the case). b. I have some concerns about not making the client too thick - we didn't have the time to learn how to architecture a proper RESTful system at the same time as using GWT for the first time, I had concerns that we may end up with all the business logic in the client, rather than on the server.

I'm not a RESTful expert though, so will bow to more experience people in this respect. I still haven't totally discarded using it myself, but there's question marks in my mind at the moment.

Alternatives .... there's 2 that spring to mind ...

1. If we're talking hibernate as the persistence mechanism, then Gilead (formerly Hibernate4GWT) is an option.

2. Map the valueobjects to DTO's using Dozer, or equivalent. We can therefore be picky and cut down what get's transferred across the wire to the client.

The latter DTO option is what we've used currently. I was not happy at the project start that Hibernate4GWT was polished enough, and I had some concerns about the amount of traffic that would go to the client if we just sent our current models over. Also there was the high likelihood that some of managers would also be exposed to non java consumers as web services, so our use of some of the Java Collection classes in the model objects could have caused issues. (Our DTO's flatten out any collection objects to arrays.)

In the process of implementing this, I took the GenericManager and created a generic Mapping version of it, so that the mapping between model objects and dto's was handled in the base class (with the option of overriding, if necessary).

So, our back-end consists of Manager's and DAO's as normal (for appfuse), our GWT client talks to the managers directly using the Spring MVC DispatcherServlet.

Moving onto your point 2, I agree with having whatever back-end on a different port, so that you can still use Hosted mode for development of the client.

GWT 1.6 is going to bring some very good improvements in - Jetty as the hosted mode server for one, and better design of where compiled artifacts go, amongst many others ...

As for SmartGWT, that's a no-brainer, in my opinion, our current project relies upon GWT-EXT, but I've had plans for some time to remove this in favour of SmartGWT.

As for my maven/appfuse archetype proposal, what I was thinking about doing was one or both of Gilead/DTO mapping, and create a GWT/SpringMVC/{Hibernate} archetype. I'd appreciate people's thoughts on this. Is it worth doing? or should we be following Matt's route? Or are a tutorial or two (of the non RESTful routes) explaining the integration of GWT with Appfuse enough?