tracker issue | What iT iS dESign studios

Title:

Subapplications cannot practically use custom serialisers

| View in Tracker

Status/Resolution/Reason: To Fix//MustFix

Reporter/Name(from Bugbase): Adam Cameron / Adam Cameron (Adam Cameron)

Created: 04/27/2014

Components: REST Services

Versions: 11.0

Failure Type: Usability Issue

Found In Build/Fixed In Build: PublicBeta /

Priority/Frequency: Minor / Some users will encounter

Locale/System: English / Platforms All

Vote Count: 1

Long version:
http://cfmlblog.adamcameron.me/2014/04/coldfusion-11-custom-serialisers-more.html

TL;DR:
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".

-- 
Adam

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3750731

External Customer Info:
External Company:  
External Customer Name: Adam Cameron.
External Customer Email:  
External Test Config: My Hardware and Environment details:

Attachments:

May 08, 2014 00:00:00: 1_adam.rar

Comments:

I am trying to understand the difficulty here.

I don't get what issue you are facing for configuring the Serializer in sub applications. Why configuring the Serializer in Sub application Application.cfc is such a bad idea? Are you saying that sub applications does not have an Application.cfc? 

I believe the Custom serializer has to be application specific. Some applications might need it. Some might not. Just configuring the Serializer in Application.cfc looks like the simplest approach.

Comment by Paul N.

12507 | May 06, 2014 08:16:36 AM GMT

It really would be so much easier if you could read these tickets (and perhaps the attached blog article) before replying, Paul.

-- 
Adam

Comment by External U.

12508 | May 06, 2014 08:36:19 AM GMT

I have read the post. Still I don't understand why it cannot be used in sub applications.

When I make a modern web application (which generally aren't just a single monolithic site, but an aggregation of various other sub applications), some sub applications would want to use serializer, and some will not want to use custom serializer.

ColdFusion requires you to configure which all sub applications need custom serializer in Application.cfc. If you want to use the same serializer in your sub applications, you can put your serializer in a mapped folder and use the path in all your Application's Application.cfc.

Is there anything wrong with that approach? Is it not working for you?

Comment by Paul N.

12509 | May 07, 2014 07:14:11 AM GMT

Have you every built a ColdFusion website using FW/1, Coldbox, etc in the past, Paul? have you ever actually *used* ColdFusion *at all*?

You haven't, have you?

-- 
Adam

Comment by External U.

12510 | May 07, 2014 07:26:12 AM GMT

I am trying to understand the problem here. I tried a test case to access the CustomSerializer in sub applications. It worked fine for me. If you could explain me the difficulty in doing that, it would be really helpful.

Comment by Paul N.

12511 | May 07, 2014 08:50:58 AM GMT

OK. I have a website at C:\webroots\mysite. In that I have my *single* Application.cfc. It's the Application.cfc for the website. So any custom serialiser bumpf needs to go in there.

I also use a third-party module, called... HotBox. It is installed via dropping it into a mapped dir, /HotBox, and adjusting Application.cfc to extend Hotbox.Application. Then HotBox "works" in my site (doing whatever it does). This is the usual way modules/apps/frameworks are plugged-in to a CF website: via the minimum amount of interference and touch points into the site they're being integrated into. This is how CF websites are built these days (where "these days" are "since the turn of the century").

Now... if the author of HotBox wants to leverage the concept of custom serialisers (which is entirely reasonable, and a very real requirement that needs to be catered for)... they have to require me to edit *my* customserialiser file to put some inclusions into it to hook back into HotBox. And having to do that is just a bit crap.

How to solve this? I dunno. But it should have been a challenge that was apparent to you from the outset of development of this CF feature.

The whole approach of having a single point that needs to know everything about what needs to be (de)serialised is just an "epic fail" to use zeitgeisty vernacular.

And, to be frank, I said all this in the blog article. So it's slightly irksome to have to repeat it.

-- 
Adam

Comment by External U.

12512 | May 07, 2014 09:14:46 AM GMT

Adam, Thanks for clarifying the scenario. This is what I understood.

In your application you have defined a Custom Serializer and it is configured in your Application CFC. Your Application CFC extends from the framework's Application CFC. So if there is some serialization requirement in the framework, it should use your Application's Custom serializer. The framework should use the serialization logic from the application, rather than using ColdFusion's default serialization.

I tried a simple test case like this. And it is working for me. I have attached the test case also. Please check and let me know, whether this is your requirement.

Comment by Paul N.

12513 | May 08, 2014 01:49:36 AM GMT

You're missing the point, Paul, sorry. It's not *for the website* to dictate how "HotBox" objects are serialised... HotBox already knows how to (de)serialise its objects... it's just got no way of having this wired-in to the website's serialiser CFC, short of actually requiring the owner of the website to hack their code to accommodate HotBox (and any other plug-in module they might use).

One very jerry-built way it might work is have the site's serialise extend HotBox's one, I suppose... but it still requires hacking about to then have the site's methods also call the super methods. And this only works for a single module.

At the very least you need a way of specifying more than one serialiser, but, really, the serialisation should NOT be deferred to a single point of failure. It's really just not necessary (as discussed in my article... which I'm not sure you've read, by the sounds of it?)

-- 
Adam

Comment by External U.

12514 | May 10, 2014 03:58:38 AM GMT

Thanks Adam for explaining the scenario. I am thinking of a solution. It is not final. But just a thought. We can support multiple custom serializers.

In the Application.cfc, we can take a new setting like,

this.customSerializers = {cs1 = "MySerializer", cs2 = "FrameworkSerializer" };
this.customSerializer = "cs1/MySerializer"; //Default serializer to be used

Now the default serializer is "MySerializer". de/serializeXML() can take an optional argument to specify the serializer to be used.

i.e., in HotBox application, they can say

serializeXML(testStr, true, "cs2");

And if the Custom Serializer is to be used in a RESTful service, they can configure the custom serializer as an attribute.

For eg:-

<cfcomponent restPath="test" customSerializer="cs2">
.....
</cfcomponent>

If these are not configured or passed as argument for de/serialize() APIs, then the default custom serializer of the application will be used.

This way, HotBox can implement their code, to use the framework serializer and configure the serializer in CustomSerializers setting. So this setting will be available(inherited) to my actual application which is extending from the HotBox Application.cfc.

What are your suggestions?

Comment by Paul N.

12515 | May 12, 2014 08:00:01 AM GMT

Hi Paul,

Regarding "de/serializeXML() can take an optional argument to specify the serializer to be used":

de/serializeJSON() would also take this same parameter, right?

Regarding this.customserializers, yes, supporting multiple serializers would be a good thing IMO.

Thanks!,
-Aaron

Comment by External U.

12516 | February 14, 2015 02:37:58 PM GMT

+1 ......................

Vote by External U.

12519 | February 14, 2015 02:38:11 PM GMT

*bump*

I need to create a task to *bump* tickets at least 1x/year =)

