Route not found problem ("None of these routes could generate a response...")

[Charlie Brady]

I hesitate to ask this, since I'm using apache/CGI, but I'm stumped, so
need some help.

I'm getting a 404 page on form submission. But the route I'm using appears
in the list shown in the default 404 page. Does anyone have a suggestion
how I investigate this?

....

Page not found... yet!

None of these routes could generate a response for your POST request for
/register, maybe you need to add a new one?

Pattern Methods Name

/ GET
/ POST
/uploadLicense POST uploadLicense
/register POST "redirect_activate"
/activate GET activate
/sync POST sync
...

[Stefan Adams]

I get that a lot too. Could it be that the redirect_activate method couldn't be reached?

--
You received this message because you are subscribed to the Google Groups "Mojolicious" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mojolicious...@googlegroups.com.
To post to this group, send email to mojol...@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Charlie Brady]

On Fri, 11 Jul 2014, Stefan Adams wrote:

> I get that a lot too.

I think it's a bug - nobody should get that. The helpful 404 page should
be, well, helpful.

> Could it be that the redirect_activate method
> couldn't be reached?

That's a "Name" in the table. I don't have the code accessible, but as I
recall it's:

post "/register" => sub {
...
} => "redirect_activate";

So I don't really understand your comment. Is "redirect_activate" a
method? What would "could not be reached" mean? Are "Names" used in route
lookup?

Anyway, somethings wrong. In my code, no doubt, but I think also in Mojo,
which should be able to provide a more useful diagnostic.

[sri]

I think it's a bug - nobody should get that. The helpful 404 page should
be, well, helpful.

If only there was debug information... something like log messages... we could show those at the bottom of the 404 page!

--

sebastian

[Charlie Brady]

On Fri, 11 Jul 2014, sri wrote:

> > I think it's a bug - nobody should get that. The helpful 404 page should
> > be, well, helpful.

I think I should have been clearer.

The 404 page is generally helpful. However in this case, rather than
helpful, it is confusing. It says:

...

None of these routes could generate a response for your POST request for

"/register", maybe you need to add a new one?
...

But then it shows me that I have a route for POST requests to "/register":

...
/register POST "redirect_activate"
...

So I find that confusing.

> If only there was debug information... something like log messages... we
> could show those at the bottom of the 404 page!

I don't know what you are getting at.

[Charlie Brady]

Ah, now I do. The debug log shows me:

[debug] POST "/register".
[debug] Routing to a callback.
[debug] Template "redirect_activate.html.ep" not found.

So instead of:

None of these routes could generate a response for your POST request for
"/register", maybe you need to add a new one?

it could say:

None of these routes could generate a response for your POST request for

"/register"; either a matching route was found and could not generate a
response, or you need to add a new one?

... or some state could be saved in stash, and the 404 template could be
more explicit about the problem - that a route was found, but it failed to
generate a response.

At any rate, I know what my error was:

...
$self->render;
} => 'redirect_activate';
...

with no matching template.

Thanks for the hint.

[Vibhor bhardwaj]

Hi,

Have you find any solution of your problem?

Thanks

[Charlie Brady]

On Fri, 22 May 2015, Vibhor bhardwaj wrote:

> Hi,
>
> Have you find any solution of your problem?

Yes, as you would know if you had read to the end of the thread:

https://groups.google.com/forum/#!topic/mojolicious/7FDGtO-FV9k

"At any rate, I know what my error was .."

The problem IMO is that mojo reports back 404 when I think it should
report 500. The same issue was noted by OmarOthman on IRC last week:

http://irclog.perlgeek.de/mojo/2015-05-11

[Vibhor bhardwaj]

Can you please check my question? 

http://stackoverflow.com/questions/30449865/page-not-found-yet-with-mojolicious

Is it relevant to this bug and how can I resolve this issue?

[Andrew]

Hi all, =).

This year, I used mojolicious for the first time.

I noticed something called is_file and assumed it took a file reference,
and checked if there was actually such a file.
Well...it doesn't seem to serve that purpose / work in that way at all.
I've changed my code to use -e on an actual path and file name instead, to
check if it exists.
So I'm left scratching my head - what does is_file actually do, if it
doesn't check if a file exists?

Documentation is just one word:
"True".
Indicating it returns true when given a file reference.
Is it just used to check that a variable is a file reference?
http://mojolicio.us/perldoc/Mojo/Asset/File#is_file

I've been speaking vaguely.

To be precise, I started off with this, which didn't work:

my $parts_txt_file_ref = Mojo::Asset::File->new(path =>
$variable_containing_path.'/parts.txt');
if ($parts_txt_file_ref->is_file) {
#do something
};

And I changed it to this, which worked:

my $parts_path= $variable_containing_path.'/parts.txt';
if (-e $parts_path && !-d $parts_path) {
#do something
};

Anyway, pretty happy to have joined this group, =).
Thanks for having me! =).

Yours,
Andrew.

[Justin Hawkins]

On 27 May 2015, at 8:47 am, Andrew <mojolici...@unitedgames.co.uk> wrote:

So I'm left scratching my head - what does is_file actually do, if it
doesn't check if a file exists?

A Mojo::Asset::File is always a file, as the name implies, thus it always returns true.

If you have a Mojo::Asset, you can use is_file to find out if it is a file (as opposed to it being perhaps a Mojo::Asset::Memory object).

if (! $asset->is_file) {

  $asset->move_to(‘/some/other/file.txt’);

}

- Justin

[Andrew]

 

Thanks for the clarification, =).

 

I was thinking of a file as something that exists on the server, rather than something that exists as an object.

That is, when I created a Mojo::Asset::File I didn't view it as a file, if it hadn't been saved as a file to the server, using move_to.

So is_file checks if a Mojo::Asset is a Mojo::Asset::File.

 

=) Many Thanks,

 

Yours,

Andrew.

 

 

--

[sri]

I was thinking of a file as something that exists on the server, rather than something that exists as an object.

The documentation has been updated recently too.

    https://github.com/kraih/mojo/commit/1300205d991ebfdb25d45e76cd9537327876be17

--

sebastian 

[Andrew]

=D That's so awesome! ^_^

 

Many thanks, =).

--