valueList / quotedValueList alternatives documentation

This came up in Query with cachedwithin breaks valuelist - #2 by andreas

I didn’t realise until now these were depreciated, I used these two all the time, so never visit the docs for it… as i know how to use them… and somehow missed them in the release docs (which with auto-updates even between versions are probably easy to miss these kind of changes. In CFDOCS this is not marked as depreciated.

The docs say ‘depreciated’ but don’t point to alternate functionality (because it’s not documented that i can see)… not sure the best way to do this so leaving it to the doc ninjas… but we need verbose docs on depreciated flag docs.

So these two items (valuelist/quotedvaluelist) need further docs to show what should be used, something that should be done with anything that is depreciated IMHO… should be 'this is depreciated - use {link to alternate} instead ’ or even directly put an example of replacement code (especially if no docs on how to do that)

QueryColumnData().toList(",") for instance could be used as example replacement code.

and then to replace QuotedValueList becomes :queryColumnData().toList(...).qualifyList(...) … would be great to just have a toQualifiedList() also… as now it’s becoming cumbersome and almost defeats the point of removing the other functionality as it overcomplicates a simple functionality IMHO.

This is also not documented in QueryColumnData and query.columnData which IMHO it should be especially if it is replacing something that’s been in the language for over 20 years… this would make it obvious for new devs (and old time devs that forgot this changed)

Firstly, it’s “deprecate”. “Depreciate” is a different, unrelated thing.

Secondly, on the docs page for valueList, the second sentence is

It is recommended to use QueryColumnData() instead.

For quotedValueList, it’s in the second “sentence” too:

this function is deprecated, use instead the function queryColumnData

I reckon that’s pretty clear.

It might be helpful to have examples on queryColumnData to produce the same as the supposedly deprecated functions, I agree. I hate people who say “you could do a pull request” when people as ask for help with stuff that’s missing in the docs, but this is usually when the person is looking in the docs cos they need the missing info cos they don’t know it. In this case you know the missing info, so perhaps you could add the examples? Or provide the code for the examples here, and someone else could sling them in. Dunno. That said, it’s pretty fundamental stuff, so not sure it needs spelling-out.

TBH, I just wouldn’t worry about it though. Sometimes the Lucee ppl have a brain fart and forget it’s not up to them what is and what is not deprecated in the CFML language. It’s not, it’s Adobe’s decision. Whilst valueList and quotedValueList are in CFML as prescribed by Adobe; Lucee won’t remove them. This is just empty posturing and overreach on the part of Lucee here.

Just to note, ValueList() and QuotedValueList() return values as a comma sep string while QueryColumnData() returns an array so a little more manipulation to get the exact same results using the latter (meaning can’t just drop it in as replacement)


I didn’t say the function `queryColumndata()’ was a complete 1:1 drop in replacement, but the code above IS a drop in replacement. You did address the point though that you can’t always (sometimes you can) just say ‘use this other function’, sometimes you need to put code there, especially when people (as in this case) will find valuList and QuotedValueList in THOUSANDS of examples on the internet and ALSO in decades of previous documentation in which search engines constantly refer.

Having this in the docs makes the learning curve much easier for people not as familiar and reduces the need to ask questions on slack/forums/SO… and of course better productivity.

Of course also when it’s fully depreciated being able to use the code that is put in the docs as a helper output for the error message in lucee itself could prove beneficial if it is able to be standardised.

I’m happy to update docs, but wonder if there is any documentation guidelines to put below ‘depreciated’ the code that is to replace it? (just want to be consistant) and happy to update more docs as I’ve got a wishlist of updates. (and have talked to @Zackster about doing so, but got busy, so now revisiting)