On Thu, Nov 20, 2008 at 11:03 AM, John LaBanca <[EMAIL PROTECTED]> wrote:
> That's a good idea. In general, we don't separate client code into a
> shared directory because users can decide what they want to send over RPC.
> For example, a user may not send the Request object, she may take out the
> data and send just portions to the server. None the less, it might be a
> good idea for us to separate these classes in general if we think they are
> likely to be used with RPC. Obviously Request and SerializableResponse fall
> into this category because we made them Serializable.
Personally I think code that uses neither JSNI or reflection should be in a
shared directory (though perhaps some things would still go in client or
server if they only made sense there). I would like to see more rigorous
separation of code so that shared code can only see other shared code and
referencing server/client code there would be a compile-time error. I set
my home app up that way and I found it makes things much easier. For
example, I was originally lazy and had a model as an inner class of a
widget, and that model was used in server code. When debugID support was
added, suddenly my server broke because accessing that model class wound up
doing clinit on the widget, which wound up calling GWT.create.
Here is the model I have been using:
server - code that needs any server-only resource, such as servlets or
reflection
shared - code that does not contain or reference any class that contains
JSNI,
GWT.create, or reflection
client - code that needs JSNI, GWT.create, or is only useful in the client
rebind - generators and other code that needs access to TypeOracle
linker - linkers
When compiling the server-side code, it can only see server and shared.
Client side code can see client and shared.
--
John A. Tamplin
Software Engineer (GWT), Google
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
