Luis, have you considered making scan locations search recursively?
I'm not sure what the original logic was, but I wonder if it would be
more intuitive for them to work that way since we've had a handful of
people on the list who have assumed that would be the behavior.
I have another alterior motive for asking If we did that, I would
change my mapDirectory() out and just make my CFC folder be the scan
location. I have over 200 models and my app takes SEVERAL minutes to
start up on my slower workstation after I restart CF due to all the up
front class creation caused by getComponentMetaData(). (Reinits
aren't affected quite as much, since Java stores the classes in perm
gen, but all the mappings are created up front again) I would rather
use scan locations so the mappings were discovered as needed (lazy
loaded) rather than all at once at app startup.
My goal is to not have to create mappings for each model, or scan
locations for each directory.
Let me know if I'm not accounting for something that would keep that
from being possible. (like performance)
Yea this is a tricky one. As the original intent was for scan locations to hide the packages and just just reques objects inside the package with dot notation.
If we change it's behavior to recursively search it might be incredibly slow in order to traverse every structure.
Hmm, I had never thought about requesting objects with a partial path. I guess the use-case for that would be if I had the following model: "com.mycompany.orders.orderService" an I added a scan location of "com.mycompany", then I could ask for "orders.orderService" and it would find it. I've read the docs on scan locations several times and had never quite put that together. As interesting as it is, I don't think, I'd ever use it. I'd rather just ask for "orderService" all by itself.
All that aside, that might make this a big trickier, but not impossible. I think performance issues could be easily worked around by simply caching a recursive query of the files in each scan location at the time the scan location is registered. Loop over the list and add an additional column called depth which would be calculated off of listLen(path,"/"). Then locateInstance() could be changed to a maxrows=1 query of queries on each scan location's list of files where the end of the path matched what you were looking for. Ordering by your depth column ascending would ensure that root of the scan location was given precedence over sub directories.
Since you'd only hit the hard disk once when you registered the scan locations, the only performance would be the Q of Q, which should be pretty darn fast (and would only need to be executed one per model anyway since the mapping is cached after the first time).
Can we clarify the differences the. Between mapdirectory and scan locations. Scan locations is how coldbox model conventions work meaning it points to the model folder and you jut refer objects from that directory down. That has to remain also.
If we did that, I would