The Problem with getMetadata() and annotations (and possible solutions)

However, annotations don't inherit which causes a problem if you're using a extension to keep generated and custom code separate. Here's the problem and some possible solutions (as always, input appreciated!) . . .

A good rule of thumb is never to hand edit any generated code, so if you want to generate a UserService.cfc but still want to be able to add custom code, one of the most useful patterns is to generate GeneratedUserService.cfc, then you can put any custom code into UserService.cfc which extends GeneratedUserService.cfc. With this pattern, you can regenerate GeneratedUserService.cfc at any time without messing up any custom code you may have written in UserService.cfc.

However, if you're using annotations, they don't inherit. Try putting cfcomponent Title="whatever" into GeneratedUserService.cfc, create a UserService.cfc that extends the generated user service, instantiate it and then try calling getMetadata(UserService).Title - it'll error as the Title annotation doesn't inherit.

So, now if you want to annotate the title or db table or whatever for UserService, you're going to have to put that annotation into the user editable UserService.cfc. You could write some kind of text munger to do a "protected blocks" style transformation of the UserService, just editing the cfcomponent and any cfproperty tags on re-generation. It isn't that technically difficult, but I'm not a huge fan of the approach. For now I'm thinking the least bad solution would be to actively re-generate both the GeneratedUserService.cfc (with the code) and the UserService.cfc, making the UserService look something like this:

basically using class based mixins to mix in any custom methods. Not ideal, but not too bad.

Oh, and why don't I just dispense with the inheritance altogether if I'm using mixins to put the custom code into a different file? Because if you want to change the implementation of a method, with extension, you can write another getWhatever() or validateSomething() method. If you use class based mixins and the generated method exists, it'll throw an error that the method already exists. Of course, you could fix this with some clever object based mixin coding that replaced methods one at a time, but it'd make the framework more complex and potentially have some runtime performance implications as well . . .

Any thoughts? How would/do you handle this?