> The way I interpreted this(the stock watcher demo approach) is that the
> classes used to transfer data are, by virtue of them being in the remote
> service, available to client and server.
> You do not need to do anything special. However if you have a utility,
> validation or some sort of common functionality between client and server,
> that is where the shared comes in.
I for one put services in a "shared" package. It might be that in the
stock watcher sample they considered RPC to be "a client dependency/
constraint that the server has to fulfill" (to be able to communicate
with the client app), hence the "client" package; whereas "shared" is
used for "shared code" that could be (re)used in other apps, including
server-side with no GWT involved, or GWT with no Java involved on the
server-side.
> Since the remote service interface is under client, it is a good place for
> data objects as well. Adding them to the shared directory may not buy us
> anything. However I cannot see any downside either.
> In a Swing-EJB application some folks consider data objects to be a part of
> business layer or part of server side, others package as a "common" layer
> and hence package as a third one; neither client nor server. I see this as a
> matter of personal preference. I keep my data objects under client.
Yep: no downside, personal preference only (and enterprise/team coding
guidelines).
--
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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment