Effect of using implementations rather than interfaces in client data model
Hi all
I have a couple of somewhat basic, related and possibly duh! type
questions (which the subject of this post doesn't articulate very
well!) that I can't seem to find answers to on the forum etc. Couple
of points before the actual questions.
1. This is using GWT 1.4.6x, if that makes a difference.
2. Am not talking about RPC/serializable classes, but about data
objects that are used purely on the client side.
1. When designing the client side data model, does it make a
difference in terms of performance/optimization whether one uses
concrete implementations rather than interfaces (especially for things
in the collections framework)? More specifically, suppose I have a
data model class defined like so:
public class DataModel {
private String aString;
private List aList = new ArrayList();
private Map aMap = new HashMap();
// Methods that provide access to the data
}
Is there any advantage in terms of ease of compilation/client
performance/size of compiled Javascript if the above is declared like
so, instead:
public class DataModel {
private String aString;
private ArrayList aList = new ArrayList();
private HashMap aMap = new HashMap();
// Methods that provide access to the data
}
2. Does using the @gwt.typeArgs annotation in any way affect the
behaviour/performance of pure client side data objects? For example,
would doing like so:
public class DataModel {
private String aString;
/**
* @gwt.typeArgs com.foo.client.model.Bar
*/
private ArrayList aList = new ArrayList();
/**
* @gwt.typeArgs java.lang.String, com.foo.client.model.Bar
*/
private HashMap aMap = new HashMap();
// Methods that provide access to the data
}
help in any way? AFAIK, the @gwt.typeArgs annotation has to do _only_
with RPC for GWT serializable objects and remote interfaces.
Thanks and regards
Ravi
--~--~-~--~~~---~--~~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Exception handling in GWT Service
Jossey
Quite the contrary, actually. I started off with a custom exception
which was merely a child class of Exception that I intended to use in
RPC calls (i.e. service methods throw it). This actually didn't work
in the ways expected, i.e. when the server threw the exception I was
unable to retrieve the exception message in the client, or find out
what the cause was. Which is when some digging around revealed that if
you want to send the exception over the wire, it has to be a GWT
SerializableException.
This is with 1.4.6x, of course this may have changed in 1.5.x, I am
not sure.
Ravi
On Nov 26, 5:58 pm, jossey [EMAIL PROTECTED] wrote:
Hi,
Why are we extending SerializableException?
Is that because the starting example had it so?
I think it kinds of gives out a wrong message. ...
just extends Exception should do.
not very relevant to the discussion anyways...
Jossey.
On Nov 25, 3:33 pm, Ravi M [EMAIL PROTECTED] wrote:
Ah me. Step 1 should read:
1. Declare your RPC exception like so:
public class MyRPCException extends SerializableException {
public MyRPCException() {
super();
}
public MyRPCException(String message) {
super(message);
}
//... other stuff?
}
On Nov 26, 1:32 am, Ravi M [EMAIL PROTECTED] wrote:
Satya,
The following should work.
1. Declare your RPC exception like so:
public class MyRPCException extends SerializableException {
public TrackerRPCException() {
super();
}
public MyRPCException(String message) {
super(message);
}
//... other stuff?
}
2. Declare your service method like so:
public SomeReturnedObject myServiceMethod(...arguments...) throws
MyRPCException;
3. Declare your async service method like so:
public void myServiceMethod(...arguments..., AsyncCallback callback);
4. The server side implementation of your service method may be like
so:
public SomeReturnedObject myServiceMethod(...arguments...) throws
MyRPCException {
SomeReturnedObject ret = null;
try {
// Do stuff to populate ret. This stuff could
potentially fail.
} catch (SomeNonGWTSerializableServerSideException e) {
throw new MyRPCException(This is an error message that
may be appropriate to show in the UI: + e.getMessage());
}
return ret;
}
5. In your AsyncCallback in the client:
public void onSuccess(Object result) {
SomeReturnedObject foo = (SomeReturnedObject) result;
// Happiness and tranquility reign supreme
};
public void onFailure(Throwable exception) {
try {
throw exception;
} catch (MyRPCException e) {
// Show the error message to the user,
// or handle however you want to.
}
};
This should work, there may be some overkill in this though. All this
is GWT 1.4.6x, I'm not sure if any of this has changed in 1.5.x.
Hope this helps
Ravi
On Nov 26, 1:08 am, satya [EMAIL PROTECTED] wrote:
Thank you very much,
I guess i can return the String IllegalDateRangeException when
throwing that exception from my Service and check for that in my
onFailure class.
public void onFailure( Throwable caught )
{
if ( caught.getMessage().contains
( IllegalDateRangeException ) )
//handle my class.
}
Thnak you,
Satya
On Nov 25, 1:38 pm, olivier nouguier [EMAIL PROTECTED]
wrote:
On Tue, Nov 25, 2008 at 8:14 PM, satya [EMAIL PROTECTED] wrote:
Also
when i call the actual method, does the exception get caught in the
failure method or in my catch method?
For example:
AsyncCallback callBack = new AsyncCallback() {
public void onFailure( Throwable caught )
{
//Is the exception caught here?
here !
}
public void onSuccess( Object result )
{
}
try
{
createNewRuleService.createRule( screenType,
eventRuleForm, callBack );
}
catch ( IllegalDateRangeException e )
{
or the exception is caught here?
}
You should notice the differences between RemoteInterface and its
Asyn counter part:
* return type: the asyn interface method doesn't have return value
=== it will be pass as parameter asynchronously in onSuccess
callback
Re: Exception handling in GWT Service
Satya,
The following should work.
1. Declare your RPC exception like so:
public class MyRPCException extends SerializableException {
public TrackerRPCException() {
super();
}
public MyRPCException(String message) {
super(message);
}
//... other stuff?
}
2. Declare your service method like so:
public SomeReturnedObject myServiceMethod(...arguments...) throws
MyRPCException;
3. Declare your async service method like so:
public void myServiceMethod(...arguments..., AsyncCallback callback);
4. The server side implementation of your service method may be like
so:
public SomeReturnedObject myServiceMethod(...arguments...) throws
MyRPCException {
SomeReturnedObject ret = null;
try {
// Do stuff to populate ret. This stuff could
potentially fail.
} catch (SomeNonGWTSerializableServerSideException e) {
throw new MyRPCException(This is an error message that
may be appropriate to show in the UI: + e.getMessage());
}
return ret;
}
5. In your AsyncCallback in the client:
public void onSuccess(Object result) {
SomeReturnedObject foo = (SomeReturnedObject) result;
// Happiness and tranquility reign supreme
};
public void onFailure(Throwable exception) {
try {
throw exception;
} catch (MyRPCException e) {
// Show the error message to the user,
// or handle however you want to.
}
};
This should work, there may be some overkill in this though. All this
is GWT 1.4.6x, I'm not sure if any of this has changed in 1.5.x.
Hope this helps
Ravi
On Nov 26, 1:08 am, satya [EMAIL PROTECTED] wrote:
Thank you very much,
I guess i can return the String IllegalDateRangeException when
throwing that exception from my Service and check for that in my
onFailure class.
public void onFailure( Throwable caught )
{
if ( caught.getMessage().contains
( IllegalDateRangeException ) )
//handle my class.
}
Thnak you,
Satya
On Nov 25, 1:38 pm, olivier nouguier [EMAIL PROTECTED]
wrote:
On Tue, Nov 25, 2008 at 8:14 PM, satya [EMAIL PROTECTED] wrote:
Also
when i call the actual method, does the exception get caught in the
failure method or in my catch method?
For example:
AsyncCallback callBack = new AsyncCallback() {
public void onFailure( Throwable caught )
{
//Is the exception caught here?
here !
}
public void onSuccess( Object result )
{
}
try
{
createNewRuleService.createRule( screenType,
eventRuleForm, callBack );
}
catch ( IllegalDateRangeException e )
{
or the exception is caught here?
}
You should notice the differences between RemoteInterface and its
Asyn counter part:
* return type: the asyn interface method doesn't have return value
=== it will be pass as parameter asynchronously in onSuccess
callback.
* exception: are not part of the async method === it will be pass
as parameter asynchronously in onFailure callback.
Thank you very much for your help. I appreciate it.
Satya
On Nov 25, 1:10 pm, satya [EMAIL PROTECTED] wrote:
How do i specify in the service signature that this is GWT
serializable?
my method signature looks like:
public String create(Rule rule) throws IllegalDateRangeException;
On Nov 23, 5:23 am, olivier nouguier [EMAIL PROTECTED]
wrote:
On Sun, Nov 23, 2008 at 6:58 AM, satya [EMAIL PROTECTED] wrote:
Hi,
Can i pass exceptions between client and server.
Can i have an RPC serice with method that throw an user defined
exception and handle that exception in the client side?
Yes as long as your exeption is declared in the Service Signature (to
be declared as GWT serialisable).
I created an userdefined exception:
--
public class IllegalDateRangeException extends SerializationException
implements IsSerializable
{
private String errorMessage = null;
public IllegalDateRangeException ( String error )
{
errorMessage = error;
}
public String toString()
{
return Exception occurred: + errorMessage;
}
public String getErrorMessage()
{
return errorMessage;
}
public void setErrorMessage( String errorMessage )
{
this.errorMessage = errorMessage;
}
}
and my RPC
Re: Exception handling in GWT Service
Ah me. Step 1 should read:
1. Declare your RPC exception like so:
public class MyRPCException extends SerializableException {
public MyRPCException() {
super();
}
public MyRPCException(String message) {
super(message);
}
//... other stuff?
}
On Nov 26, 1:32 am, Ravi M [EMAIL PROTECTED] wrote:
Satya,
The following should work.
1. Declare your RPC exception like so:
public class MyRPCException extends SerializableException {
public TrackerRPCException() {
super();
}
public MyRPCException(String message) {
super(message);
}
//... other stuff?
}
2. Declare your service method like so:
public SomeReturnedObject myServiceMethod(...arguments...) throws
MyRPCException;
3. Declare your async service method like so:
public void myServiceMethod(...arguments..., AsyncCallback callback);
4. The server side implementation of your service method may be like
so:
public SomeReturnedObject myServiceMethod(...arguments...) throws
MyRPCException {
SomeReturnedObject ret = null;
try {
// Do stuff to populate ret. This stuff could
potentially fail.
} catch (SomeNonGWTSerializableServerSideException e) {
throw new MyRPCException(This is an error message that
may be appropriate to show in the UI: + e.getMessage());
}
return ret;
}
5. In your AsyncCallback in the client:
public void onSuccess(Object result) {
SomeReturnedObject foo = (SomeReturnedObject) result;
// Happiness and tranquility reign supreme
};
public void onFailure(Throwable exception) {
try {
throw exception;
} catch (MyRPCException e) {
// Show the error message to the user,
// or handle however you want to.
}
};
This should work, there may be some overkill in this though. All this
is GWT 1.4.6x, I'm not sure if any of this has changed in 1.5.x.
Hope this helps
Ravi
On Nov 26, 1:08 am, satya [EMAIL PROTECTED] wrote:
Thank you very much,
I guess i can return the String IllegalDateRangeException when
throwing that exception from my Service and check for that in my
onFailure class.
public void onFailure( Throwable caught )
{
if ( caught.getMessage().contains
( IllegalDateRangeException ) )
//handle my class.
}
Thnak you,
Satya
On Nov 25, 1:38 pm, olivier nouguier [EMAIL PROTECTED]
wrote:
On Tue, Nov 25, 2008 at 8:14 PM, satya [EMAIL PROTECTED] wrote:
Also
when i call the actual method, does the exception get caught in the
failure method or in my catch method?
For example:
AsyncCallback callBack = new AsyncCallback() {
public void onFailure( Throwable caught )
{
//Is the exception caught here?
here !
}
public void onSuccess( Object result )
{
}
try
{
createNewRuleService.createRule( screenType,
eventRuleForm, callBack );
}
catch ( IllegalDateRangeException e )
{
or the exception is caught here?
}
You should notice the differences between RemoteInterface and its
Asyn counter part:
* return type: the asyn interface method doesn't have return value
=== it will be pass as parameter asynchronously in onSuccess
callback.
* exception: are not part of the async method === it will be pass
as parameter asynchronously in onFailure callback.
Thank you very much for your help. I appreciate it.
Satya
On Nov 25, 1:10 pm, satya [EMAIL PROTECTED] wrote:
How do i specify in the service signature that this is GWT
serializable?
my method signature looks like:
public String create(Rule rule) throws IllegalDateRangeException;
On Nov 23, 5:23 am, olivier nouguier [EMAIL PROTECTED]
wrote:
On Sun, Nov 23, 2008 at 6:58 AM, satya [EMAIL PROTECTED] wrote:
Hi,
Can i pass exceptions between client and server.
Can i have an RPC serice with method that throw an user defined
exception and handle that exception in the client side?
Yes as long as your exeption is declared in the Service Signature (to
be declared as GWT serialisable).
I created an userdefined exception:
--
public class IllegalDateRangeException extends
SerializationException
implements IsSerializable
{
private String errorMessage = null
Re: Client Side Checked Exceptions
Stephen
I _think_ Lothar's point is that MyException needs to extend
com.google.gwt.user.client.rpc.SerializableException not just
implement IsSerializable for exceptions across RPC to work properly. I
had this problem a few weeks back where exceptions thrown across RPC
were merely IsSerializable and couldn't be caught with the correct
type in onFailure().
Anyway, looks like you fixed your problem regardless, so I will cease
and desist.
Regards,
Ravi
On Oct 21, 9:13 pm, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Sorry lothar. to answere your first question, it isnt being caught at
all, and MyException extends isSerialisable however as i mentioned i
was mistaken, instanceof works perfectly.
Thank you for taking the time to help develop gwt and for helping me
out :)
On Oct 21, 1:28 pm, Lothar Kimmeringer [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] schrieb:
Sorry for reposting but to me this is a critical issue that should be
looked into asp. Has anyone else had this problem or can someone else
reproduce it?
You haven't answered my question, so I didn't see a reason to look
into that further (nobody is paying me for doing that anyway, so
it's voluntary work anyway).
What is
try{
String test = null;
test.toString();}
catch(NullPointerException npe){
Window.alert(Boolean.toString(npe instanceof NullPointerException));}
returning?
iv also found recently that if i throw an exception MyException from
the server to the client and do the following in the onFailure method
the expression evaluates to false.
if (caught instanceof MyException) {
Window.alert(true);
} else {
Window.alert(false);
}
To repeat my question: Is MyException derived from SerializableException?
Regards, Lothar
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: RPC + Serializable objects
Suri, No, I don't have any experience with GWT + Struts or indeed Struts itself. I'm fairly new to the whole web application development domain itself, sorry I can't help out more. Although if you search the group archives and the web you'll probably find lots of information on GWT + Struts, maybe even what you're looking for. Regards Ravi On Oct 27, 1:27 am, Suri [EMAIL PROTECTED] wrote: 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
Re: RPC + Serializable objects
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
