Lucee NOT DEAD

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.