That doesn't fully address the entire question, though. Aside from the potential gotchas about using java.io.Serializable, the source files are still in a separate project, which is easy to imagine in a larger modular project. I've heard of people including the source when bundling their jars, but I wasn't able to get GWT to find the source there myself.
My imperfect solution to the problem was to write a code generator that uses reflection on specified classes to generate both IsSerializable DTOs and utility classes for convering between the two. It turned out to be a bigger project than I wanted it to be, even for the limited cases I had, and it needs a complete rewrite. However, I'd be happy to share the ideas and what code I have if anyone else is interested in contributing. I think this is a significant inconvenience for GWT and would like to find a good long-term solution for it. -Brian On Feb 1, 10:22 am, Paul Robinson <ukcue...@gmail.com> wrote: > You don't *have* to use IsSerializable. Serializable is also supported. > Seehttp://code.google.com/webtoolkit/doc/latest/DevGuideServerCommunicat... > > and > > http://code.google.com/webtoolkit/doc/latest/FAQ_Server.html#Does_the... > > Paul > > > > BM wrote: > > Hi, folks. > > I have a little question that I haven't figured out myself (mea > > culpa). Since GWT requires IsSerializable, how better I can avoid > > hassle with duplicating redundant Java Beans? The way it works for me > > now: one JavaBean is for database, another is for GWT, but both of > > them are identical (GWT's one IsSerializable that's the only a > > difference so far). > > > I will explain you how I am doing now (not sure it is best way, but it > > works so far). For example, suppose I have a completely separated > > library, called "Database Operations". It looks like this: > > > DatabaseOperations op = new DatabaseOperations(jndiStringOfJDBC); > > List<HelloBean> hellos = op.getABunchOfHellos(); > > > Now, the code above will return me a list of HelloBean that has a > > method .getHelloWorldText() for example. So far, so good. Now, in > > order to display these beans from the GWT callback in the javascript > > client, I need make sure HelloBean implements IsSerializable and its > > source is in GWT tree, otherwise GWT Compiler will complain and fail. > > Booooo!, but that's _another_ project with _another_ namespace etc > > etc. So what I do is simply create a stupid clone of HelloBean for GWT > > that implements IsSerializable and then import HelloBean-not- > > serializable to HelloBean-that-is-serializable. I don't like this way, > > because if I changed something in the service, I have to change a lot > > of stuff elsewhere etc. It is also redundant beans... OTOH, I can not > > find how to avoid this either... :-( > > > So the question is: how I can get rid of these redundant beans, having > > my HelloBean made once and forever made or where to RTFM about this, > > since I can not find any doc regarding this? > > > Please note, I don't use ORM due to my own point of view that ORM > > (Hibernate, Top-Link etc) is just a plain wrong idea for actually > > amplify your hassle, rather then solve it. So I have no problem to > > twist my JavaBeans in any direction, basically. I am fine storing in a > > Database any POJO that implements anything (Serializable, > > IsSerializable or nothing at all). > > > P.S. I am using NetBeans for the development, if this would help. > > Probably not. > > > -- > > BM -- 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.
