Lucee NOT DEAD

:100:

2 Likes

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! :smiley:

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.

I agree, which is why I never did that, which makes your entire first paragraph a red herring.

Which is precisely what .cfs vs .cfm accomplishes as well.

As for .cfc files, are you loading them directly from the browser?

https://localhost/example.cfc

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!

Ahem…

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.

handlers/Home.cfc

function about( event, rc, prc ) {
  prc.employees = employService.listAll();
  event.setView( 'home/about' );
}

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)

1 Like

My point throughout this entire topic has been and still is that there is no logical reason for tag syntax other than for HTML presentation.

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 :slight_smile:

3 Likes

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.

I am not holding my breath!

Do you by any chance use ColdBox? And if so, is that why you put the whole kitchen sink into .cfcs? :grinning:

(Related topic: Does MVC discourage OOP?)

Sounds like what you’re doing violates Separation of Concerns which makes your code more difficult to maintain.

1 Like

Ah well then at the very least, ColdBox’s index.cfm can now be replaced with an empty index.cfs! Unfortunately not much benefit there haha, but .cfs is ideal for “snobby” cfscript-loving OOP devs who remain on the fence about MVC. :stuck_out_tongue_closed_eyes:

Have to say, though, I’m with @JenniferHerrera re: the ubiquitous and unprofessional religious messaging from Ortus. That makes me even more hesitant to give it a try.

Lol, unfortunately I don’t think Adobe ever supported it :slight_smile:

To be frank, I have nothing against you or Jennifer, but I find the repeated discussion of Religious preferences as valid reason to not use a library intolerant and bigoted. For goodness sakes, it’s 2022. If you seriously can’t bring yourself to use a bit of code written by someone who’s religion you disagree with, you need to do some soul searching. I’d love to sit and chat about any of these topics if we ever run into each other at a CF conference (I’ll be in person at CF Summit and Into The Box this year!) but these public forums are not the place to try and throw shade at people’s religious views.

I’ve demonstrated zero criticism of religious preferences. I’m simply saying a business website and its GitHub repository – public forums – are not appropriate places for bible quotes and religious dogma. In 2022 that gives the appearance of nutso extremism. If you still don’t recognize how unprofessional that is, then you’re the one in need of introspection. I’ve read that 90% of Americans are some form of Christian, and I tolerate that because most of them are not constantly shoving it in my face. It’s a legit reason (one of many) why I’m not interested in ColdBox, and why Ortus has likely failed to attract others who feel the same way (and don’t even bother saying anything about it because they probably think it’s just easier moving on to Node.js). These issues – which are relevant to the original Lucee NOT DEAD topic because of the potential negative publicity factor since ColdBox is the de facto framework for Lucee – are certainly worthy of public discourse.

Just to be clear. I don’t put the whole kitchen sink into .cfcs and I use templating and cfinclude (inside templates) myself. What I was trying to say is that I wouldn’t use inlcudes in scripts like here:

But that’s just my own personal choice :smile:

Reading this thread, I am aware that the powers that be prefer scripting but CFML coding is the game when your legacy site uses it. In these cases you make the best of it and apply best practices coding regardless of the format method. I don’t write code to impress critics, I write code to be efficient and future supportable. Some of the spaghetti I have taken responsibility compels me to take a walk around the room sometimes, but that’s true of PHP, .NET, Perl, python, and whatever else I work on!

I like CFML honestly, and I am very good at it, I see no need to re-write old code just to do it.

Gets me wondering if there is a conversion utility to go from CFML to CFSL, but I am sure this topic has been covered elsewhere.

Yes! http://cfscript.me

It’s not perfect, but it can get you pretty close.

2 Likes

After I made my post I found a few were out there. I will experiment and over time transition. But I have thousands of lines of code and a lot of web applications my company supports…could take years.

Ironically you presented two reasons to do so, “efficient and future supportable”. The benefits are a Catch-22 because you don’t fully realize how awesome script syntax is compared to tags until you’re actually comfortable with it on a daily basis.

I still have the old CFML in my legacy code, too. I see the need to bring it into the 21st century, but I don’t have the incentive as long as it’s working, nothing needs to change, and no one’s paying me to upgrade it. That’s also one of the practical reasons why I haven’t migrated all my code to Node.js.

However, as soon as something does need to be fixed or features added, when appropriate I include the migration to cfscript as part of the todo list, but usually limited to the portions that are affected by the necessary code changes, unless I’m feeling really productive and have the luxury of extra time.

It’s like when new houses are developed, in most municipalities the developer is required to add a sidewalk if there isn’t one already. The grandfather clause applies to old houses, but adding a sidewalk still looks nicer and makes it easier for others to navigate.

Taking this silly analogy to the emoji level:

CFML is to cfscript as :derelict_house: is to :house_with_garden:. :laughing:

Argh … cringing at “CFSL”. :grimacing:

I haven’t used any conversion tools (I was previously aware of cfscript.me and it failed to deliver on my very first, very simple attempt), but CFScriptify is another option, though also incomplete.

@carehart back in 2018 shared his list of cfscript resources.

@AdamCameron published documentation on GitHub and it has 12 other contributors.

@tonyjunkes published examples also on GitHub.

Everybody knows that docs.lucee.org needs updating (sounds like that’s coming with Lucee 6), but there are already cfscript examples there, and more at cfdocs.org.

If those don’t answer any specific questions you might have, post the topic in this here forum and I will reply if I know the answer!

Well, nice to see that there are people still supporting the old cfml. When I bring in new programmers I encourage them to script rather than CFML, or at least be able to support either but they all need to know how to use CFML for legacy support. I have web applications that were first launched in 1996 that have been updated and improved since then but some of the core is original CFML. I have been running CF since the beginning practically.