I have a CF10 application that is being migrated to Lucee 5. Nothing in this app is under any tests so manual testing and client testing are the only way forward. The major differences that I’ve found are obviously Application.cfm => Application.cfc and the way PDF’s are handled.
All the code for the printing PDF’s is in the database but lucee needs a different config and CSS for working compared to CF10.
I’m trying to keep the code base the same and on that basis would it be better to query the system (system.coldfusion.ProductName) and provide the print files based on that, rather than building the lucee codebase with changes?
Two thoughts, Tony: one a question and one a tip. First, can you clarify what difference you’re referring to about application.cfm vs cfc? Each engine does support both approaches.
Second, as for testing by the server var, yes, that can be helpful when there’s some compiler difference due to engine differences (or also when due to different engine versions) . As you may know, you’d be able to do a cfinclude within the if or else test, where each could include a different file having code that would work for each of the different engines/versions. This works because cfinclude is a runtime rather than compile-time directive.
Thanks Charlie - That helped me decide on the direction forwards. I am aiming for the smallest difference between the ACF and Lucee code and that is having the same code base. Using cfinclude makes sense with a cfif statement. From this it follows that I can migrate the ACF code to Application.cfc before I do the change over.
This means I can run one master/main code branch rather than a separate one for Lucee.
With regards to what I was referring to with cfm vs cfc, I just assumed that this is the preferred method nowadays.
Hi Zackster - Yes thanks for reminding me of this. I should be so lucky to have any functions at all with this code. It’s quite well structured though and divided into sensible pages so the logic is reasonably easy to follow.
I don’t want to go delving in to do changes though. Once the code is migrated I’ll start to open seams and break apart areas to replace with more up to date coding.
Thanks, Tony, for the update and kind regards. As for your last point, yes most would FAVOR a move to app.cfc.
But I was referring to your having said, “The major differences that I’ve found are obviously Application.cfm => Application.cfc”. To be clear, you could start/could have started that transition on your cf10, which may be helpful in making only “one change” at a time. Just something to consider, not an admonishment.
I think as you already have the PDF formatting in data that keeping a separate db version for Lucee that you can test independently is the way to go, with the code remaining unaltered.
Versions of the PDF rendering in Lucee can be quite different, so I’d make sure your dev/staging environment(s) are the same as live, or you might get an unwelcome surprise.
The PDF rendering can be up- or downgraded independently of the Lucee version (for the most part) so it’s not too hard to keep things stable. Bear in mind a bug fix that is perfectly valid can break your formatting if you have already adjusted your HTML/CSS to cope with the anomaly, so don’t rush to upgrade the PDF component without testing first. I say this based on hard-won experience!
I agree - another table with the lucee pdf code is not a problem and it means that all can be tested before deploy into App Engine. AFAIK the PDF engine on Lucee only handles up to CSS2 but I might be wrong. I can get the result that I need from that.
It’s good to have one code base and makes working with Git much easier. Once I’ve moved the code to App Engine there is no further need for CF.