ok…so I have a simple function that takes a CGI variable, massages it and then stuffs some value into application storage. That function is called on appInit and then onRequestStart checks to see if the application storage has that value and if not, get’s it…this way, it runs once at start up and if something corrupts the storage, every request will check for it and make sure it exists.
Technically, I can easily see a way to do this as an application helper function, plugin or a “system-level” interceptor.onRequestCapture().
As I have posted before…I get interceptor happy sometimes so I’m always leery about this…
If I make it part of an interceptor, not only do I not need the function, but no developer after me ever has to worry about where it comes from, the value they need will always be there.
The function is certainly easy (this was the first way I did it), but on the downside, unless you use some crazy function naming convention, it’s hard to tell where the function might exist (should another developer later need to modify it) AND, you have to remember to put it into your configured onrequest start handler. Also, unless I do this as part of the application helper, it may not be globally available and there might be a need to use it later (there is an optional param that prevents the creation of the application storage variable so it can be used more generically).
The plugin…well at first I thought that might be silly, but…I could create a system-plugin and provide all sorts of system wide functions AND it then easily becomes inject-able…and you just never now how you might want to share any or all of those global system functions.
Thoughts on a best practice or at least some experience?
Documentation will always satisfy any developer, so if your application is well documented, both in and out of code will always make it easier for another developer to pick it up.
On the interceptor side, yes I too would use the AppInit interception point to do what your doing, as this would give you access to the ApplicationStorage plugin to do its magic as well if the need arises you also have the framework to do other things at app init stage to some degree.
But aside from that my first instinct is go with what suits your development now, and just document both the application and code and any developer can pick up what your application is doing.
all of your suggestions would be best practice. your application or even your enterprise model will drive the patterns to use.
is this method living in a module? is it only used in one application? will it keep things de-coupled? does it need to be implicitly or explicitly set? is it part of the skeleton for all of your applications?
All good comments…Andrew, I’d love to take those questions and associate them with CB elements / methodologies / etc. The only problem I’m going to have is the developers I’ll be working with me are foolishly going to, at least initially, follow my lead and are likely to ask me the same question…since this is client work, I really don’t want them to be spending time worrying or investigating in the way I am now.
One comment / maybe correction. In my first pass, I was not using onappinit the interception point, I was using a function named onAppInit (kinda the default in CB templates) method of a “system” handler which is defined as the application startup method (coldbox.applicationStartHandler). This just as easily allows me to use the Application Storage plugin as an interceptor would. I don’t think there is an interception for application start because (?) interceptors are application scoped objects (someone correct me if I’m wrong).
With your first point, I think that is just part of the course of development. If you adhere to code re-factoring and Unit Test development, these things can be picked up at that stage. For example, you maybe working on an API an begin to layout the foundation for the API and boom something crops up that you didn’t think about.
Your other developers may question that, or provide the information that might not be thought of at the time.
The amount of times I have rewritten code, because something better proves more efficient, is a lot. So it depends, and the answer will always be in how your organisation relates to getting the job done quickly and whether their is an option to revisit later.
Ideally you want to work out all options prior to doing any Client work as much as possible.
In your last point, yes I didn’t imply you were using that interceptor, it was me showing another way. But again I use Application.cfc non inherited, which just basically means I load ColdBox up the old fashioned way as shown in the example provided by ColdBox. But when ColdBox is loaded there are interception points that can be used an you will find that AppInit is called when the Application is initialised. Which will also cover reinit’s as well.
Yes, you are right of course. I was going to say that I have never worked in an environment where this has not been the case…however this time, I have the advantage of almost three months just to figure out if I can get everything working using coldbox as our framework…a pretty rare opportunity in my experience…one I want to use to my advantage.
Hint… Hint…