[coldbox-5.6.2] Keeping uniquness alive when similarities abound

When a module will work for something, it truly works wonderfully…but a modules is not only not always needed, there are some constraints (I think) that kinda make them less of a good pathway for me. I have a need to inherit from a core object for different product lines that are managed from within a central core or administrative code. The easiest way to manage similar functionalities is to just create new object versions that inherit from the core but only provide variants from the core as far as code. While some product lines will manage, for example, their simple user authentications, other products might need more information than the core does and inheriting the core services and just changing what needs to be changed seems a perfect way to do that.

However, I’m used to just letting CB and WB handle scouring the models directory and using sub-directories to differentiate logical domains of code…but in this case, it would be wonderful to use the same name for a class but in a different directory so I can also organize the code by product domain too.

/ models
/ core
userservices.cfc
/ product1
userservices.cfc ← inherits from core.userservices
/ product2
userservices.cfc ← inherits from core.userservices

But of course, automatic WB class scanning would balk right? I’ve never needed anything like this so I’m testing that theory next.

Is (a) this feasible…a way to have multiple cfc’s in separate sub-directories with the same names but somehow differentiated, (b) practical or has anyone had a similar need and though of a different way to handle this?

Originally I had though about multiple modules or even nested modules but I could not get inheritance to work that way so I assumed it likely require that I create composite variants and inject the core classes…which I suppose might be OK too…but it just seemed like more mess…not really sure so I figured I throw this out and see if something sticks.

Thanks for any insight.

Mike

  • I don’t recommend having two CFCs with the same name as that’s just confusing. Name them something useful like BaseUserService.cfc, product1UserServices .cfc, product2UserServices.cfc, etc
  • If you really want to name them the same thing, put an alias in the component metadata. Note, this requires you to flip the switch to auto-process model mappings on app init. It’s also more work than just naming them unique in the first place
  • You can have models in one module extend models in another module. You’d need to set up the module dependencies to load in the proper order and use the CF mappings created for each module to resolve the CFC path. extends=“moduleName.models.UserService”

To your individual points…

  • Completely agree
  • I have done that before but it was a while ago and I had forgotten. As this project grows I think trying to keep this straight would just bring about a confusion that I would prefer to avoid.
  • Ok…so in my first tests I had tried I had forgotten to consider the order the modules are being load so I think this is the approach I’m going to take. Every product will have it’s own class that inherits from the user module classes of the same name and every product too can be a module since we want to maintain some modularity as we grow the product lines.
    As always, thanks Brad. Always helping to look at things differently and providing the insights we need.

Mike