Comment by External U.

12517 | April 19, 2016 11:27:35 PM GMT

Hi Paul,

Instead of adding another parameter to de/serializeXML() and de/serializeJSON(), how about allowing "useCustomSerializer" to accept a string (to specify the serializer to use). Example:

Old:
--------------------------------------------
serializeXml(Object objToBeSerialized, boolean useCustomSerializer)

New:
--------------------------------------------
serializeXml(Object objToBeSerialized, string useCustomSerializer)

And same change for deserializeXML/serializeJSON/deserializeJSON.

Thanks!,
-Aaron

Comment by External U.

12518 | April 20, 2016 01:10:02 AM GMT

Hi Adobe,

Is there someone there that could read my above questions, and possibly reply?

Regarding my last question (about changing the `useCustomSerializer` parameter from boolean to string in serializeXML/deserializeXML/serializeJSON/deserializeJSON), I realize there'd be a conflict if someone set that parameter to `false` whilst also having `this.customSerializers = {false = "MySerializer", cs2 = "FrameworkSerializer" };` (note the boolean serializer name) in Application.cfc.. but is that really a problem? :)

Thanks!,
-Aaron

Comment by Aaron N.

31275 | September 04, 2019 10:08:44 AM GMT

By "is that really a problem", I mean.. is that really a problem that CF needs to cater to?

Comment by Aaron N.

31276 | September 04, 2019 10:10:30 AM GMT

THIS.customSerializers could disallow boolean key names. Then `useCustomSerializer` parameter could accept any THIS.customSerializers key name. No need for yet another "optional argument to specify the serializer to be used". Just dual-purpose the existing `useCustomSerializer` parameters to accept a boolean (to preserve existing behavior) and a string (a THIS.customSerializers key name).

Thanks!,
-Aaron

Comment by Aaron N.

31279 | September 05, 2019 02:39:46 AM GMT

tracker issue : CF-3750731

Subapplications cannot practically use custom serialisers