Ah, I missed the part where you had your own uuid as well. The i18n plugin already handles storing the locale in session, cookie, request, etc. How is your uuid generated? Is it based on the locale?
You could use the session storage or cookie storage plugin to encapsulate the uuid, or if there is some logic involved to generate or default it, just create a wrapper service if your own design that you can inject that will retrieve that state from the appropriate scope. (You can programmatically access the request collection from your models via ColdBox’s RequestService, if necessary too) Just wrap it up so anything messy is abstracted behind a clean API.
I would try to keep your method parameters to those that directly apply to the method being called so you don’t burden calling code with unnecessary details.
Brad. You’re information was very helpful. I added the code to the preHandler() thinking I could set the locale there. Worked great!!! Until I used Postman to actually make the REST call. Then I discovered that (apparently) the preHandler does not get invoked if the call is made via REST.
I then decided to go the route of creating an interceptor using the docs on the wiki. Doesn’t matter what I do; however, it does not seem to work.
The Interceptor is defined in the Coldbox.cfc, and has a configure() and preProcess() method. The preProcess method has eventPattern=“^api.” which matches the route. The interceptor extends Coldbox.system.Interceptor.
Anything off the top of your head that I am missing?
Are you using CF’s built in REST, or routing a REST API via ColdBox?
There’s no difference from the client’s perspective when consuming a REST API versus a generic HTTP call since that’s all REST really is. Therefore, hitting a URL in the browser should simulate a GET method REST call. So to clarify, when you said the prehandler does not get invoked if the call is made via REST, can you clarify what that is opposed to?
If you take the event pattern out of your interceptor, does it fire?
Can you show us the config code that registers it?
If you put a dump/abort in the configure(), can you confirm it’s being loaded?
Also on top of what Brad has said, have you tried re-initializing the application so they are loaded. Now at a guess I am thinking that the interception point is not being fired as Brad may have picked up, because I think the . is causing the issue, unless you have other routes that begin with api, then maybe remove that and see if you still get the same results.
But a very simple injection of logbox, then logging a debug entry in the interceptor can tell if the interception point is actually firing, try without the event pattern and then try with it. But I am positive that it is the event pattern that is the cause or you haven’t re0inited the application, I would assume the former.
//------------------------------------------------------------------------------------------------
public void function preProcess(event, interceptData) eventPattern="^api" { log.info(“pre-Process for api call…”);
}
}
When trying to solve any of this sort of stuff, logging becomes your best friend.