SerializeJSON() - some optional parameters

language proposals
1

I am new to Lucee and the first task was migrating a CF10 legacy app. One property of that app was to produce JSON with lowercase keys.

See this discussion for more detail and the way I solved it if you are interested: Topic 10619

As a result of trying to solve the issue I thought I could offer this proposal for the SerializeJSON function. The idea is that if you need something custom you can do it on a case-by-case basis.

  1. Optional parameter: keyCase: ‘preserve’ | ‘upper’ | ‘lower’
    If missing, revert to the server settings as now: preserve or upper

  2. Optional parameter: transform(key, value) function
    The idea is for those edge cases where you need complete control on a specific serialization task so you can adjust each key:value result as you go.
    eg you might need transforms like the ones GSON offers:
    LOWER_CASE_WITH_UNDERSCORES, LOWER_CASE_WITH_DASHES, etc
    but with a transform function you could do whatever you liked, and even just filter for a specific key that needs adjustment to either the key name or value.

BTW: as part of my attempts to solve the issue at hand, I made a jar class wrapper around GSON and tried that instead since it has a method similar to the one I am proposing where I set all keys to lowercase. That was definitely fast, but not accurate. eg a numeric integer field from Lucee of 38 that SerializeJSON returns as “38”, GSON returned as “38.0”. :frowning:

Opinion: I know you can manage the key casing and format when you create the structs in the first place. In my mind, however, the serialization is a concern that the originating code should not have to worry about. eg if you DID need lowercase keys with dashes or to adjust a specific property name just for serialization because the requesting client needs it that way, this should be the concern of the serializer, not the business logic.

Anyway, just a suggestion.

Thanks,
Murray

2

Just shooting from the hip…
(I have done no research / experimenting to prove/disprove what I am saying)

For simplicity sake, could you not use a Functional Programming approach and “.map” a function for every key?

Gavin

3

I am not sure, Gavin. Can you give an example of how you would do that (in theory)?

var myNestedStruct = { props here }
var json = serializeJSON(myNestedStruct); // How to map?

or maybe I am missing the point altogether?
Thanks,
Murray

4

@flowt-au for request/optional features please create an enhancement ticket in Jira https://luceeserver.atlassian.net/ under the Lucee Development (LDEV).

for transform(key, value) function parameter, you can achieve this by using BIF struct.each().

1 Like
5

Thanks @cfmitrah.
Transform: In fact using struct.each() was the solution I used: Topic 10619

The reason for suggesting the transform function as part of the SerializeJSON() was to avoid processing the struct (or array of structs or even array of nested structs) twice - once to transform keys/values and again to serialize it. My thinking is that it will shave some time off the whole process if the optional transform is called as part of the serialization pass. But maybe I am wrong about that.

Also, as a convenience, developers would only need to provide a function that handled one key:value pair at a time, rather than the recursive function with tests for data types that my solution involves. Or, maybe my solution is not optimal.

Anyway… it was just a suggestion.
:slight_smile:
Murray

1 Like
6

Done for the optional keyCase parameter. :slight_smile:
Murray

7

Jira ticket : LDEV-4069 - SerializeJSON: add an optional keyCase parameter

1 Like