Wishlist thread (second edition)

[sri]

Soooo... it's been over 6 months since our last wishlist thread (https://groups.google.com/forum/#!searchin/mojolicious/wishlist/mojolicious/YK7SrFvEneY/uwr-TZAlGmcJ), a lot has happened since then (5.0 and Mojoconf, yay!), and i believe we are ready for another round.

In this thread you can post changes or features you would like to see in Mojolicious, no rules, just blurt away. :)

P.S.: Our official roadmap can still be found on GitHub (although it is almost empty now). https://github.com/kraih/mojo/issues?labels=future&state=open

--

sebastian

[sri]

I guess Mojolicious is done. :)

--

sebastian

[Stefan Adams]

On Tue, Jul 8, 2014 at 12:56 PM, sri <kra...@googlemail.com> wrote:

I guess Mojolicious is done. :)

It's funny you say this (albeit in jest), because I've thought to myself many times: "I wonder if Mojolicious will ever be considered 'done'?  Not counting the new HTTP/2.0 and other RFC pending changes..."  I always think there can't possibly be anything else to add or improve.  But then you continue to make excellent subtle documentation or code enhancements, and then you figure out a new feature to add!  :D

[s...@alexbyk.com]

+1)
Mojo is great but never stop

On Tue, Jul 8, 2014 at 12:56 PM, sri <kra...@googlemail.com> wrote:

I guess Mojolicious is done. :)

It's funny you say this (albeit in jest), because I've thought to myself many times: "I wonder if Mojolicious will ever be considered 'done'?  Not counting the new HTTP/2.0 and other RFC pending changes..."  I always think there can't possibly be anything else to add or improve.  But then you continue to make excellent subtle documentation or code enhancements, and then you figure out a new feature to add!  :D

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

[Andrey Khozov]

​My wish list for Mojolicious:

1. Digest authentication in Mojo::UserAgent;
2. Full asynchronous API for Minon::Backend (fail_job, finish_job, job_info, list_jobs, remove_job, retry_job);
3. Support UDP in Mojo::IOLoop (may be UNIX sockets too) and asynchronous DNS client;

It is very difficult to make portable, but :)

4. Asynchronous working with files;
5. Likeness AnyEvent::Util::fork_call.

All glory to the Mojolicious!​

--

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.

--
Andrey Khozov

[Helmut Wollmersdorfer]

Am Dienstag, 8. Juli 2014 19:56:40 UTC+2 schrieb sri:

I guess Mojolicious is done. :)

IMHO it is done.

My whishlist is more outside the core, features and coding:

1) improve documentation

- more real live examples instead of "toy size" (foo, bar, Hello World ..) examples

2) improve non-core plugins (not a task of the core Mojolicious project)

 

[Tim]

SOCKS 4/5 proxy support for Mojo::UserAgent :)

[s...@alexbyk.com]

I noticed that subroutines in Mojo source code are ordered
alphabetically. Can anyone share how to do that? Is there some magic vim
plugin?

[Dotan Dimet]

On 07/09/2014 04:55 PM, s...@alexbyk.com wrote:

I noticed that subroutines in Mojo source code are ordered alphabetically. Can anyone share how to do that? Is there some magic vim plugin?

Sebastian uses Atom (previously Textmate), not vim, and when I asked he said he does all the documentation manually.
So no magical plugin, just obsessive diligence.

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

[sri]

1. Digest authentication in Mojo::UserAgent;

Complex and not worth it (IMO), these days Basic authentication over HTTPS is always better.

2. Full asynchronous API for Minon::Backend (fail_job, finish_job, job_info, list_jobs, remove_job, retry_job);

Not necessary, Mojolicious applications only call ->enqueue, everything else happens in the Minion worker process.

 

3. Support UDP in Mojo::IOLoop (may be UNIX sockets too) and asynchronous DNS client;

UDP support is something i've considered, but we simply have no need for in Mojolicious core. Asynchronous DNS i would love to see, but is simply too hard (impossible?) to do right (through the operating system resolver) with Perl.

 

