The tutorial says to sling this code into a view:

<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

<http://localhost:8888/index.cfm/say>

(not

[...]/say/goodbye

The logic to build the link in

linkTo

(https://github.com/cfwheels/cfwheels/blob/v2.2.0/wheels/view/links.cfm#L24) ends up calling

uRLFor

(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

uRLfor

(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

wildcard

(which is resolved further up I guess), and this is not present in

arguments

(so the

if

block doesn't run), but it is present in

local.params.route

, 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

route

. No other information.

$findRoute

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

$findRoute

. 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

application.wheels.routes

element to be processed is the

/[controller]

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

$findRoute

the rest of the stuff it needs to make a decision; in this case it needs

method

,

controller

and

action

, then it works. This is solved simply by calling it as

$findRoute(route = local.params.route, argumentCollection=arguments)

(I've added the

argumentCollection

there. This is even how it's called in the previous logic block! • I don't know where the

method

value should best come from. I guess perhaps it's implicit that a call to

linkTo

is going to be for a GET route (

<a>

tags - "links" - are always GET requests, right?), so it can be passed from there to

uRLfor

? 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

GET

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

$throwErrorOrShow404Page

? 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.

But make sure you update your CLI first. I just pushed v0.7.0 this morning.

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.

Thanks man. And thanks for pitching in here.

box install cfwheels

is not installing any

wheels

script

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?

Ah...

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.

But:

========= 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.                 |
==================================================

CommandBox:MyCFWheelsApp>

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.