Use SOSL to generate bindings
jjulicher opened this issue · comments
Hi Andy
Great stuff.
One feature that might be of use instead of using custom metadata you could you SOSL to find your classes that extend di_module.
List<List<SObject>> results = [FIND ' extends di_Module' IN ALL FIELDS RETURNING ApexClass (Id, Name)];
for(SObject result : results.get(0)){
System.debug(result.get('Name'));
}
It would be a relatively quick query and you could also cache the data in the platform cache.
I was contemplating using this to create my own annotations framework for DI but I thought it might be too temperamental and require too much processing time for the initial setup/config.
Although I'm not sure how this would work with unlocked packages if the code would be searchable or not.
@jjulicher -- that is a very interesting thought.
Just curious, have you used SOSL to examine ApexClasses in any other use cases? Any limitations in the approach? Any impacts with users of different license types executing?
@ImJohnMDaniel
I hadn't had a chance to fully explore the limitations of the approach as I left the previous company before I got a chance.
Looking at it I can see that as a normal user you wouldn't be able to query ApexClass so it becomes a bit of bust as of now. thanks for pointing that out.
@jjulicher Understood.
I will say that I was not previously aware that SOSL could interrogate the content of the ApexClass like you showed above. While, as you say, it may not be the best fit for this project, I will definitely use that technique on some other projects that I have been thinking about.
So for that alone, thank you very much for bringing this up!
Cheers!
@jjulicher wow mind blown! SOSL over Apex! 👍 Thanks for sharing!