4. Asynchronous working with files;

Impossible to do without IO::AIO, which is out of the question for political reasons.

 

5. Likeness AnyEvent::Util::fork_call.

Already exists as a CPAN module. https://metacpan.org/pod/Mojo::IOLoop::ForkCall

--

sebastian

[sri]

SOCKS 4/5 proxy support for Mojo::UserAgent :)

This has come up before, i'm not against it, but there needs to be a new abstraction layer first.

    https://github.com/kraih/mojo/issues/429

--

sebastian 

[sri]

1) improve documentation

- more real live examples instead of "toy size" (foo, bar, Hello World ..) examples

I don't see that happen in core documentation, but instead in high quality applications like Convos.

 

2) improve non-core plugins (not a task of the core Mojolicious project)

Some, like Minion, will be maintained by the core team too.

--

sebastian 

[sri]

Sebastian uses Atom (previously Textmate), not vim, and when I asked he said he does all the documentation manually.
So no magical plugin, just obsessive diligence.

OCD driven development. :)

--

sebastian 

[sri]

Impossible to do without IO::AIO, which is out of the question for political reasons.

Getting rid of EV as well is actually on my wishlist, but there are currently no alternatives. Something based on libuv would be awesome.

--

sebastian 

[Andrey Khozov]

On Wed, Jul 9, 2014 at 8:43 PM, sri <kra...@googlemail.com> wrote:

2. Full asynchronous API for Minon::Backend (fail_job, finish_job, job_info, list_jobs, remove_job, retry_job);

Not necessary, Mojolicious applications only call ->enqueue, everything else happens in the Minion worker process.

​These functions (at least job_info and list_jobs) can be useful for writing administrative web interface to the queue. Of course, for this you can use the synchronous version, but it is not always convenient to do so.​

--
Andrey Khozov

[Charlie Brady]

On Sun, 6 Jul 2014, sri wrote:

> In this thread you can post changes or features you would like to see in
> Mojolicious, no rules, just blurt away. :)

A plugin like Mount, but which proxies requests and responses, so instead
of:

my $route = plugin Mount => {'/prefix' => '/home/sri/myapp.pl'};

I can do:

my $route = plugin Proxy => {'/tomcat' => 'http://localhost:8080/'};

cf ProxyPass and ProxyPassReverse in apache. This would help me to be rid
of apache and CGI.

[sri]

​These functions (at least job_info and list_jobs) can be useful for writing administrative web interface to the queue. Of course, for this you can use the synchronous version, but it is not always convenient to do so.​

Admin interfaces don't need to scale very well, but we can talk more about this once a web interface actually exists.

--

sebastian 

[sri]

...but we can talk more about this once a web interface actually exists.

The more i think about this the more scared i am... if we decide all backend methods in Minion need a non-blocking variant, i think we might have to get rid of pluggable backends completely. Since the complexity would just be too much, very few people would actually be able to write alternative backends.

--

sebastian

[Abhijit Menon-Sen]

At 2014-07-09 07:43:05 -0700, kra...@googlemail.com wrote:
>
> > 1. Digest authentication in Mojo::UserAgent;
>
> Complex and not worth it (IMO), these days Basic authentication over
> HTTPS is always better.

Yes, I agree (as someone who has implemented digest authentication in
multiple contexts).

-- ams

[Abhijit Menon-Sen]

At 2014-07-09 11:36:10 -0400, charli...@budge.apana.org.au wrote:
>
> I can do:
>
> my $route = plugin Proxy => {'/tomcat' => 'http://localhost:8080/'};
>
> cf ProxyPass and ProxyPassReverse in apache. This would help me to be
> rid of apache and CGI.

This isn't exactly what you wrote, but too far off:

http://search.cpan.org/~mramberg/Mojolicious-Plugin-Proxy-0.2/lib/Mojolicious/Plugin/Proxy.pm

