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...
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@example.com.
To post to this group, send email to firstname.lastname@example.org.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
Post a Comment