Generated GWT Protobuffers - base class, name about protostuff-googlecode-exported

[GoogleCodeExporter]

Here's a patch for the name:

Original comment by [email protected] on 13 May 2010 at 9:01

Attachments:

• gwt_overlay.stg.diff

[GoogleCodeExporter]

Damn. There's a semi colon missing in two places in that patch. Should be in 
the 
obvious location :)

Original comment by [email protected] on 13 May 2010 at 9:02

[GoogleCodeExporter]

Actually, scratch that. I blame jetlag, that won't work. Open to other ideas. 
Right now I 
have an attribute that I strip out before serialising.

Original comment by [email protected] on 14 May 2010 at 2:00

[GoogleCodeExporter]

Yep ... the limitation of the overlay.
The type descriptor could be added as an option.
It could be a generated service endpoint that handle that.
Would be great if you can contribute to tailor it to your needs.

Cheers

Original comment by [email protected] on 14 May 2010 at 3:43

[GoogleCodeExporter]

Here's a different, still pretty ghetto, approach. I suspect the only way to 
make this work  
properly will be to move away from the JavaScriptObject based approach. As a 
bonus, I 
added hasFoo() methods.

Anthony

Original comment by [email protected] on 14 May 2010 at 7:13

Attachments:

• gwt_overlay.stg.diff

[GoogleCodeExporter]

I can add this via compiler options.

Not sure about moving away from JavaScriptObject on gwt.
In case you already have an idea, feel free to create a custom compiler.  
Should be
pretty quick with stringtemplate.  It could also be added to the list of 
compilers.

I've just added a compiler that complements the code generated by c++ protoc.
http://code.google.com/p/protostuff/wiki/JSONSerialization#java_v2protoc_schema

Original comment by [email protected] on 14 May 2010 at 4:48

• Changed state: Accepted

[GoogleCodeExporter]

The message fullname does need to be there on a protocol with multiple 
protobuffers.
I'm proposing the ff. gwt_overlay options:
${messageName}.include_name
${messageName}.include_fullname
${packageName}.include_name
${packageName}.include_fullname

// to save space vs "_protoMessageName"
getProtobufName() would return instance["_pbn"] 
getProtobufFullName() would return instance["_pbfn"]

Btw, is the name needed for the wrapped messages?  From a protocol standpoint, 
the
request message's descriptor might just be enough since it already identifies 
its
message fields.

Original comment by [email protected] on 15 May 2010 at 3:21

[GoogleCodeExporter]

Is it worth mirroring the Google PB approach of 
getDescriptorForType().getName() (or 
whatever it's spelt)...

Original comment by [email protected] on 16 May 2010 at 7:33

[GoogleCodeExporter]

Yea it makes sense.  Looking into it atm.

Original comment by [email protected] on 16 May 2010 at 8:27

[GoogleCodeExporter]

The fields you were needing are only name and fullName right? (possibly 
extensions also)

The others are for proto file metadata and others purely for dynamic messages.
I suppose you won't be needing these?

Original comment by [email protected] on 16 May 2010 at 4:29

[GoogleCodeExporter]

Here's my current set of changes. Things I've added:

simple shim versions of newBuilder() and Builder
getFooList() methods for repeated fields
made setFoo return this

this makes a whole pile of code that was written against com.google.protobuf 
just 
work :)

Original comment by [email protected] on 16 May 2010 at 8:07

Attachments:

• gwt_overlay.stg.diff2

[GoogleCodeExporter]

Hmm, so the compiler actually permits gwt overlays does allow to be subclassed.
Nice.

I'm getting errors ... getFooCount() doesn't exist

    public final java.util.List<Integer> getSomeIntList() {
        JsArrayInteger array = getSomeIntArray();
        java.util.List<Integer> list = new java.util.ArrayList<Integer>();
        if (array == null) {
          return null; 
        }
        for (int i=0; i < getSomeIntCount(); i++) {
          list.add(array.get(i));
        }
        return list;
    }

Will change it to:
        JsArrayInteger array = getSomeIntArray();
        if (array == null) {
          return null; 
        }
        java.util.List<Integer> list = new java.util.ArrayList<Integer>(array.length());
        for (int i=0; i < array.length(); i++) {
          list.add(array.get(i));
        }

This will be added via option ("emulation_mode"?) on a separate stg ... 
basically
extending the template gwt_overlay.stg. (like how java_bean_separate_schema.stg 
works)

Thanks

Original comment by [email protected] on 17 May 2010 at 6:23

[GoogleCodeExporter]

Its now added via gwt_overlay_emulation_mode.stg (rev 786)

I've added 
[http://code.google.com/p/protostuff/wiki/WritingCustomCodeGenerators] so
I won't have to restructure your patch :P

Its preferred to always use an option for adding features/extras.
(one-size-does-not-fit-all)

Let me know if you're interested in contributing (with write access).

Cheers

Original comment by [email protected] on 18 May 2010 at 12:43

[GoogleCodeExporter]

Original comment by [email protected] on 20 May 2010 at 9:34

• Changed state: Fixed

[GoogleCodeExporter]

You can now supply your customized stg resource to the compiler.

Just rename it to gwt_overlay.java.stg (.java indicates the type of resource it
generates)

gwt.output = path/to/your/custom/gwt_overlay.java.stg

It should work out-of-the-box since your modified stg already contains the 
templates
necessary.

Hope that helps.

Original comment by [email protected] on 31 May 2010 at 2:42