-- ams

[Abhijit Menon-Sen]

At 2014-07-09 22:08:30 +0530, a...@toroid.org wrote:
>
> This isn't exactly what you wrote, but too far off:

Sorry, *not* too far off.

-- ams

[Charlie Brady]

Yes, not too far off. But only for get requests, and it buffers responses.
I need to proxy at least get/head/post/put/del. I'm sure a good solution
could be built into Mojo, but Mojolicious::Plugin::Proxy is too
simplistic.

See also:

http://marcus.nordaaker.com/my-first-mojolicious-plugin-proxy/

http://larig.wordpress.com/2012/08/01/a-mini-proxy-via-mojolicious/

[sri]

Since the complexity would just be too much, very few people would actually be able to write alternative backends.

Not to turn this into a Minion design discussion... but i think the backend API is already borderline too big, and i'd rather like to remove stuff than add more.

    http://mojolicio.us/perldoc/Minion/Backend#SYNOPSIS

--

sebastian 

[Abhijit Menon-Sen]

At 2014-07-09 16:15:08 -0400, charli...@budge.apana.org.au wrote:
>
> I'm sure a good solution could be built into Mojo, but
> Mojolicious::Plugin::Proxy is too simplistic.

I am not sure if you're saying that a good solution must necessarily be
"built in" rather than a plugin, but if so, I don't agree. Yes, M::P::P
is certainly simple, but it should be easy to extend to suit your needs.

-- ams

[Luc Didry]

I noticed that there is no command to generate a command. It could be
great to have
/script/myapp generate command Foo

or something like that which generate the command MyApp::Command::Foo in
the good directory.
Would it be possible to add it ?
--
Luc
http://www.fiat-tux.fr/
Internet n'est pas compliqué, Internet est ce que vous en faites.

[sri]

I noticed that there is no command to generate a command. It could be
great to have
/script/myapp generate command Foo

or something like that which generate the command MyApp::Command::Foo in
the good directory.
Would it be possible to add it ?

What "good directory"? Would it generate an application specific command? Something in the Mojolicious::Command namespace? A CPAN distribution like the plugin generator? You leave out way too much information for me to give a real answer.

Perhaps you should release something to CPAN first under a different name (leaving the Mojolicious::Command::generate::command namespace for core), to see if there is demand.

--

sebastian

[sri]

SOCKS 4/5 proxy support for Mojo::UserAgent :)

This has come up before, i'm not against it, but there needs to be a new abstraction layer first.

    https://github.com/kraih/mojo/issues/429

Having thought about this some more, i was about to suggest that perhaps something much simpler would work too. Such as a handshake mechanism based on IO::Socket::Socks added to Mojo::IOLoop::Client (much like the TLS code), but as it turns out IO::Socket::Socks currently doesn't even install on OS X. :(

--

sebastian 

[Luc Didry]

On 10/07/2014 22:24, sri wrote:
>
>>
>> I noticed that there is no command to generate a command. It could be
>> great to have
>> /script/myapp generate command Foo
>>
>> or something like that which generate the command MyApp::Command::Foo in
>> the good directory.
>> Would it be possible to add it ?
>
>
> What "good directory"? Would it generate an application specific command?
> Something in the Mojolicious::Command namespace? A CPAN distribution like
> the plugin generator? You leave out way too much information for me to give
> a real answer.

I meaned lib/MyApp/Command/foo.pm with the MyApp::Command namespace.
It's not for CPAN distribution like the plugin generator but a helper to
create commands easily.

