Any CommandBox experts around? I was hoping to use DocBox from a Commandbox commandline on a codebase involving static methods. I reported an issue with getComponentMetaData omitting static methods and properties a while back (https://luceeserver.atlassian.net/browse/LDEV-3362) and it was fixed in Lucee 6.0.0.144, so I was hoping that a hearty config set server.defaults.app.cfengine=lucee@6.0.0-SNAPSHOT+14 and CommandBox restart would lead to CommandBox itself using Lucee ´6 - but as the docbox result is still very empty for anything static, I assume that this config setting only applies to servers started from within CommandBox. Is there some way to change the very engine CommandBox itself is using in order to use DocBox on static methods and properties?

@Markus Wollny I wouldn't use any of the lucee 6 builds on forgebox, they're very old and I don't even know if they work. Only a few lucee 6 builds made it onto ForgeBox before LAS stopped publishing them for... reasons.

Ok, thanks for the info. I do have a DocBox recipe that just does some find&replace on the code before and after, so that's still a viable workaround. I was hoping that there had been some progress on that front, as it's fairly ugly.

In lucee 5.3, getComponentMetaData/getMetaData includes statics functions from 5.3.9.59-SNAPSHOT. But it still misses the private and package static functions. I've created a seperate ticket for this https://luceeserver.atlassian.net/browse/LDEV-3875

Glad to hear some of that made it into 5.3.9. In the mean time, maybe you can work with @mborn (our current DocBox expert) on getting backwards compat support added.

I think you're right @bdw429s but it's been about a year since I checked. I think docbox itself used

static

properties for a while, until we discovered it was breaking in Lucee... so we changed to standard component

property name=

syntax.

Yeah, a lot of older libs used to use "fake" static vars that were really just variables.static.

I'll create a ticket to run

static

through its paces. We may just need a test or two to get it working on Lucee 5.3.9+.

But basically, docbox needs updated to read the new proper static metadata out of CFCs and present it to the Strategy in charge of rendering.

In my use case I haven't had the need to take care about static properties yet, so all I did so far was to work around the problem with static methods. The approach requires a locally checked out git repository in a committed state. Here's my recipe template for a file docgen.boxr:

# quick replace of static methods with a prefixed method name
#directoryList path=.\cfc listInfo="path" filter="*.cfc" type="file" recurse="true" | #arrayToList | forEach command="sed --file \${item} 's~static(.*?)function (\S)~\1 function staticFuncZZZ\2~gi' > \${item}" delimiter=","

# generate the docs
docbox generate source=.\cfc mapping=[packageName] strategy-outputDir=./doc strategy-projectTitle="My Title"

# reset the changes made by initial replace
!git restore --source=HEAD --staged --worktree -- .\cfc

#directoryList path=.\doc listInfo="path" type="file" filter="*.html" recurse="true"| #arrayToList | forEach command="sed --file \${item} 's~staticFuncZZZ~[static] ~gi' > \${item}" delimiter=","

If I had to extend that to care about static properties, it wouldn't be much of an issue, I guess. The biggest problem here is that I temporarily mess up the actual source code and rely on git to revert that mess, so if a user is not careful to never run this on the same working directory he/she is currently working on, there's going to be a painful mistake some day. That's why I recommend doing DocBox runs in a separate hierarchy at the moment. And this imposes a certain additional hassle that would be nice to get rid of. Attached is an example what this looks like in my DocBox output. As I'm using a simple search&replace strategy, there's not much sophistication behind it. One could argue however, that if DocBox would do the static processing on its own, it might be preferrable to have static methods (and properties) additionally grouped in tabs in the Method Summary block - so in the overview we'd see a default tab "All Methods" with static methods prefixed "static" in some way and one or two additional filtered tabs labeled "Instance Methods" (for non-static) and "Static Methods" (or maybe better "Concrete Methods" ?). If tabs are too much of a hassle, grouping all static methods to one end of the method list may be another option.

@Markus Wollny nice work with the

directoryList  | #arrayToList | forEach

magic 🙂

Thanks for pointing out tokenreplace, but for me sed is the go-to tool for any string processing, as there is only so much one can accomplish without regex. For the first line there is just no way for it to work without regex, so tokenreplace would only be an option for the last line replacing the staticFuncZZZ token with [static] and I prefer the Unix philosophy of keeping a clean API by sticking to a limited set of tools each of which does one job extremely well. Having said that, I cannot overexpress my gratitude to Commandbox for providing my Windows based office machine with sed, grep and all the other helpful commandline imps I so love on my Debian servers.

@Markus Wollny You're welcome 😊 I agree, tools like sed and grep are super useful on Windows. What's cool is that the CommandBox version of

sed

is powered by CFML's

reReplace()

functions in the background 💪