What's the best development environment for Wave Gadgets?
Jonas Huckestein
so I just started developing Wave Gadgets and I'm currently using GWT.
While there are obvious benefits such as unit testability, cross-
browser support and code-splitting, there are also some downsides. For
instance I cannot easily test gadgets locally (not to mention testing
robots!). I had to create a local mock implementation of the wave API
for testing and every time I use a new API feature I have to add it to
my mock implementation. All in all it feels kind of clunky and
strange.
Are there any easier ways to develop (possibly very complex) wave
gadgets? What do you guys use?
In case you are interested, I wrote a tutorial in how to get started
developing gadgets with gwt. Also, I guess I will be uploading my
WaveMock framework to Google Cloud this week (if anybody is
interested):
http://thezukunft.com/2010/02/08/a-wave-gadget-robot-using-gwt-2-0-and-google-app-engine-part-1/
Cheers, Jonas
kayode odeyemi
--
You received this message because you are subscribed to the Google Groups "Google Wave API" group.
To post to this group, send email to google-...@googlegroups.com.
To unsubscribe from this group, send email to google-wave-a...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-wave-api?hl=en.
--
Odeyemi 'Kayode O.
Application Developer & Systems Engineer (Sun Certified Professional),
Drupal Developer
Tel: +2348053063373
P.O.Box 682, Ita-elewa, Ikorodu,
Lagos, Nigeria, West-Africa.
Website: http://www.sinati.com
Socialize with me: http://profile.to/charyorde, http://twitter.com/charyorde
Benjamin Nortier
I would be interested in that mock framework of yours. I was
considering doing the same because it is difficult to test gadgets in
the sandbox or preview. I would be able to contribute as well if I
have the need of extended functionality...
Cheers
Benjamin
--
Benjamin Nortier
e: bjno...@gmail.com
c: +44 (0)778 946 1959
gtalk: bjno...@gmail.com
kayode odeyemi
HaiColon
locally (or as a website on a remote server) and then I add a layer on
top that makes it work with Google Wave. That way I can test 90% of
the gadget locally, no problem. And for the other 10% I just use the
debug features of the sandbox Wave client. That has worked good so far
even for bigger/more involved gadgets and the bonus is that your
gadget then doesn't need to be Wave exclusive.
If you'd want to use a test-driven development approach you could only
test this 90% non-Wave part of the application but none of the Google
Wave specific stuff in the other 10%, so this approach may not be good
enough for everyone.
Cheers,
Chris
> http://thezukunft.com/2010/02/08/a-wave-gadget-robot-using-gwt-2-0-an...
>
> Cheers, Jonas
Jonas Huckestein
I have just released WaveConnector - a turnkey solution for developing
wave gadgets using GWT and testing them in hosted mode. Please head
over to my blog at http://thezukunft.com or the project page at
http://code.google.com/p/waveconnector-gwt/ for details. It's as easy
as downloading a zip archive :D
Chris, how di you achieve the 90%? I assume you must also decouple the
GWT code from the Gadget/Wave API? I have simply implemented a mock
version of the wave API. That way I think I can do all testing
locally.
Kayode, WaveConnector is exactly the mock framework (+ some
convenience functions) I was talking about :)
Sorry for this shameless selfpromotion on this board but I think this
might actually help a lot of people or get them to develop for Wave in
the first place.
What do all of you think of a dedicated Wave+GWT group? I asked that
question on the GWT groups earlier and people seemed to be interested.
Cheers, Jonas
This is my first ever open source contribution so please give me
comments and feedback on my blog or the project page.
dougx
a gadget?
All you need is a frame:
<?xml version="1.0" encoding="UTF-8" ?>
<Module>
<ModulePrefs title="State Example" height="220">
<Require feature="wave" />
</ModulePrefs>
<Content type="html">
<![CDATA[
<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<script type="text/javascript" src="http://xxx.appspot.com/xxx/
xxx.nocache.js"></script>
<link type="text/css" rel="stylesheet" href="http:/xxx.appspot.com/
xxx/xxx.css">
<title>Jewels</title>
</head>
<body>
</body>
</html>
]]>
</Content>
</Module>
Then use the cross domain compiler to compile the code (this is
actually exactly what it's for...):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit 1.7.0//
EN" "http://google-web-toolkit.googlecode.com/svn/tags/1.7.0/distro-
source/core/src/gwt-module.dtd">
<module rename-to='xxx'>
<inherits name='com.google.gwt.user.User'/>
<inherits name='com.google.gwt.user.theme.standard.Standard'/>
<entry-point class='com.hax.wave.xxx.client.XXXWidget'/>
<add-linker name="xs"/> <-- You _must_ include this step to access
teh wave API.
</module>
And finally, use JSNI to access the wave api:
public static native boolean isInWaveContainer() throws Exception /*-{
var rtn = false;
if (($wnd.wave) && ($wnd.wave.isInWaveContainer()))
rtn = true;
return(rtn);
}-*/;
...
So yeah. Might find that helpful. Note that in 2.0 you can't debug
using the xs linker, so you'll need to comment that line out while
you're developing your widget, and then put it back when you do a
deployment build.
That wave connector is very cool; nice work! :)
Hm... I wonder if we could add an app engine based data store based
state so just when you're debugging locally you can have two browser
windows open and it'll treat those as different viewers of the gadget,
so you can do full testing. That'd involve defining separate servlet
end points though; perhaps it'd be better as a separate gwt
application, and you can include it on your testing pages...
~
Doug.
On Feb 11, 7:42 am, Jonas Huckestein <jonas.huckest...@me.com> wrote:
> Hi Everybody,
>
> I have just released WaveConnector - a turnkey solution for developing
> wave gadgets using GWT and testing them in hosted mode. Please head
> over to my blog athttp://thezukunft.comor the project page athttp://code.google.com/p/waveconnector-gwt/for details. It's as easy
Jonas Huckestein
nice, I didn't think of using a normal GWT application as a wave
gadget like that before. But I think that is just a way of manually
doing what the Gadget API for GWT is doing for you.
What you said about being able to see two different views of the
gadget side by side in local testing is easily accomplished in
WaveConnector (actually it's the primary design goal). We can view two
versions of the Gadget (which is no more than a GWT widget) side by
side in a browser. All we need to do is give them two different
eventBuses (to prevent them from interfering with one another) and
make sure that wave-related events are shared across the buses. (more
generally using singletons in the GWT widget might cause problems).
I don't think there is need to include a server in order to test the
gadget with more than one participant :)
We can also add a user interface to add/remove participants, switch
the wave mode etc.. I will try to get this done next week.
Thanks for your feedback. I'm glad you liked it!
Cheers, Jonas
> > over to my blog athttp://thezukunft.comorthe project page athttp://code.google.com/p/waveconnector-gwt/fordetails. It's as easy
HaiColon
As long as the self-promotion is on topic I don't think it is a
problem, it's very welcome instead.
As for how I achieve the 90%.. You assumed right, I decouple the Wave
code from the other code. How I see it, the difference between a
JavaScript app and a Wave JavaScript app is that without Wave,
everything happens instantly. In Wave, you have to send some data to
Wave and wait for the callback from Wave before you let things happen.
So what I do is I write a function that makes changes instantly. This
is all that the gadget needs to work without Wave. Then I add a
function that sends data to Wave. And finally, in the gadget state
change callback function, the gadget calls the "original" function
which does the actual work.
So I would have a callback function gadgetCallback(), a function
someTask() and a function someTaskWave(). someTaskWave() sends new
data to Wave after a click on a button or something, then
gadgetCallback() is called by Wave and calls the someTask() function
with the received data. If I use the gadget without Wave, I would just
call the someTask() function directly after the button click. Since
the someTaskWave() function and the gadgetCallback() function are
really tiny because they don't have to do much, combined they make up
well under 10% of the whole code and I can test all the rest of the
code locally or add another layer on top to add support for another
Wave-like service.
Having a mock framework is way better of course ^^, although the
decoupling of the Wave code from the other code still has the bonus of
making it easy to use the gadget for other services than Wave, so the
best solution would be to combine both approaches. If you care about
cross service compatibility that is :)
And I have to say that this wasn't some crazy well thought through
design decision on my part, it just happens that I always start to
implement all the Wave stuff at the very end when the app is already
working :)
On Feb 11, 12:42 am, Jonas Huckestein <jonas.huckest...@me.com> wrote:
> Hi Everybody,
>
> I have just released WaveConnector - a turnkey solution for developing
> wave gadgets using GWT and testing them in hosted mode. Please head
> over to my blog athttp://thezukunft.comor the project page athttp://code.google.com/p/waveconnector-gwt/for details. It's as easy
dougx
I've never been a fan of gadgets. It's always seemed rather contrived
to me, to suggest you can have an entire web application all wrapped
up in a single xml file.
All of the open social applications you'll find in the real world make
use of makeRequest() and server side services; the way you would
expect a modern web application to. In fact, I'd argue the huge delay
in adding makeRequest() and the REST api is why Hi5 and Myspace
applications never took off the way Facebook ones did (traffic too, to
be fair).
Still, practically speaking I strongly advise you not to use the
gadget linker. It's old, barely supported (seriously, look at the
change log...), generates very large files (no cute splitting into per-
browser components like the normal linker does), and makes several of
the powerful GWT features available; specifically RPC, code splitting,
debugging and resource bundles.
Still, you know. It's kind of fun for tooling around and making little
bits and pieces with I guess.
Regarding the wave container... I suspect we're re-inventing the
wheel; I wonder if it wouldn't be a better plan to implement an
independent wave client container on top of shindig (http://
shindig.apache.org/) ...
~
Doug.
> > > over to my blog athttp://thezukunft.comortheproject page athttp://code.google.com/p/waveconnector-gwt/fordetails. It's as easy
Jonas Huckestein
features. Is there any reason for that? In that case we could also try
to improve on the linker :)
I didn't know about shindig either, but from the looks of it, we would
have to build a GWT wrapper around it first.
So here's what my final goal and masterplan is:
- I want to develop wave gadgets using ALL of GWTs features
- I want to test in hosted mode with multiple versions of the gadget
running side by side
- I want to be able to simulate mode changes and participant updates
all from one interface
I thought I was pretty close but the gadget linker not working with
some of GWTs power features is a real letdown! So does anybody have
any ideas how to build what I want to build in another way?
I didn't understand your point about why you cannot put a web
application in a gadget container, though. Using JSONP you can develop
any application you want and connect it to a webservice. There is no
reason for this to be slower than anything that doesn't run in a
gadget container. (I don't know what opensocial's makerequest does,
though).
Cheers, Jonas
> > > > over to my blog athttp://thezukunft.comortheprojectpage athttp://code.google.com/p/waveconnector-gwt/fordetails. It's as easy
Kayode Odeyemi
--
You received this message because you are subscribed to the Google Groups "Google Wave API" group.
To post to this group, send email to google-...@googlegroups.com.
To unsubscribe from this group, send email to google-wave-a...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-wave-api?hl=en.
Kayode Odeyemi
dougx
linker, which doesn't let you do some of the cool things that GWT
does.
This is much nicer in my opinion:
<?xml version="1.0" encoding="UTF-8" ?>
<Module>
<ModulePrefs title="State Example" height="220">
<Require feature="wave" />
</ModulePrefs>
<Content type="url" href="http://www/cgi-bin/example/gadgets/
mystats.cgi" /> <- Normal web application end point.
</Module>
(ok, that doesn't actually work because the container doesn't support
cross domain calls, but it's so _elegant_... *sigh~*)
Unrelated, but it looks like wave is actually _built_ out of a
modified shindig version (go spelunking in the gadget sandbox and
you'll see what I mean). It's possible we might just be able to lift
the js straight off the wave servers and use that with a bit of
modification. I'm going to have a shot at that and see if I can get it
working...
...but even if I do, you're right; it won't really help. It'll make it
easier to test, but the mock framework is really the only way I can
think of test in hosted mode.
~
Doug.
> > > > > over to my blog athttp://thezukunft.comortheprojectpageathttp://code.google.com/p/waveconnector-gwt/fordetails. It's as easy
dougx
you're not in a local iframe anymore; your own server is cross domain
now, so you'll have to use an XSS proxy to make RPC calls (or
makeRequest()).
~
D.
On Feb 11, 6:28 pm, Kayode Odeyemi <drey...@gmail.com> wrote:
> Ok. I get it now. Now digging in...
>
>
>
> On Thu, Feb 11, 2010 at 10:10 AM, Kayode Odeyemi <drey...@gmail.com> wrote:
> > I really want to explore the approach you took Doug(i.e the GWT only
> > approach). But my question is how do you include the module file and the
> > JSNI implementation in the Wave gadget
>
> > On Thu, Feb 11, 2010 at 6:37 AM, Jonas Huckestein <jonas.huckest...@me.com
> ...
>
> read more »
Jonas Huckestein
> Yup; just remember that when you're compiling using the xs linker
> you're not in a local iframe anymore; your own server is cross domain
> now, so you'll have to use an XSS proxy to make RPC calls (or
> makeRequest()).
That I don't understand. I can do simple GETs on whatever server I
want. The only thing I can't do is POSTs, PUTs and DELETEs but that is
not needed. You can just use JSONP to call your webservices. (Of
course they have to be set up to accept that).
Also: is gwt-gadgets using the xs linker or how does it work? Because
I am already using a ClientBundles with it and that works pretty
good :)
Cheers, Jonas
> ...
>
> read more »
zundel
The primary purpose of the gwt-gadgets linker is simplify wrapping up
your gadget application into a gadget spec, reduces one layer of
script in loading your gadget, and to wrap the gadgets API. You can
also write a gadget by hand-authoring the gadget spec, providing your
own JSNI bindings to the Gadget API and deploy as a regular GWT app.
A disadvantage to this approach is that your gadget spec will load the
selection script, which will then pull in your specific permutation.
In the gadget generated spec, the selection script is baked in to the
gadget spec.
Just to clear a few things up:
- The gadget linker does support using different permutations.
- As a primary linker, it can affect some features, I'm not sure
which ones. Some of them are implemented as secondary linkers. I've
never tried to use 'runAsync' with it, for example.
- You are right, there have been few updates to the gadget linker
recently. I last made changes for the last gwt-google-apis release
last year sometime.
- It uses the legacy gadget spec and hasn't been updated for the
Open Social gadget spec.
I'm hoping we'll have some more work done on the gadget bindings
soon. In the mean time, if there is something someone wants to
contribute, please feel free to discuss or post a patch on the gwt-
google-apis group.
-Eric.
> > > > > over to my blog athttp://thezukunft.comortheprojectpageathttp://code.google.com/p/waveconnector-gwt/fordetails. It's as easy
dougx
http://gwt-google-apis.googlecode.com/svn/releases/gadgets/1.0/gadgets/src/com/google/gwt/gadgets/linker/
...and yes, you can use JSONP to do cross domain class; it's one of a
variety of XSS techniques; that, a proxy iframe, html5 postMessage,
etc. All I'm saying is that you need to use one of them to make server
requests when you use the cross domain linker.
~
doug.
> ...
>
> read more »
dougx
the gadgets api for anything since it doesn't wrap the wave extension
api.
Certainly there are disadvantages to this approach, for example the
default linker waits until page load is completed before triggering,
which means typically gadgets.util.registerOnLoadHandler() never
returns a callback (I guess it's already fired by the time the GWT
code loads and binds a handler).
Still, like you said; it's open source. I'm sure people are clever
enough to try both methods and choose the one they find works best for
them (and/or modify the source so it does work for them.... :)
~
Doug.
> > > > > > over to my blog athttp://thezukunft.comortheprojectpageathttp://code.google.com/p/wavec.... It's as easy
> > > > > > as downloading a zip archive :D
>
> > > > > > Chris, how di you achieve the 90%? I assume you must also decouple the
> > > > > > GWT code from the Gadget/Wave API? I have simply implemented a mock
> > > > > > version of the wave API. That way I think I can do all testing
> > > > > > locally.
>
> > > > > > Kayode, WaveConnector is exactly the mock framework (+ some
> > > > > > convenience functions) I was talking about :)
>
> > > > > > Sorry for this shameless selfpromotion on this board but I think this
> > > > > > might actually help a lot of people or get them to develop for Wave in
> > > > > > the first place.
>
> > > > > > What do all of you think of a dedicated Wave+GWT group? I asked that
> > > > > > question on the GWT groups earlier and people seemed to be interested.
>
> > > > > > Cheers, Jonas
>
> > > > > > This is my first ever open source contribution so please give me
> > > > > > comments and feedback on my blog or the project page.
>
> > > > > > On Feb 10, 2:07 am, HaiColon <haico...@gmail.com> wrote:
>
> > > > > > > What I do is I write the gadget in a way that makes it work both
> > > > > > > locally (or as a website on a remote server) and then I add a layer on
> > > > > > > top that makes it work with Google Wave. That way I can test 90% of
> > > > > > > the gadget locally, no problem. And for the other 10% I just use the
> > > > > > > debug features of the sandbox Wave client. That has worked good so far
> > > > > > > even for bigger/more involved gadgets and the bonus is that your
> > > > > > > gadget then doesn't need to be Wave exclusive.
>
> > > > > > > If you'd want to use a test-driven
>
> ...
>
> read more »
Jonas Huckestein
things up.
Using runAsync with the gadget linker gives you a message saying that
you cannot have multiple fragments with that linker. (that seems to be
the same message I get when using the XS linker)
Maybe I will look into the runAsync support :) But so far I haven't
found a lot of resources on how linkers work (and what primary and
secondary ones are), so we'll see. And I'll definitely check whether
ClientBundles work.
Off-Topic (as is most of this post): Wouldn't it be a good idea to
bake the selection script into regular HTML host pages, as well?
Cheers, Jonas
> > > > > > over to my blog athttp://thezukunft.comortheprojectpageathttp://code.google.com/p/wavec.... It's as easy
> > > > > > as downloading a zip archive :D
>
> > > > > > Chris, how di you achieve the 90%? I assume you must also decouple the
> > > > > > GWT code from the Gadget/Wave API? I have simply implemented a mock
> > > > > > version of the wave API. That way I think I can do all testing
> > > > > > locally.
>
> > > > > > Kayode, WaveConnector is exactly the mock framework (+ some
> > > > > > convenience functions) I was talking about :)
>
> > > > > > Sorry for this shameless selfpromotion on this board but I think this
> > > > > > might actually help a lot of people or get them to develop for Wave in
> > > > > > the first place.
>
> > > > > > What do all of you think of a dedicated Wave+GWT group? I asked that
> > > > > > question on the GWT groups earlier and people seemed to be interested.
>
> > > > > > Cheers, Jonas
>
> > > > > > This is my first ever open source contribution so please give me
> > > > > > comments and feedback on my blog or the project page.
>
> > > > > > On Feb 10, 2:07 am, HaiColon <haico...@gmail.com> wrote:
>
> > > > > > > What I do is I write the gadget in a way that makes it work both
> > > > > > > locally (or as a website on a remote server) and then I add a layer on
> > > > > > > top that makes it work with Google Wave. That way I can test 90% of
> > > > > > > the gadget locally, no problem. And for the other 10% I just use the
> > > > > > > debug features of the sandbox Wave client. That has worked good so far
> > > > > > > even for bigger/more involved gadgets and the bonus is that your
> > > > > > > gadget then doesn't need to be Wave exclusive.
>
> > > > > > > If you'd want to use a test-driven
>
> ...
>
> read more »