We’ve recently started consolidating some code into coldbox modules and have run into some interesting errors. The code doesn’t change, but every once in a while, the same URL will run the view code without running the handler code first. That, or the handler runs and somehow the prc gets trampled in between the end of the handler running and the view code running.
The reason we think this is the case, is that in the handler, things are put in the prc and the view code throws an exception like “Element READONLY is undefined in PRC”. In an ajax handler, we have code like
`
<cfset local.returnStruct.view = renderLayout(layout = “layout.div”, viewModule=“person”, view = “admin/request/memo”) />
`
We’ll get an error like this from the view a few times a day. The code doesn’t change, and it’s been tested by multiple people before it goes out, so we know it’s working.
Is there anything that could cause modules to treat this as an implicit handler and try to run the view without correctly finding the handler and running it the usual way? Or is there anything that could present a different struct to the view as prc than the one the handler added data to?
Any help would be great! Thanks.
Jon
Can you wrap the line that fails in a try/catch and E-mail yourself the contents of the prc scope to help debug? Also make sure you’re not storing prc in any other scope that could be causing it to bleed between pages.
Thanks!
~Brad
ColdBox/CommandBox Developer Advocate
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Thanks for the quick reply. I’ll try the try/catch (see what I did there). That should give a better idea of what’s going on.
On storing prc, we never touch it other than to put things in and reference things we’ve put there - the usual.
thanks again,
Jon
I had the same issue once due to a trailing / in a path in modulesExternalLocation. The moduleservice will add the convention folders to the path using a leading slash.
Views are simple files called with paths and windows was resolving the double slash it created. However, for components it replaces the slashes by dot’s and a double dot in the component path will not be resolved. As a result it would find views and layouts, but not handlers and models.
Maybe this will help?
Pascal
Was it doing this consistently? What you’re describing sounds like how it fundamentally handles resolution. Our code (including the config of modulesExternalLocation) doesn’t change between deployments, and doing a framework reinit causes the issue to go away for us. We’re seeing it in various external modules, where it seems like when it loads the module it just fails to note that there’s a handler and treats the URL like it’s supposed to do the implicit handler thing and starts immediately in on the .cfm view code.
I’m not sure even where to look in the framework code to see if there may be something like a caching of routes and maybe it gets a request before it has a chance to finish finding the handlers when the app is starting up, so it assumes it’s an implicit handler and goes from there, caching that determination until the next reinit. Dunno - just grasping at ideas.
Jon
Do you happen to have any symlinks at play with your modules? I just fixed a similar issue on the bleeding edge of ColdBox that happened when you symlinked a module into ColdBox. It was due to a Lucee bug that only showed up on Mac (well, I didn’t test LInux, but the bug didn’t exist on Windows).
~Brad
No - our modules are sitting adjacent to our host app code w/o any linking. Because we’re seeing it intermittently, I wonder if it has to do with a race condition when the module is loaded into the host app under server load.
(Sorry to carry on the conversation in two places; I figured I’d post here as well for anyone who’s not on the slack channel.)