Interesting question. Gin auto-creates RPC interfaces as well, for
example, if you have:
public interface MyFoo extends Ginjector {
MyServiceAsync getService();
}
then Gin implicitly looks for MyService.class and invokes
GWT.create(MyService.class) when calling getService(). Since Gin is
handling the creation, I'm not sure if it handles RPC methods with
classes have have @Inject annotations, but you could probably setup a
separate binding. The de-serialization logic in RPC is not likely to
allow Gin interception, since it apparently uses default constructors
to create classes, and what you want it to do is delegate the
construction to some injectable mechanism (e.g. to substitute your own
subclasses)
It doesn't sound impossible to make this work, and is probably easier
to get right than trying to make new Foo() interceptable by the
compiler. I would join the Gin groups and ask the guys there about it.
-Ray
On Tue, Apr 21, 2009 at 11:49 AM, nicolas de loof
<nicolas.del...@gmail.com> wrote:
> Sounds a good solution.
> How would this solve the use case "data returned by RPC call" ?
>
> 2009/4/21 Ray Cromwell <cromwell...@gmail.com>
>>
>> I really think Guice-style dependency injection is the way to go to
>> solve this problem, rather than trying to emulate Java
>> Proxies/Classloader in the compiler. If you use Guice/Gin, then in Gin
>> you can inject GWT.create-d versions, and in JUnit-mode, you can use
>> regular Guice injection. The code use is 99% between GWT and non-GWT
>> versions test versions, with the exception of the
>> Guice-config/Injector creation.
>>
>> Because of the way Gin works transitively, you only need a single
>> GWT.create() and this is isolated to your startup code while in your
>> JUnit version, you kick off a Guice-injected class instead.
>>
>> -Ray
>>
>> On Tue, Apr 21, 2009 at 11:28 AM, nicolas de loof
>> <nicolas.del...@gmail.com> wrote:
>> > A simple example : databinding
>> > Lets consider I want to bind some Label text to some model Bean value.
>> > Gwt
>> > Label widget "text" can be accessed as a javaBean property, so this
>> > sound a
>> > typical java.beans.binding use-case
>> > This requires my model bean to support PropertyChangeListeners. As I'm
>> > lazy
>> > I'd like a generator to create an "enhanced" model class with such
>> > support
>> > for the "value" property.
>> > I can get this to work today if my model Bean is created using
>> > GWT.create(),
>> > but this makes my code GWT-dependant and not testable in "standalone"
>> > junit.
>> > If the generator "enhanced" class is used even when I use " new Model()
>> > " or
>> > get a Model bean from RPC, my code can be easily unit tested.
>> > Cheers,
>> > Nicolas
>> >
>> > 2009/4/21 Bruce Johnson <br...@google.com>
>> >>
>> >> On Tue, Apr 21, 2009 at 12:38 PM, nicolas de loof
>> >> <nicolas.del...@gmail.com> wrote:
>> >>>
>> >>> The only critism I'd have is the requirement to use GWT.create() to
>> >>> get
>> >>> code from a generator. This is a requirement when the generated code
>> >>> doesn't
>> >>> extend the source type (for example for Async interfaces) but not when
>> >>> the
>> >>> genrator is used to add some capabilities (ie acts as a decorator),
>> >>> for
>> >>> example to add PropertyChangeListener to a model bean.
>> >>
>> >> Perhaps if you could distill down a more concrete example, it could get
>> >> the wheels turning. Enhancements to GWT.create() certainly aren't off
>> >> the
>> >> table. Ray Cromwell has made some pretty useful-sounding suggestions in
>> >> the
>> >> past. We just have to find large-group consensus on what makes the most
>> >> sense, striking a balance between power, clarity, and of course,
>> >> optimizability.
>> >>
>> >> Here's a quick back-of-envelope pattern that could possibly work:
>> >>
>> >> class PersonBean {
>> >> void setName(String name):
>> >> String getName();
>> >> }
>> >>
>> >> interface MethodCallLogger {
>> >> }
>> >>
>> >> class MyEntryPoint {
>> >> class PersonBeanWithMethodCallLogger extends PersonBean implements
>> >> MethodCallLogger {
>> >> // empty, but a subclass gets generated
>> >> }
>> >>
>> >> public void onModuleLoad() {
>> >> // Have a generate-with rule for MethodCallLoggerGenerator,
>> >> triggered
>> >> by assignability to "MethodCallLogger"
>> >> PersonBean pb = GWT.create(PersonBeanWithMethodCallLogger.class);
>> >> pb.setName("Nicolas");
>> >> }
>> >> }
>> >>
>> >> // Generated...
>> >> class PersonBeanWithMethodCallLoggerImpl extends
>> >> PersonBeanWithMethodCallLogger {
>> >> void setName(String name) {
>> >> someLogger.log("setName('" + name + "') called");
>> >> super.setName(name);
>> >> }
>> >>
>> >> ...
>> >> }
>> >>
>> >> As formulated above, this pattern doesn't compose well. But it might be
>> >> that we can forge a pattern like this into something everyone likes
>> >> eventually.
>> >>
>> >> -- Bruce
>> >>
>> >>>
>> >>> This makes unit testing more difficult as code that uses GWT.create
>> >>> cannot run in "classic" jUnit. It would be great to have the compiler
>> >>> use
>> >>> generator-extended classes even when created using the standard "new"
>> >>> keyword.
>> >>> Thanks a lot for the explanation.
>> >>> Nicolas
>> >>>
>> >>> 2009/4/21 Bruce Johnson <br...@google.com>
>> >>>>
>> >>>> A sort of philosophical meta-point that may or may not be of
>> >>>> interest...
>> >>>>
>> >>>> When we started GWT, we were worried about managing the complexity of
>> >>>> compile-time code generation, so we tried to find the simplest, most
>> >>>> easy-to-debug approach we could think of. GWT's model of never
>> >>>> changing
>> >>>> existing code[1], but only adding new Java source during the compile,
>> >>>> is
>> >>>> really a design choice, not a technical limitation. The benefit of
>> >>>> the
>> >>>> current design is that you can add -gen to hosted mode and map the
>> >>>> corresponding folder into your source path, and then easily step
>> >>>> through all
>> >>>> your code, both handwritten and generated, in the debugger. This
>> >>>> avoids
>> >>>> tricky or confusing situations wherein the source code you see
>> >>>> appears to be
>> >>>> doing something different than the bytecode that's running. It seems
>> >>>> good to
>> >>>> avoid that kind of dichotomy, on the principle that
>> >>>> straightforward-though-verbose is generally better than
>> >>>> fancy-but-confusing.
>> >>>>
>> >>>> [1] Overlay types were the first time we ever even did bytecode
>> >>>> rewriting, and that support is implemented at a very deep level.
>> >>>> Also, JSOs
>> >>>> are intended to be among only a very few "magic" things in GWT
>> >>>> (basically,
>> >>>> JSNI, GWT.create(), GWT.runAsync(), and JSOs). We went to a lot of
>> >>>> effort to
>> >>>> ensure that JSOs worked according to a fixed set of rules that are
>> >>>> not hard
>> >>>> to comply with, even if people don't fully understand why the
>> >>>> implementation
>> >>>> requires it.
>> >>>>
>> >>>> On Mon, Apr 20, 2009 at 11:11 AM, Thomas Broyer <t.bro...@gmail.com>
>> >>>> wrote:
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On 20 avr, 08:43, nicolas de loof <nicolas.del...@gmail.com> wrote:
>> >>>>> > > > I wonder if there is any way to also "pre-process" Java
>> >>>>> > > > sources,
>> >>>>> > > > for
>> >>>>> > > example
>> >>>>> > > > this would enable support for Aspect Oriented Programming or
>> >>>>> > > > maybe some
>> >>>>> > > > DataBinding framework.
>> >>>>> >
>> >>>>> > > Depends what you mean by "pre-process"... Generally, generators
>> >>>>> > > analyze the class they're called for (for example, looking for
>> >>>>> > > specific annotations on methods or on the class itself) and
>> >>>>> > > according
>> >>>>> > > to this generate a Java class extending the one they've been
>> >>>>> > > called
>> >>>>> > > for.
>> >>>>> > > (is this understandable? is this at least no-so-bad english?)
>> >>>>> >
>> >>>>> > In many case the generator will create from MyClassX some
>> >>>>> > MyClassXImpl or
>> >>>>> > equivalent that extends the original one, bu not REPLACE it as
>> >>>>> > Java
>> >>>>> > source.
>> >>>>> > This is what I mean by "pre-process".
>> >>>>> >
>> >>>>> > For example, to implement a AOP framework I'd like to instrument
>> >>>>> > all
>> >>>>> > calls
>> >>>>> > to some method. For this reason I'd like a generator /
>> >>>>> > pre-processor
>> >>>>> > to
>> >>>>> > check the source files and detect the matching pointcuts to add
>> >>>>> > some
>> >>>>> > adived
>> >>>>> > code. Many other example can apply, including annotation
>> >>>>> > processing
>> >>>>> > for
>> >>>>> > declarative coding (ex : @Property annotation to automagically
>> >>>>> > introduce the
>> >>>>> > required PropertyChangeListeners)
>> >>>>>
>> >>>>> You would generate a subclass that delegates to super.method()
>> >>>>> after/
>> >>>>> before the aspect(s) code.
>> >>>>>
>> >>>>> > I never tried it myself, but I'n not sure a generator can REPLACE
>> >>>>> > the
>> >>>>> > original Java Source.
>> >>>>>
>> >>>>> AFAICT, it can't, but there's probably no need for this.
>> >>>>>
>> >>>>> > I may be wrong but I also thing the generated code is
>> >>>>> > only available when using GWT.create(),
>> >>>>>
>> >>>>> The generator is only called at the point where GWT.create() is
>> >>>>> called
>> >>>>> (I may be wrong but you could generate a different output for each
>> >>>>> GWT.create() call-point for the same class literal), so yes, you're
>> >>>>> right.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>
>> >>
>> >>
>> >
>> >
>> > >
>> >
>>
>>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
