Yes, the option to extend RPC and gadgets are two separate ideas. > Code generation is one of the core features of GWT, and nothing new is being > added to the Java programming language, as the syntax is part of the Java > language.
The reason GWT works is because HTML and Javascript evolve very slowly. A tight Java binding to a fast-changing Javascript API like Gadgets or OpenSocial is asking for trouble because you won't be able to keep updating the Java code fast enough. Alex On Thu, Jan 22, 2009 at 5:08 PM, Ray Cromwell <cromwell...@gmail.com> wrote: > > I think there are two issues. One is providing hooks to allow the RPC call > to be dispatched via a customized mechanism. This can range from > makeRequest() with POST, to cross-domain JSONP, to ProtocolBuffer > RpcChannel. I've brought up this issue time and time again, as I've been an > early adopter of writing complex GWT apps inside of Gadgets. I think it > would be useful to revisit the RPC design in the future to make it easier to > plugin custom methods, not just for Gadgets/makeRequest, but also for stuff > like JSON wireformats and ProtocolBuffers. > The issue of the GadgetLinker manifest generation is separate. I happen to > like the concept, but dislike the current implementation. I like the > auto-generation of the manifest, the type safety of dependency-injected > interfaces. However, the current system is too inflexible. It doesn't > support multiple Gadget views, it doesn't support "optional" feature > requirements. That is, if you require an optional feature in the manifest, > the feature interfaces will still get injected even if they weren't loaded. > Simply put, I don't find using annotations, generators, and linkers scary. > Code generation is one of the core features of GWT, and nothing new is being > added to the Java programming language, as the syntax is part of the Java > language. > On a wider now, realistically, GALGWT needs official bindings for non-legacy > Gadgets and OpenSocial. I've implemented JSOs for most of those privately as > Gadget features, but it would be nice to have an officially sanctioned > Google binding. > > -Ray > > On Thu, Jan 22, 2009 at 1:13 PM, Alex Epshteyn > <alexander.epsht...@gmail.com> wrote: >> >> Background: >> >> OpenSocial containers provide the method gadget.io.makeRequest because >> gadget scripts aren't able to use XHR due to the SOP. Furthermore, I >> believe, OpenSocial containers don't expose the _IG_GetCachedUrl(url) >> method that the gwt-gadgets library uses. >> >> Now, regarding the gwt-gadgets library, to be blunt, it simply scares >> me. I don't want all the gadget stuff brought into the Java >> programming language with interfaces and annotations. Having the >> bootsrap and gadget.xml generated with a custom linker is scary and >> unnecessary. This is just asking for trouble with a leaky >> abstraction. >> >> The RPC Problem: >> >> It's very easy to write a Google Gadget with GWT without using the gwt- >> gadgets library. Simply write your gadget.xml by hand (there's not >> much to it, really), write your GWT app the traditional way, compile >> it with the XS linker, and write a script tag referencing >> your .nocache.js script in your gadget.xml. You can call all the >> OpenSocial and Gadgets API methods from your GWT code using JSNI (JSO >> overlay types could simplify things a bit). >> >> The only problem is RPC. Currently using GWT-RPC in an OpenSocial >> container seems impossible. You'd have to write a JSON service. >> >> The Proposed Solution: >> >> This is just a rough sketch, but I think this can be accomplished as >> follows: >> >> 1) Subclass RequestBuilder to use gadgets.io.makeRequest >> >> 2) Subclass RemoteServiceProxy and override the protected method >> doPrepareRequestBuilder to return an instance of your custom >> RequestBuilder subclass. >> >> 3) Modify ProxyCreator to allow setting a custom superclass for the >> generated proxy class. I.e. allow chaning this line: >> composerFactory.setSuperclass(RemoteServiceProxy.class.getSimpleName >> ()); >> >> (Perhaps with a system property defining the class name for starters). >> > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