I often create commands for cron tasks, it is very handy since it's easy
for my colleagues to understand their aims (and if they don't
understand, they can use the command with help and they're ok).

> Perhaps you should release something to CPAN first under a different name
> (leaving the Mojolicious::Command::generate::command namespace for core),
> to see if there is demand.


--

[sri]

Having thought about this some more, i was about to suggest that perhaps something much simpler would work too. Such as a handshake mechanism based on IO::Socket::Socks added to Mojo::IOLoop::Client (much like the TLS code), but as it turns out IO::Socket::Socks currently doesn't even install on OS X. :(

Another problem is that IO::Socket::Socks doesn't support IPv6 (at all), so there is still some work to be done on IO::Socket::Socks before we can consider using it in the Mojolicious core.

--

sebastian

[Jonis Hjellestad]

json_like('/foo', qr/bar/, 'match') and also json_unlike would be quite nice to have for testing. Don't know if this has been suggested before.

--

Jonis

On Monday, 7 July 2014 03:12:50 UTC+2, sri wrote:

Soooo... it's been over 6 months since our last wishlist thread (https://groups.google.com/forum/#!searchin/mojolicious/wishlist/mojolicious/YK7SrFvEneY/uwr-TZAlGmcJ), a lot has happened since then (5.0 and Mojoconf, yay!), and i believe we are ready for another round.

In this thread you can post changes or features you would like to see in Mojolicious, no rules, just blurt away. :)

P.S.: Our official roadmap can still be found on GitHub (although it is almost empty now). https://github.com/kraih/mojo/issues?labels=future&state=open

--

sebastian

[sri]

json_like('/foo', qr/bar/, 'match') and also json_unlike would be quite nice to have for testing. Don't know if this has been suggested before.

Please be more specific, what would be the exact semantics? And how is it consistent with json_is, which does an is_deeply comparison?

--

sebastian 

[Richard Sugg]

It would be great to have some performance and load information available from within the app. For instance, to be able to report from within the app the number of workers, number of requests for each worker, etc.

[Alexander Karelas]

I don't know if it's technically possible, but I also support this request. I use blocking mode of Mojolicious w/ Hypnotoad, so it would be good to know how many of the workers are currently busy serving requests.

- Alex

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

[Alexander Karelas]

On 07/11/2014 06:45 PM, Alexander Karelas wrote:
> [...] it would be good to know how many of the workers are currently busy

in a machine-readable way.

[sri]

It would be great to have some performance and load information available from within the app. For instance, to be able to report from within the app the number of workers, number of requests for each worker, etc.

This can be done very easily with a plugin, a database like Redis, and a bunch of hooks.

--

sebstian

[sri]

json_like('/foo', qr/bar/, 'match') and also json_unlike would be quite nice to have for testing. Don't know if this has been suggested before.

Please be more specific, what would be the exact semantics? And how is it consistent with json_is, which does an is_deeply comparison?

Proposal accepted (for now)... after digging through some old code previously referenced on IRC.

    https://github.com/kraih/mojo/commit/94e5fe6e33ba0198bb69fcdb2834b34b0859bfe3

--

sebastian

[andrew fresh]

On Sun, Jul 06, 2014 at 06:12:50PM -0700, sri wrote:
> In this thread you can post changes or features you would like to see in
> Mojolicious, no rules, just blurt away. :)

I would love to see form handling in UserAgent to make filling out forms
easier. I hate having to specify every input in the form when I mostly
want defaults.

l8rZ,
--
andrew - http://afresh1.com

The 3 great virtues of a programmer: Laziness, Impatience, and Hubris.
--Larry Wall

[sri]

I would love to see form handling in UserAgent to make filling out forms
easier.  I hate having to specify every input in the form when I mostly
want defaults.

What would that look like?

--

sebastian 

[Daniel Mantovani]

Hope is not too late, my list:

  - Some kind of EventEmitter that allows you to subscribe and emit events from and to any process when using hypnotoad. I think it should support several backends (like Mojo::Plugin::Minion does), ie: File, Mango, Redis

  - SSH and Telnet clients on Mojo::IOLoop (meaning non-blocking clients). Probably not very demanded requests, but in my opinion they would help developers to choose mojolicious as a base framework for apps that concentrate several platforms with different interfaces (so you can choose using Mojo::UserAgent or for instance Mojo::SSHClient or Mojo::TelnetClient in a non-blocking way depending on what the target platform supports).

  - Some way to overwrite time for testing time related logic. I use an environment variable and read it, something like

                  $mytime = $ENV{MY_MOJO_FAKE_TIME} || time;

    (but I'm not sure if I'm reinventing the wheel here).

