On 1 avr, 21:27, Ken <kenxu...@yahoo.com> wrote:
> In GWT recommended project structure, client code and server code are
> placed in one project. I find this structure is not so development-
> friendly in practice. (GWT 1.6 has some new update to the project
> structure to make it more like standard WAR project, but client and
> server code are still in one project.)
>
> Client code will be eventually compiled to Javascript and run on web
> browser. Server code will run on web server. These two parts of code
> shouldn’t reference to each other. The only connection between them
> should be the RPC interface (sub-interfaces of RemoteService) and DTOs
> (the Java objects get transmitted between client and server). Any
> attempt to let your widget reference to an RPC implementation Servlet
> or let the Servlet reference to a widget is wrong. However, your Java
> compiler (not GWT compiler) can not detect this kind of error, as
> these Java classes are all in the same project, and they are “allowed”
> to reference to each other. You can’t detect the error either in
> hosted mode, because client and server code run in same JVM in hosted
> mode. You only can find out half the issue when you call GWTCompiler
> (Compiler in GWT 1.6) to translate the client to Javascript. I say
> half because GWTCompiler only shows you the toxic references from
> client to server, but not the other way.
>
> A solution would be to have three projects instead of one:
> MyProjectRpc
> MyProjectGwt
> MyProjectWeb
>
> MyProjectRpc is a GWT module. It only contains RemoteService
> interfaces and DTOs. It has no UI or widgets.

Note that if you use the same packages as in MyProjectGwt, your don't
*need* the make it module (GWT compiler loads from classpath, wherever
your files actually live); though I'd say it's still good practice to
make it a module (I seem to remember GWTShell having problems when
changing code in an inherited module: the code change wasn't picked up
and your client code was still running with the previous code unless
you exit and re-launch the GWTShell; am I mistaken?)

> MyProjectGwt is your client module. It inherits MyProjectRpc, and
> contains widgets. MyProjectGwt’s Java build path includes
> MyProjectRpc.
> MyProjectWeb is your server project. It is a standard WAR project.
> Your RPC implementation servlets go here. Its Java build path includes
> MyProjectRpc.
>
> Therefore, both MyProjectGwt and MyProjectWeb reference to
> MyProjectRpc only. If your widgets incidentally reference to a
> servlet, Eclipse (Java compiler) will tell you right away.

Agreed (though sticking to the recommended client and server, and
possibly shared, subpackages, it's still fairly easy to *not*
reference client code form server code and vice versa).

> To make above solution work, you need to configure GWTCompiler to
> output to MyProjectWeb instead of the default folder www. (-out
> argument will do the job.)

Er, why? Doesn't it all depend how you're building and deploying your
app?

> You also need to run your own web server
> for hosted mode instead of GWT’s internal Tomcat. (Pass –noserver to
> GWTShell.)

Why not just give the MyProjectWeb project to the GWTShell in the
classpath? Provided you used the "client" and "server" subpackages of
the same "root" package in all three projects (or made a gwt module in
the same package as the server code in the MyProjectGwt project and
inherited it appropriately), with the appropriate <servlet/>
declarations in your GWT module, the GWTShell should pick up your
servlets and it should "just work" without the need for a standalone
servlet container.

When not using GWT-RPC (but still using Java on the server side), I
however highly suggest using two distinct projects (no need for a
shared project in this case) as in this case your client and server
code are not as tightly coupled as with GWT-RPC, so they can leave
their own life and be tested independently (we're in such a
configuration at work, and actually one of us is only working on the
server code, another only working on the client code and I, as a
project leader, work on both sides to coordinate the devs)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to