A coupla days ago, <@U037T7H57EF> raised a situati...
# cfwheels
A coupla days ago, @Mr M raised a situation they were having with the beginners tutorial (see https://cfml.slack.com/archives/C1QB85ZJ5/p1647699598608829). Because I had a surplus of will-to-live today, I thought I'd try an exercise in CFWheels, which necessitated me building a new CFWheels site, so I figured the best thing to do would be to follow the same tutorial. I got to the same point as Mr M, and encountered the same problem. And to me, having looked through the code to where it's going wrong, it looks like a bug. Details in thread...
The tutorial says to sling this code into a view:
Copy code
<p>Time to say <cfoutput>#linkTo(text="hello", action="hello")#?</cfoutput></p>
(this is @ https://guides.cfwheels.org/docs/beginner-tutorial-hello-world#linking-goodbye-to-hello) I can confirm what Mr M says... that only creates a link to
The logic to build the link in
(https://github.com/cfwheels/cfwheels/blob/v2.2.0/wheels/view/links.cfm#L24) ends up calling
(from https://github.com/cfwheels/cfwheels/blob/v2.2.0/wheels/view/links.cfm#L59). At this point it is still passing through everything it needs to create the correct URL. In
(https://github.com/cfwheels/cfwheels/blob/v2.2.0/wheels/global/misc.cfm#L599), the logic flows through to where it checks what route we are on (https://github.com/cfwheels/cfwheels/blob/v2.2.0/wheels/global/misc.cfm#L669). At this point we are on
(which is resolved further up I guess), and this is not present in
(so the
block doesn't run), but it is present in
, so that
else if
block executes. What that does is call
$findRoute(route = local.params.route);
. Notice all it passes into that method is the
. No other information.
has a bunch of logic in it to resolve the correct route pattern for the requested info... this is down around https://github.com/cfwheels/cfwheels/blob/v2.2.0/wheels/global/internal.cfm#L461-L477. This is where the bug is. All the logic in there presupposes that values like HTTP method and the controller and the action have been passed-in to
. If they had been... the code would actually work. However the logic to do the matching @ https://github.com/cfwheels/cfwheels/blob/v2.2.0/wheels/global/internal.cfm#L468-L470 never finds them, so the logic just ends-up falling out the bottom of the function, without a route being resolved. Because the last
element to be processed is the
one, then that's the one that gets used in the URL. This itself looks to me like another bug, because if the route can't be resolved, it shouldn't just return the last one it tried (and failed) on; it should throw an exception. The fix is in two parts: • pass the call to
the rest of the stuff it needs to make a decision; in this case it needs
, then it works. This is solved simply by calling it as
$findRoute(route = local.params.route, argumentCollection=arguments)
(I've added the
there. This is even how it's called in the previous logic block! • I don't know where the
value should best come from. I guess perhaps it's implicit that a call to
is going to be for a GET route (
tags - "links" - are always GET requests, right?), so it can be passed from there to
? After that, none of the logic should be making assumptions about what method the route is being resolved for, so I don't think it should default to
anywhere "further in".
Oh, three parts... • if that loop trying to resolve the route completely fails (after the loop
local.foundRoute = false
still), then some sort of action ought to be taken. The rest of the code in the function presumes it was found. I guess it could
? It's hard for me to say, because this issue only comes up due to a logic error in the Wheels code, or possibly even a config error on the part of the inplementation code. So I think it should probably be a server error (5xx) not a 4xx as that implies the client agent has done something wrong, which they actually haven't here. Anyway, the current code is not helpful as the app dev should be told if their routes are misconfigured, or if they're requesting an invalid route / URL / link / what-have-you.
Four parts: • in this situation
if (!StructKeyExists(application.wheels.namedRoutePositions, arguments.route)) {
(https://github.com/cfwheels/cfwheels/blob/v2.2.0/wheels/global/internal.cfm#L453-L454) CFWheels returns a 404 response. As per above, this is not caused by the client agent doing something wrong, it's due to the CFWheels app doing something wrong. So it's a 5xx situation, not a 4xx situation.
Ah! I found a ticket in github (https://github.com/cfwheels/cfwheels/issues/1098#issuecomment-1074229845)... added all these deets there. Hopefully if anyone is still there (Looks like @chapmandu might be?), they can do [something] with this info if they want.
@Adam Cameron can you try installing a new CFWheels app using the CLI.
Copy code
wheels generate app
I have fixed the bug in the urlFor() function in the cfwheels-core package.
But make sure you update your CLI first. I just pushed v0.7.0 this morning.
@Peter Amiri, to be clear: my interest in this issue is pretty non-existent. I was just trying to help @Mr M who had the same problem.
All I wanted to do is report my findings to [someone on the project who might want to know], and feed back if my findings weren't clear.
(which I consider I have done)
I do not have the CLI thing installed, and have no use for it. I'm just using the install from https://www.forgebox.io/view/cfwheels
And even then I'm only installing that to investigate how easy/hard it is to integrate an IoC container (eg: DI/1) into a wheels app. So just needed an operational wheels site, which I have.
Understood. Thank you for the information. I am currently not a member of the core team and only have access to the CLI code but I will work with them to see how to clean up the various outdated information published on the framework.


All good so far 😄
Thanks man. And thanks for pitching in here.
No problem. If you don't mind I'd still like your opinion on the CLI if you don't mind doing a
box install cfwheels
and then
wheels g app
and let me know what you think of that experience.
I'll try to find some time.
box install cfwheels
is not installing any
I presume you want me to run that from within a commandbox shell?
(after doing the
box install cfwheels
I mean)


Think you poss missed a step to install the CLI bit?
box install cfwheels-cli
and then going into a box shell before doing
wheels g app
works better 😉
OK this is gonna take more time than I have available right now. I will check another evening when I have some time.
Copy code
========= All Done! =============================
| Your app has been successfully created. Type   |
| 'start' to start a server here.                |
|                                                |
| Don't forget to add your datasource to either  |
| /lucee/admin/server.cfm OR                     |
| /CFIDE/administrator/index.cfm                 |
|                                                |
| Once you've started a local server, we can     |
| continue building out the app.                 |

Ok, thanks for trying.
Just so you know, the
wheels g app-wizard
command just gathers info to pass to the
wheels g app
command. I've done some testing with the H2 drivers also and updated the drivers for H2 in the CLI as well as the Wheels core. Anyway I welcome your input whenever you get a chance to look at it again.