Hi,

Is it possible (or on some wish list) to register new data types with fpjson so it can understand and generate custom output, and understand reading back that custom output.

eg:

Current I write a TColor value to JSON and it results in:

"BackgroundColor": -2147483648

Yes, technically that is correct, and Delphi/FPC code will understand that, but other programming languages will not. So I was wondering if we could somehow tell fpjson to render TColor output for example as:

"BackgroundColor": #FF00AA

or maybe

"BackgroundColor": $FF00AA

or maybe

"BackgroundColor": { "R": $FF, "G": $00, "B": $AA }

or maybe

"BackgroundColor": { "R": 255, "G": 0, "B": 170 }

The first two are probably preferred over the latter two for my needs.

This is not just for TColor, but I have various other data types I think would be useful having improved JSON output/input in a slightly different format. eg: Improving the formatting of floating point values would also be nice.

eg: Currently I get:

"Width": 2.66680002212524

but would prefer

"Width": 2.6668

Regards,
Graeme

There cannot be custom output in JSON, then it would no longer be JSON. JSON is a fixed defined format; it does not allow "deviation".

What you probably need is what RTTIJSON does, or the restbase class. Alternatively WST also has a serializer that outputs JSON.

But they all have 1 thing in common: they take an object instance, and serialize this to JSON or vice versa. Custom types must be coerced into one of the types that JSON understands.

Michael.

Michael Van Canneyt wrote

There cannot be custom output in JSON, then it would no longer be JSON. JSON is a fixed defined format; it does not allow "deviation".

Maybe you understood me wrong, or my output examples were rubbish - you pick. ;-) I don't mean generating non-standard JSON output. The output will still be true JSON, just in a improved format for multiple applications (not just FPC or Delphi based) to understand.

eg:
Here is a snippet of a JavaScript based Report Designer that outputs colour values to JSON:

"Brush": "solid:77,182,172",
"TextBrush": "solid:255,255,255",

Note, it is still valid JSON, but it is an improved output format that most likely multiple application could understand better than the original TColor value.

Now obviously I can manually format TColor to the above string output, and than parse the string data when read again. I would have to do this at all places where I save/read a TColor value.

My suggestion is if one could register a TColor reader/writer type, and fpjson can then do the rest - using the helper classes when needed. I would only have to register this new type once in my application, and persisting TColor could be simpler in my code.

Granted, I haven't given this much thought - it's just an idea that popped up. So there is most likely some details or usage idea that need to be worked out.

Another useful example would be persisting enum types. Currently I have to write functions like StretchTypeToString() and StringToStretchType() and then use these all over my code where I read/write a TStretchType value. I'm hoping the above idea could simplify code like this too.

Regards,
Graeme

JSONRTTI, RestBase or WST do all this for you. It takes care of enumerateds objects, arrays etc.

JSONRTTI, RestBase can easily be enhanced to support a custom type registry:

RegisterType(TypeInfo(TMySpecialType), @Reader, @Writer)

Where reader and writer are defined along the lines of:

AReader = Procedure (Instance : TObject; AProperty: PPropInfo; Data : TJSONData) of Object;
AWriter = Function (Instance : TObject; AProperty: PPropInfo) : TJSONData of object;

or so.

Michael.

Michael Van Canneyt wrote

JSONRTTI, RestBase can easily be enhanced to support a custom type registry: RegisterType(TypeInfo(TMySpecialType), @Reader, @Writer)

That's what I had in mind. If I have a spare moment I'll take a look at that. Thanks for pointing me in the right direction.

Regards,
Graeme