BR,

PS: about EventEmitter, I guess it wouldn't work but I never actually tried to use it for inter-process (toad) subscribe and emit. I just used it "intra-process" to subscribe to events that eventually come from a Redis backend from any process, and it worked fine. If EventEmitter already works among different process please just dismiss that point

El domingo, 6 de julio de 2014 22:12:50 UTC-3, sri escribió:

Soooo... it's been over 6 months since our last wishlist thread (https://groups.google.com/forum/#!searchin/mojolicious/wishlist/mojolicious/YK7SrFvEneY/uwr-TZAlGmcJ), a lot has happened since then (5.0 and Mojoconf, yay!), and i believe we are ready for another round.

In this thread you can post changes or features you would like to see in Mojolicious, no rules, just blurt away. :)

[sri]

  - Some kind of EventEmitter that allows you to subscribe and emit events from and to any process when using hypnotoad. I think it should support several backends (like Mojo::Plugin::Minion does), ie: File, Mango, Redis

I do like the idea of a message bus with pluggable backends, but i don't believe it's a common enough problem that it needs to be solved in Mojolicious.

  - SSH and Telnet clients on Mojo::IOLoop (meaning non-blocking clients). Probably not very demanded requests, but in my opinion they would help developers to choose mojolicious as a base framework for apps that concentrate several platforms with different interfaces (so you can choose using Mojo::UserAgent or for instance Mojo::SSHClient or Mojo::TelnetClient in a non-blocking way depending on what the target platform supports).

Haha, this one is way way way way way out there... i'm not even sure a non-blocking SSH client exists on CPAN yet.

 

  - Some way to overwrite time for testing time related logic. I use an environment variable and read it, something like

                  $mytime = $ENV{MY_MOJO_FAKE_TIME} || time;

Afraid i don't see the connection to Mojolicious.

--

sebastian

[andrew fresh]

Perhaps a wrapper to ->post( form => { ... } )?

my $tx = ...->res->forms( name => 'login' )
->submit({ user => 'me', password => '12345'});

being a shortcut to

my $form = ...->res->dom->at('form name[login]');
my $action = parse_action_from( $form );
my %inputs = parse_inputs_from( $form );
my $tx = $ua->post( $action => form => {
%inputs, user => 'me', password => '12345' } );

Where the parse_X_from are easy enough to write, but annoying.

# default to the first form on the page
perl -Mojo -E 'say g("http://localhost:3000")->res->forms
->submit( user => "me", pass => "sekret" )->dom->at("title")->text';

l8rZ,
--
andrew - http://afresh1.com

Hey, I think I see a barn up ahead.
-- The American Astronaut

[sri]

Perhaps a wrapper to ->post( form => { ... } )?

    my $tx = ...->res->forms( name => 'login' )
    ->submit({ user => 'me', password => '12345'});

being a shortcut to

    my $form = ...->res->dom->at('form name[login]');
    my $action = parse_action_from( $form );
    my %inputs = parse_inputs_from( $form );
    my $tx = $ua->post( $action => form => {
        %inputs, user => 'me', password => '12345' } );

And how does the response reference the user agent?

--

sebastian 

[andrew fresh]

On Sun, Jul 13, 2014 at 09:40:26AM -0700, sri wrote:
> > Perhaps a wrapper to ->post( form => { ... } )?
> >
> > my $tx = ...->res->forms( name => 'login' )
> > ->submit({ user => 'me', password => '12345'});
>

> And how does the response reference the user agent?

