<https://download.lucee.org/#37C61C0A-5D7E-4256-85...
# lucee
a
https://download.lucee.org/#37C61C0A-5D7E-4256-8572639BE0CF5838 The sum-total of the docs for this seems to be; "Extension for ESAPI functions". Are there any other docs? Which functions in CFML are "ESAPI functions" Do I need to go through docs.lucee.org for all matches of "*Requires Extension:* ESAPI extension"? I tried to find a section in there covering "ESAPI functions", but if it's there, it's eluding both me and Google. If indeed I am not missing something (entirely likely: this is the first time I've had to deal with a Lucee extension), could we get those docs augmented to list which functions it provides for? Even if the docs are maintained somewhere else (like at its source code repo on GitHub?) then just a link would suffice. I mean I could guess. But I really shouldn't have to, yeah?
or maybe better, https://github.com/lucee/extension-esapi/blob/master/source/fld/function.fld although I do agree, that you shouldn't have to guess or jump through hoops to track down.
a
18 items on both those pages. Which is slightly at odds with the 24 google claims are documented as being part of that extension. Obvs (?) the code is the source of truth though. I will try to find time to see what the other six are google mentions and see why they're not in the code (or if Google's doubling up or whatevs... I didn't check the values, just the count)
I also note that https://github.com/lucee/extension-esapi/blob/master/README.md points back to https://docs.lucee.org/categories/esapi.html, but the latter lists 21 functions. So Google found 24 in the docs. The docs for the extension point back to a Lucee docs page listing 21. And there's only 18 in the code. I think if the entry in Lucee admin included a link back to the github project, and the reality of the github project was reflected in the Lucee docs... it'd be fine.
(and it should be thus for all the extensions that cover parts of native CFML, I'm not just talking about this particular extension here. This is just the one causing me grief right now)
j
hmm, that might get complicated when you start considering that normal file/directory functions might rely on, say, the s3 extension, or some other extension based on the path. (maybe the docs already deal with this in some way, though--i haven't checked.)
a
Sure, 100%. I was not suggesting a template approach for "the way to document extensions". You do point out that the docs need to go both ways, eg: for
fileRead
the docs need to be clear and specific "if you wanna use this on s3, you need the extension [link to extension]", and for the docs for the extension, "adds s3 support to [list of CFML functions / tags here]". And if there's something else that needs documenting too... then document that too.