That means injection isn’t even happening. Otherwise, WireBox would have thrown an error. How are you creating the object that has the injected property inside of it?
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
it’s a handler Brad.
I have a cfm page in a view folder of coldbox that creates the invoice.cfc object located in the handler of the module api.
Yeah you may want to separate that back into the handler, personally anyting like this should be done in the handler and not the view. It means you can reuse code more this way.
> creates the invoice.cfc object
I need more info than that. HOW is it being created?
// This is bad, it bypasses WireBox entirely
myComponent = createObject( ‘component’, ‘path.to.myComponent’ );
// This is good, WireBox is used to create and autowire the object
myComponent = getInstance( ‘myComponent@module’ );
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Hi Brad and Andrew,
My apologies for the ambiguous explanation.
Here is what is in the ColdBox root>views, AKA wsdev>views folder for testing my API.
//writedump(var=apiPost,abort=true); writeOutput(apiPost.statusCode & 'test_ws_invoice_post.cfm
This test_ws_invoice_post.cfm file is using REST calling the API invoice.cfc create() method in JSON format that is located in the api module of ColdBox.
Brad, I see how this is not actually creating an object like your last example as it is actually calling the invoice.cfc via REST. How would I be able to make this work? The only thing I can think of is by creating another cfc layer (a proxy perhaps?) with your line of code “getInstance(‘invoice@api’);” which then calls the invoice.cfc. It seems like my proxy idea is a round-about way to get the API to communicate with WireBox, so I am sure I am missing the target. I am all ears on how this is actually done with an API.
Thank you for pinpointing the problem!
Ryan Hinton
All handlers can be called via rest.
Thanks, Andrew.
The handler is working, but it is not registering WireBox, which is the problem, I believe.
So, I’m curious to know how you or Brad get the WireBox to run on an API in a module.
The code I have in the previous message works except that it does not seem to know anything about WireBox, as Brad mentioned.
The utility shows undefined, so all I need is to understand where I should actually get WireBox working.
I have the property set to Brad’s example within the api invoice.cfc, but none of this seems to get fired since WireBox does not seem to be running.
I also have a WireBox.cfc in the configure folder, so I’m assuming it’s integrated and running, but maybe I am wrong about that.
Within the WireBox.cfc I have an empty JSON within the configure() method like the following:
wireBox = {};
The only reason why I have it this way it because I have tried a pluthera of configurations within the wireBox struct and there is no difference with what I do in here. Also,
based on our previous conversations, I believe this is autowired for the models folders by default and does not require any other configuration if that is where my utility.cfc is located.
So, right now I’m stumped. lol
Thank you,
Ryan Hinton
You might need to show your handler, without that we are guessing to what your’re actually doing.
Unless you have changed the conventions the model folder should be the folder you stick these into and it should just pick them up. Do you require any special init of that component. I tried going back through the posts, but couldn’t find any code to show your handler and what you’re doing in your handler.
But yeah I would be moving the CFHTTP out of your view and into your handler, or at least into a model rather than do it in the view itself. Reason being, is that if the CFHTTP fails, then your not running the view and then displaying another view. You can change the view in the handler depending on the handler logic flow.
Here is a synopsis of what I have in my modules/api/handlers/invoice.cfc
I have placed asterisks on the line that errors in the following code.
The error that I receive is:
Event: api:invoice.create
Routed URL: api/invoice/create/
Layout: N/A (Module: )
View: N/A
Timestamp: 06/08/2015 10:38:20 AM
Andrew, to answer your inquiries:
There is no special init of the handler component in the invoice.cfc.
The cfm page that has the cfhttp is only a test case page on my local machine that will not be used in production and it is only for me to actually view the response. It’s just a test to call the API module with various test files, which I am actually creating test json files that will make the API bust.
Do you think this is the reason for the main problem? Unless I seem to be completely not understand what you are suggesting by moving it, I seem to not have an issue with the cfhttp page for local testing. I’m having an trouble with the API not having WireBox working. When I actually move the utility methods within the invoice.cfc and remove everything related to utility, the entire API works flawlessly. It’s just not getting a handle on WireBox when I am attempting to inject utility.cfc from the modules/api/models folder.
Based on what I have mentioned, do you still think the cfhttp page needs to be moved in order to get WireBox to work?
Thank you,
Ryan Hinton
Ok, so to clarify you have a models folder with the utility in it? And you’re using ColdBox 4.x, can you double check your conventions, because it is model and not models in ColdBox 4.x, unless you have changed the default convention. At least that is what one of the changes in 4.x is.
Yes I do.
The flow is that you have to evaluate/run the view in order to do the cfhttp, if you do your job correctly you will need to apply a catch if something goes wrong. Nothing is up 24/7 and you should cater for this. By moving this into the handler, you can say something like this.
function create(event,rc,prc) {
// Create an Invoice
var local.jsonClaims = deserializeJSON(fileRead(rc.claims));
local.jsonKeyVals = utility.makeJSONkeyValPair(local.jsonClaims); // THIS IS THE LINE THAT ERRORS
local.response =
//psuedo code
try {
//doCFHTTP();
//do what you need with results
//displayView for invoice
} catch (any e) {
// displayView for Error page or notify admin / developer
}
}
In that example based on the condition of an exception or not, it will display the right view. If you go to the view that is extra processing if you need to then change the view to display an error or apply other notification work flows into the mix.
ColdBox and the API Module was created via CommandBox CLI. I have not changed any convention when it comes to naming “models” over “model”.
The folders that were created from the CommandBox CLI have made folders spelled as “models” in my case.
I also have the Relax module within my modules folder and it, too, has it spelled as “models”.
Thank You,
Ryan Hinton
Ok was trying to grasp at straws as to why something so simple isn’t working.
I would suggest two options. The first would be to zip up a working example of the site that we can download and run, OR simplify what you’re doing. Scale back to just injecting a known object into a regular handler and confirm that works and then move up from there until it stops working.
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
I see what you are attempting to have me do here with your example.
What you do not see is the multiple lines of code for the line: local.response =
I have a ton of validation happening (multiple lines) to return a response in JSON format for any kind of error back to the user.
The user will be calling our API and will not receive a view, instead they will receive a JSON response which they can process and it returns a callback to the user of all their data with an added api JSON response column attached to every data row which shows the status of OK or Error with a message description. The cfhttp page is my testing/enactment of being a user that calls our modules/api/invoice::create() method. There will not be any cfhttp used on the production server or a need for it within the create() method when all of this is complete. The user will be calling our API via the REST URL in any programming language they wish to use to receive a JSON callback.
So, I understand what you are attempting to have me do, which makes sense if I am planning to call the API back to itself. If the cfhttp was written as you are suggesting, I would be running into an infinite loop as it would be constantly calling itself over and over.
That’s how am I seeing that it would happen from your interpretation and I could be off from what you are suggesting.
Brad, I will see if I can simplify it more. If I have some time here, I will attempt to make a zipped working copy for you guys.
I am very appreciative and thankful for all of the help you guys are trying to do for my situation.
I hope I can get this working! lol
Thank you, again!
Ryan Hinton
Can you also turn on logging and check to see if there is an issue actually injecting it, if there is it will show up in the logs.
I will check that out, Andrew. Thank you for that suggestion.
If I have debugging on, would anything related to WireBox show up in the call stack? Right now there is nothing I can see that is calling it when I get the undefined error on the line that uses the utility.
I have started creating an example set that I will zip up and have for you guys shortly.
Thank you,
Ryan Hinton
The default LogBox settings may have debug messages ignored for coldbox.system. You want to enable all log levels for coldbox.system.ioc, but be warned, there’s a lot of WireBox chatter, so don’t forget to turn it of afterwards 
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com