Sadly, no answer to that :-(

l8rZ,
--
andrew - http://afresh1.com

Computer Science: solving today's problems tomorrow.

[Brian Duggan]

On Saturday, July 12, sri wrote:
> - SSH and Telnet clients on Mojo::IOLoop (meaning non-blocking clients).
> > Probably not very demanded requests, but in my opinion they would help
> > developers to choose mojolicious as a base framework for apps that
> > concentrate several platforms with different interfaces (so you can choose
> > using Mojo::UserAgent or for instance Mojo::SSHClient or Mojo::TelnetClient
> > in a non-blocking way depending on what the target platform supports).
> >
>
> Haha, this one is way way way way way out there... i'm not even sure a
> non-blocking SSH client exists on CPAN yet.

We did something like this by using Mojo::Reactor->io to watch the output
of external ssh client processes :

https://metacpan.org/pod/distribution/Clustericious-Admin/bin/clad

Brian

[Daniel Mantovani]

Thanks for the feedback, took a look at the code and I think it's a nice way to integrate ssh tasks to Mojolicious. Not realy non-blocking in the way Mojo::UserAgent is though, as far as I understood it uses one process per ssh connection. (Mojo::UserAgent just runs inside the ioloop instead).

[Jan Henning Thorsen]

About SSH tasks:

Have you looked at https://metacpan.org/pod/Mojo::IOLoop::ReadWriteFork? (Feedback wanted)

[Daniel Mantovani]

Thanks Jan, knew it existed but had never take a close look before. I think it's perfect when you need to establish an SSH connection to some host, send a command, wait for the answer and tear down the connection, all that inside same controller and for some route. I guess it can be problematic if SSH connections or hosts slow down for some reason (timeout connection, slow command response, etc), because it will be difficult to control the amount of processes it would spawn and to be able to handle congestion nicely. As I am now getting convinced that a full non-blocking solution will be just too complicated to implement, I think I will go for a preforked solution, so you can configure for each particular host how many connections you would like to have to it, and each connection would read commands from a common queue and send command responses back to another queue. I have actually implemented such a solution based on perl threads and Thread::Queue. It works great, but for several other reasons I am planning to refactor it to work with a Mojolicious / Hypnotoad frontend (instead of today's CGI/Apache). When I took a look in the way Mojo::UserAgent interacts non-blocking with http hosts, I thought that something similar for SSH was the way to go, handling everything inside Mojolicious. But as I said before, probably a separated module with preforked SSH connections will be better. I think I will just need to connect current queues with something Mojolicious can handle, like using a Redis backend with Mojo::Redis to push and pop commands, answers and status, or a Mongo backend using either Minion or Mojo::Mango (haven't taken a close look on these last two though).

[sri]

    my $tx = ...->res->forms( name => 'login' )
    ->submit({ user => 'me', password => '12345'});

We are currently considering the addition of a Mojo::DOM::val method (like in jQuery, but with support for entire forms) as a first step.

    http://pastie.org/9414616

--

sebastian

[sri]

We are currently considering the addition of a Mojo::DOM::val method (like in jQuery, but with support for entire forms) as a first step.

    http://pastie.org/9414616

Here's also a one-liner, the hash has the same format $ua->post($url => form => {...}) would use.

    $ perl -Ilib -Mojo -E 'say r g("github.com")->dom->find("form")->last->val' 

    {"authenticity_token" => "FGsjskskdw;dsd;akdw;odkaw;dkaw;2344;ska;sdkad;akdw;doakw==", "source_label" => "Homepage Form"}

--

sebastian 

[sri]

We are currently considering the addition of a Mojo::DOM::val method (like in jQuery, but with support for entire forms) as a first step.

A more complete patch is now available in a branch, chances of it getting applied are currently 50:50, due to some problems with handling buttons.

    https://github.com/kraih/mojo/compare/val

Feedback welcome!

--

sebastian

[sri]

SOCKS 4/5 proxy support for Mojo::UserAgent :)

Looks like SOCKS5 support is going to be in Mojolicious 5.22. :)

    https://rt.cpan.org/Public/Bug/Display.html?id=97533#txn-1391985

--

sebastian 

