The main complexity arises from several instances of nested types
(which can be arrays). The protos below are not complete but should be
sufficient to give you the design in use here.
The 1st proto is complete. 2nd proto is much more detailed. I too was
thinking about reflection but without a base object to deserialize to,
I didn't know how to proceed.
proto1:
message MsgReason {
message TranslatedReason {
optional bool is_suppressed = 1;
optional string orig_msg = 2;
optional string translated_msg = 3;
}
enum Type {
Text = 0;
TranslatedFix = 1;
Xml = 2;
}
required Type type = 1;
optional bytes body = 2;
}
proto2:
enum LastCapacity
{
UNKNOWN = 0;
PRINCIPAL = 1;
}
message ExecInfo
{
required string exec_id = 1;
required fixed64 timestamp = 2;
required int32 qty = 3;
required sfixed64 price = 4;
optional bytes mkt_parameters = 6;
optional LiquidityInd liquidity = 7;
required LastCapacity capacity = 8;
optional int32 exec_src = 9;
}
message ExecStatus
{
required Status status = 1;
required int32 cumqty = 2;
required sfixed64 avgpx = 3;
}
message Execution
{
required CmdID id = 1;
required ExecInfo exec = 2;
required ExecStatus status = 3;
}
On Sep 29, 3:09 pm, Marc Gravell <[email protected]> wrote:
> Well... how complex is the data? Reflection seems the most obvious
> choice if it is available - especially since that will work well with
> things like PropertyGrid (if you are in winforms). If I understood the
> scenario better I may have more ideas...
>
> Marc
>
> On Sep 29, 6:39 pm, "[email protected]" <[email protected]>
> wrote:
>
> > Bummer.. It would've been a great feature. I'm faced with displaying
> > several complex nested protos and the simplest way would've been a 2
> > column list view that was populated by a generic proto reader.
>
> > I'm looking at Jon's solution, but I really don't want to have to
> > implement and maintain 2 protobufs for each object in the client, just
> > for display purposes.
>
> > Thanks
>
> > On Sep 29, 10:58 am, Marc Gravell <[email protected]> wrote:
>
> > > In protobuf-net? No. You could deserialize into the expected type and
> > > use reflection, though. It is perhaps something I could consider
> > > should I find time though - presumably in the non-type based branch
> > > (experimental; unstable; incomplete...).
>
> > > Jon's version may have other options here? dotnet-protobufs
>
> > > On Sep 29, 4:03 pm, "[email protected]" <[email protected]>
> > > wrote:
>
> > > > Is there a way to generically read a protoBuf byte[] and extract a
> > > > field tag/name to value mapping?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Protocol Buffers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~----------~----~----~----~------~----~------~--~---
