Passing Complex Objects

[Phaedrus]

This code is really useful to me, i got calls and callbacks working in
under a day with no headaches, and this makes me happy.

Comments:
I enjoy the ability to set Applet Params by @interface

Issues:
For some reason my applet won't load unless there is no "codebase"
specified whatsoever, so i ended up having to comment out the html +=
codebase stuff. Any way I can do that in a supported way?

Wishes:
This is my main question... I see that I can pass Strings and
integers and other simple primatives, however, I wonder if there is a
way that I can create my own class to pass back and forth - is this
possible at all? I understand that perhaps the LiveConnect
infrastructure would have to support this, and maybe it doesn't and
that's the problem, however I'm wondering if you've already addressed
this and I'm just not seeing it.

Specifically, I would like to create my own simple class with 1 String
and 3 booleans (for example) - seems simple enough? And pass that
object between Java and JavaScript, as opposed to the basic parameter
approach.

Thanks in advance for your comments and answers.

Phaedrus

[Jason Greenberg]

I noticed that the existing callback code uses Base64 Encoding.

I wonder if it would be possible to adapt it slightly to use Base64 Encoding of a byte[] containing a serialized java object.

The only thing i can't figure out is if GWT has any "deserialize" methods.

--
You received this message because you are subscribed to the Google Groups "gwtai" group.
To post to this group, send email to gw...@googlegroups.com.
To unsubscribe from this group, send email to gwtai+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gwtai?hl=en.

[kilkenny]

Hi Phaedrus

I thought about passing objects. I don't think the Java Plug-in has
out of the box support for that. My initial idea was to use the
protocol GWT uses for RPC. But that would mean one would have to
include some GWT libraries into the Applet project in order to
deserialize the incoming objects. That is complicated and I don't
think developers would like it.

So I suggest to use the JSON notation for passing objects between
JavaScript and Java. I'm sorry GwtAI has not yet support for that. So
you have to wait or implement it yourself. If you want to help or even
contribute some code, that would be great...

Regards, Adrian

[kilkenny]

Hi Jason

I don't think this would work. You have to be aware that your GWT
code, even though it is written in Java, will run on a JavaScript
engine in the browser. The Applet on the other hand runs on a JVM. The
byte[] representation of an object is pretty sure not gone look the
same in JavaScript and Java. Please correct me if I am wrong...

Regards, Adrian

> > gwtai+un...@googlegroups.com <gwtai%2Bunsu...@googlegroups.com>.

[Jason Greenberg]

I believe you're correct on this, I wasn't able to visualize how it would work.

To unsubscribe from this group, send email to gwtai+un...@googlegroups.com.

[Phaedrus]

I agree that the direct call / JSObject method is what is needed for simplicity & speed in this case.  I too considered local RPC, but i think it's overkill for something that can be more directly connected.

I have a feeling I'm going to end up writing the JSON String approach, so I'll keep you updated and for sure I'll be happy to clean up & contribute what I come up with.

Regarding my one question about having an option for a blank codebase (not specified at all), am I missing something or is it actually impossible at the moment?   Currently it seems like if codebase is not specified, it uses the object path, which i don't think will work for everyone.

Thanks,

~Phaedrus

[Phaedrus]

There are a few ways to do it

1) write toString() and parse()  methods yourself to pass objects via the String callback (GWT built in JSONObject classes can be used to help)

2) Use a library.  http://code.google.com/p/google-gson/ seems to be complete and automatic.

Writing this functionality into gwtai seems to be beyond the project's scope.

A nice overview is presented here:

http://stackoverflow.com/questions/683123/json-java-serialization-that-works-with-gwt

The discussion mentions a few other libraries that keep things clean with interfaces and annotations, but in the end the serialization is manual (with helpers).

HTH

[Michael.Krog]

Related to this I am looking into integrating better object handling
in gwtai and had a discussion
with Adrian about it.

We would like to hear what you guys had to say, though.

The fact:
We know that the arguments will be converted to string when calling a
method on the applet.
We have some control over the return value because the autogenerated
Javascript code
works like a Proxy between the applet and the Gwt code. But we have no
matching
proxy on the other side of the only-string-argument loophole that we
have.

My proposal:
1:
We define a json-based protocol for the only-string-argument loophole.
Basicly json-data with data and info about how to read the data.

2:
We create a proxy on the applet side - An applet the wraps the real
applet and calls the methods on it when requested. This proxy only
takes string arguments, but the jsondata in the string tells what
method to call and with which parameters.

What do you think?

- Michael

On 16 Dec. 2010, 06:46, Phaedrus <routerde...@gmail.com> wrote:
> There are a few ways to do it
> 1) write toString() and parse()  methods yourself to pass objects via the
> String callback (GWT built in JSONObject classes can be used to help)

> 2) Use a library.  http://code.google.com/p/google-gson/seems to be

> complete and automatic.
>
> Writing this functionality into gwtai seems to be beyond the project's
> scope.
>

> A nice overview is presented here:http://stackoverflow.com/questions/683123/json-java-serialization-tha...
>
> <http://stackoverflow.com/questions/683123/json-java-serialization-tha...>The

> discussion mentions a few other libraries that keep things clean with
> interfaces and annotations, but in the end the serialization is manual (with
> helpers).
>
> HTH
>
>
>
>
>
>
>
> On Wed, Dec 15, 2010 at 10:50 PM, Phaedrus <routerde...@gmail.com> wrote:
> > I agree that the direct call / JSObject method is what is needed for
> > simplicity & speed in this case.  I too considered local RPC, but i think
> > it's overkill for something that can be more directly connected.
>
> > I have a feeling I'm going to end up writing the JSON String approach, so
> > I'll keep you updated and for sure I'll be happy to clean up & contribute
> > what I come up with.
>
> > Regarding my one question about having an option for a blank codebase (not
> > specified at all), am I missing something or is it actually impossible at
> > the moment?   Currently it seems like if codebase is not specified, it uses
> > the object path, which i don't think will work for everyone.
>
> > Thanks,
>
> > ~Phaedrus
>

> >> gwtai+un...@googlegroups.com <gwtai%2Bunsu...@googlegroups.com>
> >> .

[Michael.Krog]

Note:
Branch 0.4 has support for GWT-RPC communication between GWT and
Applet now.

- Michael

> > 2) Use a library.  http://code.google.com/p/google-gson/seemsto be

[Phaedrus]

Great news Michael, thanks

To unsubscribe from this group, send email to gwtai+un...@googlegroups.com.

[Michael.Krog]

No problem..

A correction: Its in branch 0.4.1 (0.4 was corrupted - removed now)

The RPC introduces a few changes in how to use an applet:
1) Like normal RPC an Async interface is needed which is the one to
use in GWT.
2) The async interface can be cast to AppletDefTarget(just like
ServiceDefTarget for RemoteService). This
is needed to create an Applet widget.

The demos has been updated and shows how to use it.

NB: It needs testing :)

[Michael.Krog]

...and to simplify things..

In branch 0.4.1 calling methods on an applet is just like calling
methods
on a server via GWT-RPC.

- Define an interface for the service/applet that extends
Applet(instead of RemoteService). In normal services you would have a
@RemoteRelativeUrl annotation, but for Applets you have annotations
like @ImplentingClass, @Height etc.

- Create an Applet that implements the interface.

- Create an new interface that has the original interface name
suffixed with 'Async'(fx MyApplet, MyAppletAsync). Like normal RPC
this Async class must have all methods from the original interface
except in an async form.

This leaves you with 3 classes for each applet. Example:
- MyApplet (interface)
- MyAppletImpl (applet)
- MyAppletAsync (async form of interface)

-Michael