[Tim]

Thanks for adding socks support.

I tested it with a non working proxy and got error messages in an infinite loop.

[error] Timeout

[error] Timeout

[error] Timeout

[error] Timeout

[...]

[error] Authentication with socks proxy failed

[error] Authentication with socks proxy failed

[error] Authentication with socks proxy failed

[...]

[Sebastian Riedel]

> I tested it with a non working proxy...

Could this description be any more vague?

perl -Mojo -E 'my $ua = Mojo::UserAgent->new;
$ua->proxy->http("socks://mojolicio.us:80"); say r
$ua->get("metacpan.org")->res->error'
{
"message" => "Connect timeout"
}

I'm unable to replicate your problem.

--
Sebastian Riedel
http://mojolicio.us
http://github.com/kraih
http://twitter.com/kraih

[Tim]

Here is a simple example. The error only occurs sometimes.

I tested it with some socks proxies from http://proxylist.hidemyass.com/.

my $ua = Mojo::UserAgent->new;

$ua->proxy->http("socks://" . shift);

$ua->get('http://checkip.dyndns.com/', sub {

    my($ua, $tx) = @_;

    say $tx->req->url;

    if(my $e=$tx->error) {

        say $e->{message};

    }else {

        say $tx->res->body;

    }

});

Mojo::IOLoop->start;

read: Connection reset by peer

Mojo::Reactor::Poll: Read failed: Mojo::UserAgent: read: Connection reset by peer at /Library/Perl/5.16/Mojo/EventEmitter.pm line 19.

Mojo::Reactor::Poll: Read failed: Mojo::UserAgent: read: Connection reset by peer at /Library/Perl/5.16/Mojo/EventEmitter.pm line 19.

Mojo::Reactor::Poll: Read failed: Mojo::UserAgent: read: Connection reset by peer at /Library/Perl/5.16/Mojo/EventEmitter.pm line 19.

Mojo::Reactor::Poll: Read failed: Mojo::UserAgent: read: Connection reset by peer at /Library/Perl/5.16/Mojo/EventEmitter.pm line 19.

[...]

[sri]

read: Connection reset by peer

Mojo::Reactor::Poll: Read failed: Mojo::UserAgent: read: Connection reset by peer at /Library/Perl/5.16/Mojo/EventEmitter.pm line 19.

Mojo::Reactor::Poll: Read failed: Mojo::UserAgent: read: Connection reset by peer at /Library/Perl/5.16/Mojo/EventEmitter.pm line 19.

Mojo::Reactor::Poll: Read failed: Mojo::UserAgent: read: Connection reset by peer at /Library/Perl/5.16/Mojo/EventEmitter.pm line 19.

Mojo::Reactor::Poll: Read failed: Mojo::UserAgent: read: Connection reset by peer at /Library/Perl/5.16/Mojo/EventEmitter.pm line 19.

Thanks, fixed.

    https://github.com/kraih/mojo/commit/01013463f1c56df3425faa39b4be56aa734b71df

--

sebastian 

[Andrey Khozov]

It would be nice if the minion worker in debug mode watched for file changes and restarted if need (as morbo server)

--
Andrey Khozo

​v​

[Nikita Dubrovin]

An advanced session manager like MojoX::Session?

понедельник, 7 июля 2014 г., 5:12:50 UTC+4 пользователь sri написал:

[perlpong]

The ablility to pass a filehandle to Mojo::Upload::move_to, instead of a filename.

It would be useful for moving uploaded files to temporary files without creating a race condition.

I want to be able to do this:

$upload->move_to( File::Temp->new );

[Viktor Nacht]

Making 'field-with-error' something you can set, e.g.

app->validator->error_class('has-error')

Use case is easier integration with Bootstrap (and similar), dealing with legacy code, and UI/Backend teams that don't communicate well. :)

I love the elegance of the validation feature, but locking in a class doesn't seem ideal. 

V

[sri]

Making 'field-with-error' something you can set, e.g.

