CFTABLE and CFCOL source code

“User-Interface (UI) code” does not necessarily imply code that contains client-side programming logic. In other words, generated HTML that contains neither JavaScript nor CSS may still constitute UI markup.

I would not call CFTABLE/CFCOL simplistic. In fact, I consider them complex.

For one thing, they combine server-side, business code (queries) with client-side, presentation code (HTML). That is a red flag right there. Combining server-side and client-side goes against a fundamental software best-practice, namely, separation-of-concerns. That alone is a good reason for the tags to be removed or modified.

There is another reason for removal or modification: the age of the HTML version used by CFTABLE. The tag generates HTML 3. That version is 29 years out of date, and HTML has changed a lot in the years since. That tells you that some modernization would have been required for the CFTABLE codebase. In any case, you wouldn’t want to design your backend in such a way that it relies on version changes at the frontend. It seems reasonable to assume that the Adobe ColdFusion team would weigh such considerations.

ColdFusion's codebase is closed-source.  Only the Adobe Team knows which libraries were used by CFTABLE/CFCOL and which, if any, have been deprecated. We can only offer guesses. 

Hi ​@saeedk91074034, I have some thoughts about your appeal to Adobe. You request them to post the source code for CFTABLE and CFCOL to be used on ColdFusion 2025. Unlike what you say, I think it would be a big deal for them to do so. My reason follows.

A likely consequence of the removal of CFTABLE and CFCOL from ColdFusion 2025 is that some or all of the related Java libraries have been removed as well. In fact, I would bet that a significant part of the source code that you’re requesting no longer exists. Not on ColdFusion 2025, in any case.

That your legacy app uses CFTABLE and CFCOL extensively is a major obstacle. It impedes the app’s progress. Not only were these tags deprecated since ColdFusion 2016 and unsupported since ColdFusion 2018, the ColdFusion community has been warning against the use of such CF user-interface tags for more than a decade. 

Therefore, my suggestion is that you and your team knuckle down and replace the CFTABLE and CFCOL code once and for all. Besides future-proofing your code, this will be much less expensive than the solution you currently have in mind. I say that from experience.

Saeed, I think think there’s much hope for your wish.

1 - First, let me share that I could find no such code offered by anyone else. I worked for a couple of hours with an AI on some variants.

2 - Second, such code needs to accommodate that someone’s cfcol text attribute variables might simply be #mycolname# (like text=”#firstname#”), which is fine for cftable/cfcol. But once a cftable is changed to cf_table, now the compiler loses its ability to understand that that variable was indeed a column name in the query.

And sure, that could be corrected by adding the queryname as a prefix (in each variable in the text attribute value), but now that becomes far harder to rectify across hundreds of templates.

3 - The code I came up with works instead by a technique that simply requires that the pound signs for the variable names be escaped (text=”##firstname##”). 

If someone had just one or a few to do manually, that’s not bad. But for hundreds of occurrences, that would be really tedious. (And a regex doesn’t work well, because one may have the text attribute on the same line as a cfcol, or on another line--since CFML is flexible like that. A regex would have to work really hard. And even then the text attribute may have more than simple a variable name but could be a string with a variable within it, further complicating such a regex.) 

4 - Even then, both tags have multiple optional/required attributes. For any code to work “for everyone” it would have to accommodate those, which adds complication to the effort.

5 - As for hoping Adobe might “release the source code”, that source code would be java, which turns your CFML into java before Java would compile it to bytecode. Their java source would not help us (in my opinion). In any case, tou may want to email Adobe directly about your request for “source code”, at cfsup@adobe.com. They don’t tend to answer here.

6 - Does this mean you’ll face the prospect of a great deal of time to deal with it otherwise? Yes. It is sad that the tags were removed. They’d been deprecated for 10 years, and unsupported for 8. Once they’re removed, that’s it (unless you/others can somehow persuade them to relent).

7 - That said, you’re not “dead in the water”. You can still run them on CF2023, and it will get updates for 2 more years. It’s THEN that you’d be in trouble. But you could spend that time working to either change from using cftable/cfcol to using other techniques, or you could hope someone may come up with a custom tag that handles things better.

It’s entirely possible that someone else seeing this will want to spend time trying to solve this, working with their own AI. (And anyone offering any code publicly will of course then face the prospect that inevitably someone will present some scenarios where that code won’t work. So...it’s a slog...for someone--them or the folks dealing with the removal of the tags.) 

Hope that’s at least better than no answer here at all.