Issues
- SerializeJSON: add an optional keyCase parameterLDEV-4069Resolved issue: LDEV-4069
- Throwing serialized/deserialized exception object loses original stacktrace and tag contextLDEV-4021Michael Offner
- Better error reporting when ScrptConverter._serialize() fails to serialize an objectLDEV-3998Resolved issue: LDEV-3998Pothys - MitrahSoft
- Serializing fails when referencing non-serializable Java objectLDEV-3997Michael Offner
- server scope can't be serialised on github actionsLDEV-3817
- SerializeJSON does not use custom GettersLDEV-3634Michael Offner
- Add support for serializeXML/deserializeXML and deserialize methods - ACF compatLDEV-3602Michael Offner
- CFC instances in external cached session scope lose runtime mixinsLDEV-3473Michael Offner
- SerializeJSON serializes boolean properties with default incorrect.LDEV-3410Michael Offner
- SerializeJSON serializes bit fields in queries incorrect.LDEV-3406Michael Offner
- add SerializeXML and DeserializeXML functionsLDEV-2181
11 of 11
SerializeJSON: add an optional keyCase parameter
Won't Do
Details
Assignee
UnassignedUnassignedReporter
Murray HopkinsMurray HopkinsNew Issue warning screen
Before you create a new Issue, please post to the mailing list first https://dev.lucee.org
Once the issue has been verified, one of the Lucee team will ask you to file an issue
Priority
New
Details
Details
Assignee
Unassigned
UnassignedReporter
Murray Hopkins
Murray Hopkins
New Issue warning screen
Before you create a new Issue, please post to the mailing list first https://dev.lucee.org
Once the issue has been verified, one of the Lucee team will ask you to file an issue
Priority
NewCreated 12 July 2022 at 22:12
Updated 5 February 2025 at 12:29
Resolved 5 February 2025 at 12:29
Activity
Show:
Zac Spitzer5 February 2025 at 12:28
Rather than overload the existing function with more arguments (alas, the method signatures already differ from ACF), I reckon that if we add support for useCustomSerializer instead that might help achieve your goal with this proposal
As outlined in https://dev.lucee.org/t/serializejson-some-optional-parameters/10636.
To give more control over the case of the JSON keys, I suggest adding an optional parameter:
keyCase: ‘preserve’ | ‘upper’ | ‘lower’
If missing, revert to the server settings as now: ‘preserve’ | ‘upper’
Opinion / rationale: 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 need lowercase keys because the requesting client needs it that way, this should be the concern of the serializer, not the business logic. This is especially useful when migrating legacy cfml code bases that might now need a json api attached. IMO.
Thanks,
Murray