app->validator->error_class('has-error')

There's already a helper that can be redefined.

    http://mojolicio.us/perldoc/Mojolicious/Plugin/TagHelpers#tag_with_error

--

sebastian 

[Jan Henning Thorsen]

Viktor: Mojolicious::Plugin::Bootstrap3 include styling for "field-with-error": https://metacpan.org/pod/Mojolicious::Plugin::Bootstrap3#Non-standard-files

--
You received this message because you are subscribed to a topic in the Google Groups "Mojolicious" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/mojolicious/mIRRwNwDLSE/unsubscribe.
To unsubscribe from this group and all its topics, 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.

[Per Carlson]

Hi.

When using Test::Mojo sometimes you want to extract some info the rendered data. The standard way to do that is installing an "after_render" hook.

I would like to propose a more integrated way to do this, so you could have different "peek/extract" methods in the "test chain", like:

my $t = Test::Mojo->new;

my $location;

$t->post_ok('/users' => { name => 'John Doe', age => 42 })

  ->status_is(201)  # created

  ->header_like(Location => qr!/users/\d+!)

  ->peek(sub { my $res = shift; $location = $res->headers->location });

$t->get_ok($location)

  ->status_is(200)

  ->content_like(qr!user = John Doe!)

  ->content_like(qr!age = 42!);

The sub in the "peek" method is passed one object, the current "Mojo::Message::Response" object.

The use case is ease testing of routes which do create resources.

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

--
Pelle

Research is what I'm doing when I don't know what I'm doing.
- Wernher von Braun

[Jan Henning Thorsen]

Pelle: you could just use $t->tx->res after $t->get_ok():

  $t->get_ok($t->tx->res->headers->location);

To unsubscribe from this group and all its topics, send an email to mojolicious+unsubscribe@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.

--
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+unsubscribe@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.

[Per Carlson]

Hi Jan Henning.

That was indeed a clever idea!

I wasn't aware you could reuse the $tx object from last call, and that will invalidate my wishlist request.

The docs for "Test::Mojo->tx" do give a clue that "$t->tx" lives between "$t->X_ok" calls, but that wasn't very obvious to me.

Thanks for the hint!

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.

[Jan Henning Thorsen]

You're welcome Pelle :)

[Alexander Karelas]

I'd like to see the Validation thingy working on JSON parameters ($c->req->json)

- Alex

On 07/07/2014 04:12 AM, sri wrote:

Soooo... it's been over 6 months since our last wishlist thread (https://groups.google.com/forum/#!searchin/mojolicious/wishlist/mojolicious/YK7SrFvEneY/uwr-TZAlGmcJ), a lot has happened since then (5.0 and Mojoconf, yay!), and i believe we are ready for another round.

In this thread you can post changes or features you would like to see in Mojolicious, no rules, just blurt away. :)

P.S.: Our official roadmap can still be found on GitHub (although it is almost empty now). https://github.com/kraih/mojo/issues?labels=future&state=open

--

sebastian

--

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.

[sri]

I'd like to see the Validation thingy working on JSON parameters ($c->req->json)

For that it would have to work on nested data structures, and i've not seen any proposals for that yet. Just a few weeks ago i actually proposed support for array and hash GET/POST parameters (foo[], foo[bar], foo[bar][baz], foo[3][bar]...), which could have led to this, but sadly there was no interest at the time.

--

sebastian 

[Alexander Karelas]

What I was expecting was an interface such as this:

$validation->required_json('person/address/number')->range(10, 20)

Couldn't this be done without what you described below?

- Alex

[sri]

$validation->required_json('person/address/number')->range(10, 20)

Couldn't this be done without what you described below?

Doubt it.

--

sebastian 

[sri]

Quick update, we now accept feature requests on GitHub again.

    https://github.com/kraih/mojo/commit/fa227b296b8b19ffddfe4044fe10d538bcff1234

That also means we will need more help from the community, or issues may just stay open forever.

--

sebastian