Re: [Mojolicious] Re: Mojo::Lite + AJAX exception handling / exception design pattern

[Aaron Bossert]

My personal approach to this has always been to use HTTP error codes as 
intended...and let the Ajax callback deal with what to do...for example, 
perhaps you have a  route that requires authentication, then you simply return 
a 401 if the auth was incorrect, or a 200 if correct.  The Ajax has a 'done' 
and a 'fail' callback to handle this on the client side...

--
Aaron

> On Mar 23, 2016, at 1:10 PM, Heiko Jansen  wrote:
> 
> Am Mittwoch, 23. März 2016 15:57:32 UTC+1 schrieb ddal...@gmail.com:
>  
>> A more general question, is this a good way to handle exceptions caught in 
>> mojo callback functions?   An alternative would be to not throw an exception 
>> and instead, render error data that gets returned to the .ajax .done handler 
>> (200 response code).  The .done handler is then responsible to detect the 
>> error values and display an error message to the user.  This would not 
>> generate the 500 response code which could still be thrown by the http 
>> server.
> 
> Oh my, I´m always struggling with that question myself. :-]
> I honestly don´t know if there´s a "correct" answer to that question.
> 
> There´s those - especially with a REST background - who say that you should 
> use the HTTP status codes for signalling application state.
> 
> And then there´s those who tell you that if your code handled the situation 
> then you should go with a HTTP status code indicating success and put error 
> codes in app specific data structures; leaving HTTP status codes and 
> especially error codes for those situations where your server side code 
> didn´t cope with the situation.
> 
> Of course you could also use a HTTP error status _and_ return a data 
> structure with additional information.
> 
> The answer may even depend on wether you´re talking about an API or a user 
> interface.
> 
> Maybe it´s just again a case of "select one option and stick with it".
> Or maybe someone in this group with more experience can chime in and give 
> some better advice... I would be interested in hearing it, too.
> 
> - Heiko
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To post to this group, send email to mojolicious@googlegroups.com.
> Visit this group at https://groups.google.com/group/mojolicious.
> For more options, visit https://groups.google.com/d/optout.

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Re: Mojo::Lite + AJAX exception handling / exception design pattern

[Heiko Jansen]

Am Mittwoch, 23. März 2016 15:57:32 UTC+1 schrieb ddal...@gmail.com:
 

> A more general question, is this a good way to handle exceptions caught in 
> mojo callback functions?   An alternative would be to not throw an 
> exception and instead, render error data that gets returned to the .ajax 
> .done handler (200 response code).  The .done handler is then responsible 
> to detect the error values and display an error message to the user.  This 
> would not generate the 500 response code which could still be thrown by the 
> http server.
>

Oh my, I´m always struggling with that question myself. :-]
I honestly don´t know if there´s a "correct" answer to that question.

There´s those - especially with a REST background - who say that you should 
use the HTTP status codes for signalling application state.

And then there´s those who tell you that if your code handled the situation 
then you should go with a HTTP status code indicating success and put error 
codes in app specific data structures; leaving HTTP status codes and 
especially error codes for those situations where your server side code 
didn´t cope with the situation.

Of course you could also use a HTTP error status _and_ return a data 
structure with additional information.

The answer may even depend on wether you´re talking about an API or a user 
interface.

Maybe it´s just again a case of "select one option and stick with it".
Or maybe someone in this group with more experience can chime in and give 
some better advice... I would be interested in hearing it, too.

- Heiko

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Re: How to use production.log under command line ?

[Jan Henning Thorsen]

Oh! I missed out on "debug.log" as well. Could it be wrong file 
permissions? There's a lot that can go wrong when running from "cron".

I normally add "1>/tmp/cron-app-tmp.log 2>&1" when I can't figure out what 
is going on.


On Wednesday, March 23, 2016 at 3:07:20 PM UTC+1, Jan Henning Thorsen wrote:
>
> Have you tried "perl /home/lab/MyApp get -m production 
> /update?filter=opened" ?
>
> For more information: mojo get --help
>
>
>
> On Wednesday, March 23, 2016 at 12:09:37 PM UTC+1, Pavel Serikov wrote:
>>
>> I'm calling one of route of my Mojolicious::Lite app via cron, using 
>> command-line 
>> interface , like this:
>>
>> */5 * * * * perl /home/lab/MyApp get /update?filter=opened
>>
>> inside MyApp there is some logging strings like
>>
>> app->log->info('Variable a:'.$a);
>>
>> But as I noticed that app is not writing to production.log or debug.log 
>> when accessed via command line.
>>
>> How to call same (as access to routes via browser) logging when access 
>> the app via command line?
>>
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Re: How to use production.log under command line ?

[Jan Henning Thorsen]

Have you tried "perl /home/lab/MyApp get -m production 
/update?filter=opened" ?

For more information: mojo get --help



On Wednesday, March 23, 2016 at 12:09:37 PM UTC+1, Pavel Serikov wrote:
>
> I'm calling one of route of my Mojolicious::Lite app via cron, using 
> command-line 
> interface , like this:
>
> */5 * * * * perl /home/lab/MyApp get /update?filter=opened
>
> inside MyApp there is some logging strings like
>
> app->log->info('Variable a:'.$a);
>
> But as I noticed that app is not writing to production.log or debug.log 
> when accessed via command line.
>
> How to call same (as access to routes via browser) logging when access the 
> app via command line?
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] Re: Mojo::Lite + AJAX exception handling / exception design pattern

