Code references between client/server/shared folders

[Magnus]

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.

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.

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?

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

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.)

Thanks
Magnus

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

[Jens]

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

It is just a convention, you can generally use whatever folders you want to organize your code. This convention has been made primarily for projects that have client/shared/server code in the same code base (the default project layout if you create one using the GWT Eclipse Plugin). Maven projects usually consists of multiple modules which makes this distinction via package names optional.

 

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.

Right, if you have made client/shared folder visible to the GWT compiler using the <source path="..."/> tags in your *.gwt.xml file. If there isn't any such tag then <source path="client"/> will be assumed as a default by GWT compiler.

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.

Generally yes, but you could also use Java classes that GWT does not understand out of the box. You would then mark code as @GwtIncompatible if you don't need it on the client or you provide a super-source implementation. For the past GWT releases a good example might be ConcurrentMap which GWT does not support out of the box but might be useful in a shared class.

 

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?

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

If will fail to compile if you don't have that class on your classpath. In your specific example if will probably work if you use GWT-RPC because then you need gwt-servlet.jar on your classpath which in turn contains this class (yes it is a bit weird to have a server jar with client classes in it but well).

 

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.)

You could make your TimeFormatter class the single source for time formatting in your project. In that case you would move it into your shared folder, implement it using SimpleDateFormat.format() and in addition provide a super-source version of TimeFormatter for GWT compiler which will use com.google.gwt.i18n.client.DateTimeFormat to implement the TimeFormatter API. Alternatively you could emulate SimpleDateFormat.format() by providing a super-source version of SimpleDateFormat. The whole approach is the same GWT itself uses to let you use all the emulated JRE classes in the browser.

Alternatively you could use com.google.gwt.i18n.shared.DateTimeFormat to implement your TimeFormatter class. Then it should work on server and client but then your server has an additional dependency to GWT, maybe you don't want that.

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

"public" folders are folders whose content will be copied by the GWT compiler to the GWT compile output folder without any modifications. If a project uses it then mostly for images (e.g. favicon.ico and the like), css, html. The name "public" is also just a convention and can be changed by adding <public path="some folder" /> to your *.gwt.xml file.

-- J.

[harshyadav]

I usually only call the shared code form the client (and not the other way round).

You can have separate TimeFormatter:

one for client --> 

com.google.gwt.i18n.client.*

and one for server or shared (if its used by other server side modules as well) -->

java.time.*   java.util.Date

If your TimeFormatter is in the shared module (use case: multiple server modules using it), you can tell the GWT compiler to exclude it:

<source path='shared'>

 <exclude name="**/TimeFormatter.java" />

..... 

The public folder is usually used to server public assets like your  html, or external js or css files (for e.g. bootstrap or jQuery)

[Thomas Broyer]

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 

[Natan]

If there are no visual classes, functionality will normally occur. Regarding your comment, javac will always be applied in all classes, regardless of what directory they are in. The classes destined to the sharing between client and server, it is sufficient to implement them without using any graphical interface.

sorry my english.

Natan.

--
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 google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Magnus]

Hello all!

Thomas wrote:

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).

Sounds good! But this approach also confirms that there really isn't a common solution for both server and client for this simple task.

In contrast, if you would do the formatting stuff with your own code in the shared area (based on java.util.Date), you could go with a single implementation.

In this case, you wouldn't need much code to do the formatting. Wouldn't this be cleaner?

 

> This means your Move class will receive a TimeFormatter (interface) as argument

Oh, this sounds like touching much code, since all instantiations would get a new parameter. I'd like to avoid that. Can't you pass this information in an alternative way, e. g. by an annotation or something like that?

I still feel that I need a solution that lives completely in the shared area, without making distinctions between server-side and client-side code...

Regards
Magnus