On Tuesday, May 30, 2017 at 5:36:01 PM UTC+2, Magnus wrote:
>
> Hello,
>
> my understanding of the typical folders in a GWT project is this:
>
>    - client
>    only client-side code here
>    - server
>    only server-side code here
>    - shared
>    code that may be used on client-side and server-side
>
> I believe that the code in the client folder gets compiled by the GWT 
> compiler into JS only, while the code in the server folder gets compiled by 
> javac into class files only.
> Besides that, code in the shared folder gets compiled twice, once by the 
> GWT compiler and once from javac.
>

You'll probably want to use javac on client code too; if only to get faster 
feedback for compilation errors. There are a few cases where GWT will look 
for the compiled classes too, so better have them.
 

> My understanding always was that the code in the shared folder must be 
> "pure" java, so that it can be compiled in both worlds, without any 
> references into pure client-side code.
>

As Jens said, those are only conventions. For example, you'll find in GWT 
that the RemoteService interface is in the "client" package (this is 
legacy, because it predates the convention of using a "shared" package)
Also note that it's not about compilation (all your client code will 
compile using javac) but runtime (client-side code won't work in a JVM, 
i.e. on the server)
 

> So far so good. But what happens, when code in the shared folder 
> references some classes in the client folder?
> I have just found such an example in my projects:
>
>    - There is a class Move that represents a move in a chess game.
>    It's located in the shared folder, since it's used by the server and 
>    the client.
>    - The class Move uses a class TimeFormatter (to format timestamps as 
>    "yyyy-mm-dd hh:mm:ss").
>    It's located in the client code and in turn uses the class 
>    com.google.gwt.i18n.client.DateTimeFormat.
>
> What happens, when the javac compiler sees the Move class?
>

It depends how you invoke javac.
If the folders you're talking about are subpackages in the same source 
tree, then just pass everything at once to javac and GWT (there's a reason 
GWT has those *.gwt.xml files with <source path="…"/> elements in there)
 

> What does it do with com.google.gwt.i18n.client.DateTimeFormat when 
> compiling server-side code?
>

If it's in the classpath (gwt-user.jar or gwt-servlet.jar), it'll compile.
You should probably be more concerned about runtime behavior though: if you 
call that code on the server, it'll throw.
 

> Should I move TimeFormatter into the shared folder, too?
> And one more step: Could you use the same time formatting code in client 
> and server code?
> (At the moment I use com.google.gwt.i18n.client.DateTimeFormat at the 
> client and SimpleDateFormat.format at the client.)
>

Jens suggested c.g.g.i.shared.DateTimeFormat; I wouldn't recommend it 
though (needs some additional setup on server-side, almost nobody uses it 
on server-side so you're basically on your own if you need help).

The best practice is to abstract both approaches behind an interface (or 
abstract class), that you'd put in the "shared" package, then have concrete 
implementations in the "client" and "server" packages, and arrange your 
code to use an instance of the appropriate implementation depending on the 
context (using the dependency injection pattern helps here). This means 
your Move class will receive a TimeFormatter (interface) as argument and 
will never instantiate one (ClientTimeFormatter or ServerTimeFormatter).
Super-source, as explained by Jens, also works, but is IMO more complex (to 
understand and maintain).
 

> BTW: What's the "public" folder for? I saw it in some projects but not in 
> the docs...
>

See 
http://www.gwtproject.org/doc/latest/DevGuideOrganizingProjects.html#DevGuideModules
 

-- 
You received this message because you are subscribed to the Google Groups "GWT 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Reply via email to