[Heiko Jansen]

Throwing the exception leads to a response code "500" for the ajax request; 
since code 500 signals an error the "fail" handler for the ajax request 
get´s triggered.

That of course does not mean that the content returned from the mojo server 
is rendered in your page; it was an ajax request after all, so rendering 
any content in the browser would be the responsibility of your javascript 
code in myapp_fail.

By the way: blindly rendering the response from the server to your user 
imho does not make much sense: something unexpected may have gone wrong 
server side so you cannot be sure what kind of error you got and if it was 
one you triggered on purpose like in your code show above.

If you add "location.href='/exception';" in the myapp_fail function then 
this happens:
0) You make your ajax request to the server
1) the exception template is rendered because of your "throw" 
2) your server sends a code 500 response with the content from the 
exception template
3) your javascript library receives a response with a status code 
indicating a server side processing error and calls the fail handler
4) your ajax fail handler receives the rendered output of the exception 
template and does something with it (or not)
5) you modify  "location.href"
6) the browser now makes a regular (non-ajax) request to the new URL 
in location.href which happens to be "/exception"
7) your server receives the request
8) something goes wrong and the exception template is rendered because of 
some internal error
9) the browser receives the output and displays it

Of course the response your browser receives in step 9 is in no way 
connected to the exception you threw in step 0.

After step 7 I´m not completely sure what happens; apparently you did 
create a callback for the route "/exception" (at least I believe so, 
because of the "in /exception" debug log message) but I don´t think that 
there´s any automatic connection between a route of that name and the 
internal exeception handling template. 
That´s probably the reason why the server generates a "501 Not Implemented" 
response.

In the end I believe the problem is less with using mojolicious but more so 
with some lack of understanding how ajax works and about the statelessnes 
of HTTP.

Hope I could point you in the right direction
- heiko

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

Re: [Mojolicious] Is Mojolicious a sensible long-term choice for web services?

[Ed W]

Hi


The choice of tools is not easy.

We like Perl, and are quite good with it (more than 16 years 
experience, about 100k lines of Perl code). But younger programmers 
are not much drawn to it.

We are also good with C.

This is why we look at Mojo.


I think these opinions quickly can become overly passionate... However, 
I think we can summarise that in general the trend is that web stacks 
are generally popular and developers like them. They remove a lot of the 
repeated work in developing an app


I think opinions then tend to be around whether people want "full stack" 
or just a skeleton. Plus some philosophical differences on how you 
construct your MVC, etc.


I presume anyone on this list is going to be a Mojo fan, so feedback 
should be positive!  I personally use mojolicious in production for a 
small project and like how flexible it is. There isn't too much "magic" 
so that the structure seems mostly obvious to me (contrast say with some 
huge frameworks like Rails where you have a lot of magic, especially if 
you need to actually understand the details of some rendering path).


Most of my critiques would boil down to some feature that *I* felt was 
missing, and others would be about some unique requirement that *I* have 
which would feel tricky to me because my perl fu isn't strong enough (ie 
they would be "opinion" criticisms only). So basically, Mojo seems more 
than good enough to build both small and huge projects around, any 
complaints will be small things that you can build yourself.


Also, I think perl + mojo is the best (of the scripting type languages) 
at avoiding "callback hell". It's not totally avoidable, but we have a 
lot of tools (mojo + anyevent) to keep it mostly under control.


We can consider switching to a totally different environment, where 
attractive Web Fraameworks and related development tools are available,
like Java-based (a lot of choices), Python (Django seems in the 
front), Javascript (Ember.js ?)


Dunno, it's only a datapoint, but for me the "new hotness" is Elixir. I 
like the way the language "thinks", and in many ways I find it quite 
compatible with perl (I think perl never totally embraced OO and hence a 
lot of code is kind of partly OO and partly functional. In fact there is 
quite a lot of functional style thinking in many perl projects)


The philosophy of web dev in Elixir is that the language easily supports 
even millions of (green) threads, so you can write your code in a 
"blocking style" and never worry about blocking other threads. If you 
are tempted I would recommend Joe Armstrong's thesis paper, this gives 
you insight on why the language "thinks" in the way it does.  Examples 
of successes in Erlang/Elixir might include Whatsapp and there was a non 
trivial multi user chat app demo'd recently running 2 million 
connections to a single server.


Again, just a datapoint, but I'm planning to move my Rails projects to 
Elixir, but no plans to move the Mojo stuff (in fact we will probably 
increase the number of mojolicious apps, mainly for lightweight, 
compartmentalised type deployments)



Good luck!

Ed W

--
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+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.

[Mojolicious] How to use production.log under command line ?

[Pavel Serikov]

I'm calling one of route of my Mojolicious::Lite app via cron, using 
command-line 
interface , like this:

*/5 * * * * perl /home/lab/MyApp get /update?filter=opened

inside MyApp there is some logging strings like

app->log->info('Variable a:'.$a);

But as I noticed that app is not writing to production.log or debug.log 
when accessed via command line.

How to call same (as access to routes via browser) logging when access the 
app via command line?

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to mojolicious@googlegroups.com.
Visit this group at https://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.