G'day:
I am reposting this from my blog ("ColdFusion 11: custom serialisers. More questions than answers") at the suggestion of Adobe support:
This particular question is not regarding <cfclient>, hence posting it on the regular forum, not on the mobile-specific one as Anit suggested. I have edited this in places to remove language that will be deemed inappropriate by the censors here. Changes I have made are in [square brackets]. The forums software here has broken some of the styling, but so be it.
G'day:
I've been wanting to write an article about the new custom serialiser one can have in ColdFusion 11, but having looked at it I have more questions than I have answers, so I have put it off. But, equally, I have no place to ask the questions, so I'm stymied. So I figured I'd write an article covering my initial questions. Maybe someone can answer then.
ColdFusion 11 has added the notion of a custom serialiser a website can have (docs: "Support for pluggable serializer and deserializer"). The idea is that whilst Adobe can dictate the serialisation rules for its own data types, it cannot sensibly infer how a CFC instance might get serialised: as each CFC represents a different data "schema", there is no "one size fits all" approach to handling it. So this is where the custom serialiser comes in. Kind of. If it wasn't a bit rubbish. Here's my exploration thusfar.
One can specify a custom serialiser by adding a setting to Application.cfc:
component { this.name = "serialiser01"; this.customSerializer="Serialiser"; }
In this case the value - Serialiser - is the name of a CFC, eg:
// Serialiser.cfccomponent { public function canSerialize(){ logArgs(args=arguments, from=getFunctionCalledName()); return true; } public function canDeserialize(){ logArgs(args=arguments, from=getFunctionCalledName()); return true; } public function serialize(){ logArgs(args=arguments, from=getFunctionCalledName()); return "SERIALISED"; } public function deserialize(){ logArgs(args=arguments, from=getFunctionCalledName()); return "DESERIALISED"; } private function logArgs(required struct args, required string from){ var dumpFile = getDirectoryFromPath(getCurrentTemplatePath()) & "dump_#from#.html"; if (fileExists(dumpFile)){ fileDelete(dumpFile); } writeDump(var=args, label=from, output=dumpFile, format="html"); } }
This CFC needs to implement four methods:
canSerialize() - indicates whether something can be serialised by the serialiser;canDeserialize() - indicates whether something can be deserialised by the serialiser;serialize() - the function used to serialise somethingdeserialize() - the function used to deserialise something
I'm being purposely vague on those functions for a reason. I'll get to that.
The first [issue] in the implementation here is that for the custom serialisation to work, all four of those methods must be implemented in the serisalisation CFC. So common sense would dictate that a way to enforce that would be to require the CFC to implement an interface. That's what interfaces are for. Now I know people will argue the merit of having interfaces in CFML, but I don't really give a [monkey's] about that: CFML has interfaces, and this is what they're for. So when one specifies the serialiser in Application.cfc and it doesn't fulfil the interface requirement, it should error. Right then. When one specifies the inappropriate tool for the job. What instead happens is if the functions are omitted, one will get erratic behaviour in the application, through to outright errors when ColdFusion goes to call the functions and cannot find it. EG: if I have canSerialize() but no serialize() method, CF will error when it comes to serialise something:
JSON serialization failure: Unable to serialize to JSON. |
| Reason : The method serialize was not found in component C:/wwwroot/scribble/shared/git/blogExamples/coldfusion/CF11/customerserialiser/Serialiser .cfc. |
|
| The error occurred inC:/wwwroot/scribble/shared/git/blogExamples/coldfusion/CF11/customerserialiser/testBasic.c fm: line 4 |
2 : o = new Basic();
3 :4 : serialised = serializeJson(o);5 : writeDump([serialised]);
6 : |
Note that the error comes when I go to serialise something, not when ColdFusion is told about the serialiser in the first place. This is just lazy/thoughtless implementation on the part of Adobe. It invites bugs, and is just sloppy.
The second [issue] follows immediately on from this.
Given my sample serialiser above, I then run this test code to examine some stuff:
o = new Basic(); serialised = serializeJson(o); writeDump([serialised]); deserialised = deserializeJson(serialised); writeDump([deserialised]);
So all I'm doing is using (de)serializeJson() as a baseline to see how the functions work. here's Basic.cfc, btw:
component { }
And the test output:
This is as one would expect. OK, so that "works". But now... you'll've noted I am logging the arguments each of the serialisation methods receives, as I got.
Here's the arguments passed to canSerialize():
| canSerialize - struct |
|---|
| 1 | XML |
My reaction to that is: "[WTH]?" Why is canSerialize() being passed the string "XML" when I'm trying to serialise an object of type Basic.cfc?
Here's the docs for canSerialize() (from the page I linked to earlier):
CanSerialize - Returns a boolean value and takes the "Accept Type" of the request as the argument. You can return true if you want the customserialzer to serialize the data to the passed argument type.
Again, back to "[WTH]?" What's the "Accept type" of the request? And what the hell has the request got to do with a call to serializeJson()? You might think that "Accept type" references some HTTP header or something, but there is no "Accept type" header in the HTTP spec (that I can find: "Hypertext Transfer Protocol -- HTTP/1.1: 14 Header Field Definitions"). There's an "Accept" header (in this case: "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"), and other ones like "Accept-Encoding", "Accept-Language"... but none of which contain a value of "XML". Even if there was... how would it be relevant to the question as to whether a Basic.cfc instance can be serialised? Raised as bug: 3750730.
serialize() gets more sensible arguments:
So the first is the object to serialise (which surely should be part of the question canSerialize() is supposed to ask, and the format to serialise to. Cool.
canDeserialize() is passed this:
| canDeserialize - struct |
|---|
| 1 | JSON |
I guess it's because it's being called from deserializeJson(), so it's legit to expect the input value is indeed JSON. Fair enough. (Note: I'm not actually passing it JSON, but that's beside the point here).
And deserialize() is passed this:
| deserialize - struct |
|---|
| 1 | SERIALISED |
| 2 | JSON |
| 3 | [empty string] |
The first argument is the value to work on, and the second is the type of deserialisation to do. I have no idea what the third argument is for, and it's not mentioned directly or indirectly on that docs page. So dunno what the story is there.
The next issue isn't a code-oriented one, but an implementation one: how the hell are we expected to work with this?
The only way to work here is for each function to have a long array of IF/ELSEIF statements which somehow identify each object type that is serialisable, and then return true from canSerialise(), or in the case of serialize(), go ahead and do the serialisation. So this means this one CFC needs to know about everything which can be serialised in the entire application. Talk about a failure in "separation of concerns".
You know the best way of determining if an object can be seriaslised? Ask it! Don't rely on something else needing to know. This can be achieved very easily in one of two ways:
- Check to see if the object implements a "Serializable" interface, which requires a
serialize() method to exist. - Or simply take the duck-typing approach: if a CFC implements a
serialize() method: it can be serialised. By calling that method. Job done.
Either approach would work fine, keeps things nicely encapsulated, and I see merits in both. And either make far more sense than Adobe's approach. Which is like something from the "OO Failures Special Needs" class.
Deserialisation is trickier. Because it relies on somehow working out how to deserialise() an object. I'm not sure of the best approach here, but - again - how to deserialise something should be as close to the thing needing deserialisation as possible. IE: something in the serialised data itself which can be used to bootstrap the process.
This could simply be a matter of specifying a CFC type at a known place in the serialised data. EG: Adobe stipulates that if the serialised data is JSON, and at the top level of the JSON is a key eg: type, and the value is an extant CFC... use that CFC's deserialize() method. Or it could look for an object which contains a type and a method, or whatever. But Adobe can specify a contract there.
The only place I see a centralised CFC being relevant here is for a mechanism for handling serialised data that is neither a ColdFusion internal type, nor identifiable as above. In this case, perhaps they could provide a mechanism for a serialisation router, which basically has a bunch of routes (if/elseifs if need be) which contains logic as to how to work out how to deserialise the data. But it should not be the actual deserialiser, it should simply have the mechanism to find out how to do it. This is actually pretty much the same in operation as the deserialize() approach in the current implementation, but it doesn't need the canDeserialize() method (it can return false at the end of the routing), and it doesn't need to know about serialising. And also it's not the main mechanism to do the deserialisation, it's just the fall back if the prescribed approach hasn't been used.
TBH, this still sounds a bit jerry-built, and I'm open for better suggestions. This is probably a well-trod subject in other languages, so it might be worth looking at how the likes of Groovy, Ruby or even PHP (eek!) achieve this.
There's still another issue with the current approach. And this demonstrates that the Adobe guys don't actually work with either CFML applications or even modern websites. This approach only works for a single, stand-alone website (like how we might have done in 2001). What if I'm not in the business of building websites, but I build applications such as FW/1 or ColdBox or the like? Or any sort of "helper" application. They cannot use the current Adobe implementation of the customserializer. Why? Because the serialisation code needs to be in a website-specific CFC. There's no way for Luis to implement a custom serialiser in ColdBox (for example), and then have it work for someone using ColdBox. Because it relies on either editing Application.cfc to specify a different CFC, or editing the existing customSerializer CFC. Neither of which are very good solutions. This should have been immediately apparent to the Adobe engineer(s) implementing this stuff had they actually had any experience with modern web applications (which generally aren't just a single monolithic site, but an aggregation of various other sub applications). Equally, I know it's not a case of having thought about this and [I'm just missing something], because when I asked them the other day, at first they didn't even get what I was asking, but when I clarified were just like "oh yeah... um... err... yeah, you can't do that. We'll... have to... ah yeah". This has been raised as bug 3750731.
So I declare the intent here valid, but the implementation to be more alpha- / pre-release- quality, not release-ready.
Still: it could be easily deprecated and rework fairly easily. I've raised this as bug 3750732.
Or am I missing something?
--
Adam