Extra characters in closing tags are not a problem if you have autocomplete. You may be right on line breaks but we’re getting into the odd few milliseconds of gain. And as for “that’s all I’ve ever done”, you’re putting words in my mouth; CFML started out in a particular way and I happen to still use it; I use other scripted languages too so the format is familiar. I just happen to prefer CFML and there’s no technical reason to avoid it.
None of that explains your point about tags being an embarrassment or inappropriate - you’re simply saying there’s a minor efficiency gain, possibly slightly higher for people who script by routine. Suspect we must respectfully agree to disagree here.
We can certainly respect each other, but I maintain that Lucee’s longevity depends on attracting new developers, and though that ship sailed ages ago and maybe it doesn’t matter as long as we like what we’re using and don’t care about what happens after we’re all dead and gone, script syntax nevertheless gives Lucee better odds for its future.
Well first of all the whole point of .cfs is to not use <cfscript>.
You could simply include a .cfs file like any other file.
However, the logical best practice is the other way around, where the .cfs script file is loaded in the browser or CLI, etc, and it executes the business logic, probably instantiates some objects from .cfc, and then if web-based presentation is needed, finally includes the .cfm template. Notice my emphasis on script vs template and how those two have very different responsibilities. This ensures separation of biz vs pres and also enforces script syntax for the biz logic.
And ideally all .cfm template files should be outside of the web root.
Over-simplified example:
https://localhost/test.cfs
str = testme();
include "/mapped-cfm-folder/test.cfm";
function testme() {
return ".cfs files active without <cfscript> and using include to load .cfm templates!";
}
If I come across old code using includes I wouldn’t use it within cfscript, it just doesn’t feel right to me. I’d rather move that code into a component that returns its content as string or variables. There might be use cases you may need to use cfinclude, but I still didn’t find any that can’t be achieved with components/udfs
To be clear, when I say .cfm template – intended for web presentation (aka View in MVC parlance) – I’m talking about the CFML being limited to presentation tags such as <cfoutput> and <cfloop> surrounded by HTML, CSS, and JavaScript. That is the only use case when tag syntax makes sense because of how well it flows with HTML.
You’re not saying you’d move all that into a .cfc component aka class file intended for object instantiation, are you?
I am trying to wrap my head around this, as to what advantage I gain by doing this
And ideally all .cfm template files should be outside of the web root.
Over-simplified example:
**`https://localhost/test.cfs`**
str = testme();
include "/mapped-cfm-folder/test.cfm";
function testme() {
return ".cfs files active without <cfscript> and using include to load .cfm templates!";
}
I am a huge fan of build your own adventure, and I love templates more than I like code. I am just trying to figure out other than your coding standard what is to be gained by placing all script, inside a file, that basically is all script. Most ColdFusion applications are a mix of tag soup and script scribble.
Unless of course you are doing something like this, in which case share the code:
@LionelHolt right now I’m doing exactly that , and I use cftags in various components using tag islands for that exact reason you’ve mentioned. To me it feels better wrapping that stuff (also using savecontent) in Components and returning all the strings in variables to the caller. But others would do it differently for sure. I just like using these tag islands because it combines cfscript and cftags perfectly. Tag islands is just like the cfscript tag in cftags but with an inverted direction from script to tag perspective. But that all,of course is my personal approach. Not saying anybody shouldn’t use cfinclude. I also use some cfinclude like you in some cases, but I just don’t use it in components/cfscript.
Which is precisely what we all should have stopped doing a couple decades ago when it became painfully obvious how easy that is for mixing business logic with presentation, and tag syntax for biz logic makes zero sense. I’ve already said that this is the advantage of separating .cfs files (business logic) from .cfm (presentation), and I don’t know how to be more clear than that. Also I’m tired of having to type <cfscript> so dang often!
I don’t think it’s quite fair to conflate script with so-called “business logic”. Firstly, that phrase is a little ambiguous as to what it even means. And secondly, just because you write something in script doesn’t make it business logic, or vice versa. I could write an entire web app in script and I could write an entire web app in tags and that has no bearing on whether I’ve mixed presentation layers with my model (data access, services/beans which provide data and behavior). I use an MVC framework to help keep separation of concerns. And ColdBox doesn’t care one bit whether you use tags or script in your CFCs. (My personal rule of thumb is I use tags ONLY when templating HTML [and sometimes SQL] and everything else is script for my personal readability. )
That’s the other thing-- the cfs file format is interesting, but I’d honestly never use it. I use stand alone CF templates for views and layouts-- that’s it.
Controllers are CFCs
Services are CFCs
DAOs are CFCs
Beans are CFCs
Configs are stored in CFCs (in ColdBox)
URL routes are stored in CFCs (in ColdBox)
Interceptors are CFCs (in ColdBox)
Heck, even my Application.cfc is a CFC!
And CFC’s already support a pure-script syntax. After all the bellowing about people not embracing OOP-- I’d argue that lack of object orientation is the only thing providing a purpose for a cfs file at the moment.
There is no “sense”, common or otherwise to “business logic”. If there was a practical common mathematical model then the world might be a very different if not boring place.
What I would consider a boring, useless redundant function and borderline “make work” others thrive upon and set up Ted talks about.
I am specifically asking, what do I gain, if I place all of my script inside .SCRIPTFILE, and then all my tags inside .TAGFILE. Now I have to make further code adjustments for?? What am I gaining by doing this? I understand what can be gained by MCV, and I fully love template languages such as Smarty, but when I place BUSINESSLOGIC.SCRIPT and then i have to use BUSINESSLOGIC.TAG all inside THEAPPFILE which becomes something like
INCLUDE BUSINESSLOGIC.TAG
if ELSE
INCLUDE BUSINESSLOGIC.SCRIPT
IF Else
INCLUDE BUSINESSLOGIC.TAG2
CASE ELSE
so on and so forth
Now sure some apps will dynamically call and include other files as needed, but again, What is the gain if I have to pour through 100 lines of code only to find yet another 500 lines of included items, only to locate that 1 file, that had a missing close, or if I just put it all in MYAPPFILE1.CFM i would have found it with the linter, debugger or god forbid it would have been suggested and fixed before I saved it.
If there is a better way, please, tell me, but when it comes to decades of “business logic”, i have found that nothing is actually “logical” and Spok would hate all of humanity.
Like that? Seems unlikely, so maybe now you finally understand what I’m saying? If not, I might have to give up on trying to explain this further and just be glad that .cfs support was added. Must be some good reason for that decision.
Also, I never claimed to be an expert on OOP. I specifically said I still have much to learn!
Who said what is sort of beside the point. I just wanted to make it clear the syntax you use has no bearing on whether your logic is presentation or data related.
No. MVC frameworks provide a routing mechanism to map URLs to an event handler. Most of them run through a front controller design pattern. Both ColdBox and FW/1 for example, route all traffic through an empty index.cfm file (which is really just there to satisfy the CF engine) and they highjack the processing of the request from inside the Application.cfc’s onRequest() method, parsing the route from the CGI’s path info and deciding what handler/controller will be in charge of talking to the model and rendering the reponse.
So, a ColdBox or FW/1 request could look like so:
site.com/home/about
which gets rewritten on the web server to
site.com/index.cfm/home/about
When the request comes in, the onRequest() method in the Application.cfc passes control to ColdBox.
public boolean function onRequestStart( String targetPage ){
application.cbBootstrap.onRequestStart( arguments.targetPage );
return true;
}
And, once inside the framework, If using the default convention based routing, the about() method inside of the handlers/Home.cfc would be executed which would gather data and set up the view for rendering.
I hate too get too off in the MVC weeds, and ColdBox can an entire site of docs which dig further into this, but hopefully that help explain the basic flow of a modern CFML MVC app and how the requests run without ever touching any .cfm files other than views/home/about.cfm (which was setup in the handler)
Sure, that’s your opinion. It’s also my opinion, but pushing it is as useful as discussing religion or tabs vs spaces, lol. The objective benefits have been stated
25% less code (by my estimations)
More familiar for on-boarding non-CF devs
The rest comes down to what people prefer to read and write. I totally encourage you to use script examples in any online docs- I certainly do. But there are diminishing returns in trying to convince others in the community
Most of the “Books” on ColdFusion written back when Dinosaurs roamed the earth and Bill Gates was busy making a buggy OS vs trying to fund making bugs are completely written in tags.
As for tags, nope, failed logic.
Its like saying, If you cant use a command line you shouldnt be allowed to drive.
If it is simply our opinion, then surely someone can provide a logical reason – not solely their preference (simply because that’s what they originally learned before script syntax existed) – for using tag syntax aka “markup” for non-presentational code.
, and I use cftags in various components using tag islands for that exact reason you’ve mentioned. To me it feels better wrapping that stuff (also using savecontent) in Components and returning all the strings in variables to the caller. But others would do it differently for sure. I just like using these tag islands because it combines cfscript and cftags perfectly. Tag islands is just like the cfscript tag in cftags but with an inverted direction from script to tag perspective. But that all,of course is my personal approach. Not saying anybody shouldn’t use cfinclude. I also use some cfinclude like you in some cases, but I just don’t use it in components/cfscript.
