In ACF 2023, what is the best way to read in a CSV? Googling I see Ben Nadel's CSV parser come up a lot. And mention of reading a CSV via cfhttp. Is there any better approach in 2024 I should consider?

I've been pleased with this library https://github.com/cfsimplicity/spreadsheet-cfml

@davequested fwiw, we use Ben's thing. The most recent version of it though; older versions had issues. It works fine, for what we need.

Thanks @Adam Cameron, this is the one I'm playing with: https://www.bennadel.com/blog/4037-modernizing-my-csv-comma-separated-value-parser-in-lucee-cfml-5-3-7-47.htm Kudos to @ben as always.

This ain't the job of the core language. It's a library. Plus CFML already runs on Java, and it's a solved problem. https://www.baeldung.com/java-csv-file-array#opencsv At most there could perhaps be a CFML wrapper on that for ppl without the... erm... "preparedness" to wrap a few Java expressions in a CFC. There'd be merit in it... everyone's wrapper would be a variation on the same theme, so might as well do it once and share it.

Everything is possible with libraries mate. We do plenty of that. But I'm paying a hefty license to do the heavy lifting for me. If it was native, tested, performant and one line to implement, that would be way more awesome than down in the weeds cobbling together some java methods / third party libraries. I don't really want to keep libraries up to date, deal with breaking changes, etc. I'd rather just call CSVRead() and move on with my life. Isn't that the purpose / difference of an application server such as Adobe ColdFusion? For what it's worth, I'd prefer they spent time on this type of functionality than cfform, cfinput, etc.

I despair. CFMLers are so frickin lazy / needy. If they can't do it in 5min with a

<cfoutput>

and a

<cfif>

, they go "waaaah". It would take a coupla hours for someone to knock out v1.0 of a wrapper for that Baeldung example, and get it up on to ForgeBox. All singing all dancing? Nope, that would come with later efforts where ppl go "I need it to do this too, so I'll add that bit". This is not a good use of Adobe's time. In turn, it's not good for the CFML community. I'd prefer they spent their time doing stuff we can't already do for ourselves. EGs: We can't sort out the scope cascade mess that is being exploited ATM. So good on them for addressing that. We needed them to create

()=>{}

syntax (or deal with other syntactical glitches like not being about to do an IIFE for years). Or implement the rest and spread operators. This was all good, worthwhile work they've done in the last few releases, and really makes for much more mature CFML code and a better experience in doing our jobs. Maybe it'd be a thing to have a block-like syntax on function calls like Ruby can do? Maybe being able to implement an iterable interface on a CFC-based collection type so it will work with CF's native looping structures? I reckon CFMLers might like to have traits / mix-ins as first class citizens. We as CFML devs _can't do that_: it requires Adobe to do it. Being able to use

queryExecute

for other text-based data querying languages than SQL? And apply the same interface to it as with SQL retrieval. Nice. They'd probably also like tighter Java-type integration into the language... it's a bit clunky ATM with

createObject

and

javaCast

(I think there improved stuff in that area recently, but it still makes for grim code, last time I checked). It's nowhere near as seamless as with more thoughtfully designed JVM languages like Groovy. Blimey having uniform and explicit

null

support (along the lines of what Lucee does. Kinda) is something CFMLers can't do.

Isn't that the purpose / difference of an application server such as Adobe ColdFusion?

No. Cos yer talking about CFML, not CF (where CF is the app server). I personally have very little interest in the app server side of CF, but I would "get" if Adobe wanted to invest time there. When it comes to CFML they should focus on stuff CFMLers can't already do, if they were only to pull their heads out of their arses, and apply themselves a bit.

You're totally right. serializeJSON() and deserializeJSON() was a complete waste of time. No one used it, definitely should have been a library that one.

Haha, used them just today in fact. However also would have been easy to implement as a lib wrapping existing Java work. I mean... shit... it's all Macromedia did ;-) Also: I think it took Macromedia/Adobe a very long time to get those functions working stabley without all the caveats of strings like "No" being converted to

true

and the like (I'm not making that up, that was actually a bug that someone encountered... they had a client called Dr No, I guess). If they were in the community, they woulda been sorted out much more quickly as we'd've been enabled. Obviously something that is already in the language is... well... there now. Handy. That's not to say every easy thing that you can't be arsed rolling yer own one of ought also be thrown into the sink.

> That's not to say every easy thing that you can't be arsed rolling yer own one of ought also be thrown into the sink Agreed. Careful consideration for sure. But CSV is a mainstay transport mechanism for moving data between systems. Seems having this native would be a no-brainer for me. Anyway, agree to disagree. Ben's efforts are working beautifully, thanks Ben. Classic re: PHP.

Chortle... I note PHP does it natively: https://www.php.net/manual/en/function.fgetcsv.php. I would not, however, base language design decisions on what PHP does.

Good chatting. Time to scope some unscoped variables...

bahahahahaha. Jesus. I am glad I am not on CF...

You mean ACF? Lucee doesn't search implicit scopes?

(we have screeds of unscoped variables-scope usage in our CFCs though... kinda encouraged in CFWheels. Ugh). Yeah we're Lucee not CF. Probably has the same issue. Christ I'm gonna have to check now.

You should, post in the main channel your findings

Well I say "I'm gonna have to...". I mean "someone on my team is going to get an unenviable task of ~" #bossPerks