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.

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.

On Sat, May 22, 2010 at 3:14 PM, Michael <mrher...@gmail.com> wrote:

> Hi,
>
> I have a number of class decelerations, most are passed between client
> and server via RPC AND used in the data store (Objectify).  Some just
> get used in on but not the other.  The stock watcher demo for RPC puts
> the class that is passed back and fourth in the .client path, but
> wouldn't it be better in the .shared path since both the client and
> the server uses it?  Is there a downside to doing it this way?
>
> Michael
>
> --
> 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-tool...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-web-toolkit+unsubscr...@googlegroups.com<google-web-toolkit%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=en.
>
>

-- 
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-tool...@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