Hey Ravi, Thanks for the detailed input. I should have updated this for everyone's benefit and I'll try to get into that habit. Much like you mentioned, I found that XmlBeans would not be a viable approach with the GWT/RPC mechanism. Although, without thinking deeper about the datatypes, I attributed it to the fact that the source that's generated extends from XmlObject and others, which I'm sure are contained in jars of their own and ultimately identifying and downloading the source for each of these items would probably be a really bad idea :). Thus, I'm doing exactly what you're doing at the moment i.e creating Transfer Objects to contain the bean data.
As for the Serializable issue, you could be right but isn't it also that GWT is trying to deprecate isSerializable so, ideally they do want to be able to support as much of the Standard java serializable classes if not all? So, not sure if we should or should not be using the interface. I guess that's a personal decision though. Since you're doing somewhat similar stuff, a question for you now. Have you had any experience in trying to integrate GWT into any framework? I ask because I currently have a Struts framework for the application that's being enhanced by adding this GWT module. And "ideally" I'd like not to move too far from the Struts framework so any incoming requests should be rerouted from the custom RemoteServiceServlet to be then defined at the struts-config so that the Action-Delegate-DAO structural integrity is maintained. i.e Browser <---> GWT (Client) <---> GWT (Server - RPC) <----> SomeAction Thanks for any info. Suri On Oct 25, 12:05 pm, Ravi M <[EMAIL PROTECTED]> wrote: > Suri > > I strongly suspect (but cannot confirm!) that you won't be able to use > XML Beans classes directly in your RPC. As Ian mentioned in one of his > posts, classes such as BigDecimal, BigInteger etc. are not GWT > serializable out of the box. The generated Java type for XML schema > "integer" and "decimal" members are respectively BigInteger and > BigDecimal. Further, XML schema "dateTime" and "time" are > java.util.Calendar and "duration" is an XML Beans specific type called > org.apache.xmlbeans.GDuration which is also probably not GWT > serializable. Apart from all this there is the fact that the code > artifacts generated by XML Beans form a pretty hairy bunch of > interfaces, implementations and inner classes, and I am not sure GWT > will be able to serialize them easily. > > Am working on an app which uses XML Beans generated data model objects > on the server, and had to unfortunately create "bean like" data > transfer objects for RPC, not to mention ugly code to convert from one > to the other. In hindsight, XML Beans was probably a bad decision, and > am considering using something like JibX which might work better in > terms of performance, GWT serializability etc. > > That being said, if you _do_ get XML Beans GWT serialization to work I > will be very very interested :-) > > A final tangential but related point that has already made an > appearance in this thread: It _may_ be better to continue marking GWT > serializable objects with IsSerializable rather than Serializable, > just to be very clear that the serializability in question is GWT > serializability. There's a slight danger that if Serializable becomes > the marker interface of choice widely, people might start assuming > that all java.io.Serializable objects are GWT serializable. > > Ravi > > Apart from this, XML Beans generated code for XML schema "d > > On Oct 17, 6:44 am, Suri <[EMAIL PROTECTED]> wrote: > > > Hey Ian, > > Thanks again. > > > 1) XmlBeans are an apache open source technology whereby we can define > > the bean in an XML format (called a xml schema) and have the class > > files be generated at compile time. Thus we can go ahead and use them > > like regular beans without having the hassle of having to painfully > > create mundane code for beans each time. And that the code is > > automatically generated for them makes maintaining them (deleting/ > > adding/modifying properties) easy. > > > Anyway, back to the issue. I see the xml beans jar as one viable > > option. Since you said that the source is what is required, i presume > > I don't need to worry about the compiled class files, so what i can do > > then is possibly, create the xmlbeans.gwt.xml and add the xml beans > > source folder to the classpath of the GWT compiler instead of > > bothering to create and copy a jar right? > > > I'll try it and let you know how it goes. Thanks > > > Suri > > > On Oct 16, 5:07 pm, "Ian Petersen" <[EMAIL PROTECTED]> wrote: > > > > On Thu, Oct 16, 2008 at 3:00 PM, Suri <[EMAIL PROTECTED]> wrote: > > > > In my current application to which I'm trying to > > > > integrate GWT, we use XmlBeans for passing data along. I do believe > > > > xml beans are serializable. So, then > > > > 1) Can i use these beans just as well to communicate via the GWT-RPC > > > > to my client now? > > > > I don't know what XmlBeans are, so I can't answer definitively, but, > > > if the classes are serializable, and the source is available and > > > translatable, the answer should be "yes". > > > > > 2) If yes, then what would I require for this to be successfully > > > > compiled and translated into javascript for the client code. What I do > > > > is first generate the xml beans and jar them up (the class files) to > > > > use within the current application. Additionally, the source code for > > > > these xml beans is also generated just for any reference sake but is > > > > not part of the jar. Do i need both the source as well as the class > > > > files in order to be able to implement the beans in the GWT-RPC or > > > > would referencing the classpath to the src code for the beans be > > > > sufficient? > > > > Any code that's going to run on the client has to be available to the > > > GWT compiler in source form at compile time. In your case, it sounds > > > like you may want to create a separate GWT-specific JAR of your > > > XmlBeans code. (Note that I'm making some assumptions about XmlBeans > > > because I don't know what they are--you may have to enlighten me to > > > get more specific advice.) > > > > Suppose your existing XmlBeans JAR looks like this: > > > > /META-INF > > > MANIFEST > > > /com > > > /example > > > /xmlbeans > > > ...class files here > > > > you probably want to modify it to look like this for inclusion by > > > reference in a GWT project: > > > > /META-INF > > > MANIFEST > > > /com > > > /example > > > XmlBeans.gwt.xml > > > /xmlbeans > > > ...class _and_ java files here > > > > The XmlBeans.gwt.xml file should then look roughly like this: > > > > <module> > > > <!-- give the relative directory name(s) that contain the > > > translatable source here --> > > > <!-- use more than one <source> tag if there's more than one directory > > > --> > > > <source path="xmlbeans" /> > > > </module> > > > > Then, put the JAR on the compiler's classpath (and hosted mode's > > > classpath) and, in your main module, add this: > > > > <!-- name the XmlBeans.gwt.xml file here, but translate / to . and > > > don't include the .gwt.xml --> > > > <inherits name="com.example.XmlBeans" /> > > > > You should be good to go. Of course, this all assumes that your > > > XmlBeans code is translatable and that any non-translatable bits are > > > isolated from the translatable bits. If something about your setup > > > doesn't meet my assumptions, you'll probably have to ask here, but try > > > searching the forum history, too--there have been a few people asking > > > about how to include external libraries and that's basically what > > > you're doing. > > > > Ian --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
