Discussion:
Wishlist thread (third edition)
(too old to reply)
sri
2015-06-15 13:58:17 UTC
Permalink
It's been almost a year since our last wishlist thread
(https://groups.google.com/forum/#!searchin/mojolicious/wishlist/mojolicious/mIRRwNwDLSE/jw-7w48Z7E4J),
so i think it is time for another round!

In this thread you can post changes or features you would like to see in
Mojolicious, no rules, just say what's on your mind. ;)

P.S.: Quite a few of the features requested last time have actually been
implemented in the meantime, like SOCKS5 support and non-blocking name
resolution.

--
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.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
hertzhaft
2015-06-15 17:55:33 UTC
Permalink
Hi sri,

here are my three wishes:

1. in a Mojolicious app, it would be nice to be able to run selected tests
from the "t" directory more easily, like so:
myapp test -v test3 test5

Currently I have to do
myapp test -v ~/experiments/mojo/myapp/t/test3
~/experiments/mojo/myapp/t/test5

Maybe Mojolicious::Command::test could first check for each argument if a
file with that name exists in the t directory?

2. it would be nice if a Mojolicious app could display descriptions and
usage on the command line for all Command packages in the app.
Currently it picks up only those that have their own files. My command
packages are often so short that it's more handy to have them in the app
file itself.

3. I work a lot with Mojo::Collections and find myself often writing code
like "push @{$self->item->fields}, $something". I would suggest to add
methods push, pop, unshift, shift and list to the module (which would
operate on the collection and not create a new one). This way one could
avoid the unwieldy array dereference and even chain the methods like this:
$self->item->fields->push($something)->each(sub {...}).

The pop and shift methods would be useful when the collection contains
objects with methods.
The list method should just return the dereferenced collection (like
@$collection).
I know a similar proposal has been declined before, but I think it would
make code more readable and more conform to the Mojo feel :-)

Love it!

Martin
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
sri
2015-06-15 18:03:05 UTC
Permalink
Post by hertzhaft
The pop and shift methods would be useful when the collection contains
objects with methods.
The first/last methods seem more useful for method chains.
($dom->find('div')->last->text)
Post by hertzhaft
The list method should just return the dereferenced collection (like
@$collection).
This already exists, you just call the each method without an argument. (my
@elements = $dom->find('div')->each)

--
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.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
sri
2015-06-15 18:06:02 UTC
Permalink
Post by hertzhaft
2. it would be nice if a Mojolicious app could display descriptions and
usage on the command line for all Command packages in the app.
Currently it picks up only those that have their own files. My command
packages are often so short that it's more handy to have them in the app
file itself.
I don't think this is possible.

--
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.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
hertzhaft
2015-06-16 13:29:20 UTC
Permalink
Post by hertzhaft
2. it would be nice if a Mojolicious app could display descriptions and
Post by hertzhaft
usage on the command line for all Command packages in the app.
Currently it picks up only those that have their own files. My command
packages are often so short that it's more handy to have them in the app
file itself.
I don't think this is possible.
--
sebastian
Below is an example using Symbol::Table (which unfortunately is not in
core).

Martin

- - 8< - - - - - - -
package Mojolicious::Command::task;
use Mojo::Base 'Mojolicious::Command';

has description => 'Run a task';
has usage => "Usage: APPLICATION task [ARGS]\n";

sub run { shift->app->task(@_) };

package main;
use Symbol::Table;

my $package = "Mojolicious::Command";
my $st = Symbol::Table->New('PACKAGE', $package);
foreach my $subpkg (keys(%$st)) {
print "Package $package contains commmand '$subpkg'\n";
my $cmd = "${package}::$subpkg";
print $cmd->new->usage;
}
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
sri
2015-06-16 15:26:27 UTC
Permalink
Post by hertzhaft
2. it would be nice if a Mojolicious app could display descriptions and
usage on the command line for all Command packages in the app.
Currently it picks up only those that have their own files. My command
packages are often so short that it's more handy to have them in the app
file itself.
And implemented. :)


https://github.com/kraih/mojo/commit/9d6990627b7251adb98a3c8c25b27fe66f5cb979

--
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.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
hertzhaft
2015-06-16 15:37:21 UTC
Permalink
Wow, that was really fast! Thanks! I think this feature could be useful in
other contexts, too.

What about my first wish, the tests? Any comment (not meaning to nag :-))?

Martin
Post by hertzhaft
2. it would be nice if a Mojolicious app could display descriptions and
Post by hertzhaft
usage on the command line for all Command packages in the app.
Currently it picks up only those that have their own files. My command
packages are often so short that it's more handy to have them in the app
file itself.
And implemented. :)
https://github.com/kraih/mojo/commit/9d6990627b7251adb98a3c8c25b27fe66f5cb979
--
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.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
sri
2015-06-16 15:53:48 UTC
Permalink
Post by hertzhaft
What about my first wish, the tests? Any comment (not meaning to nag :-))?
Very unlikely, the test command is really just meant as an example and even
the documentation recommends the use of "prove".

--
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.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Ludwig Nussel
2015-06-16 07:31:44 UTC
Permalink
Post by sri
It's been almost a year since our last wishlist thread
(https://groups.google.com/forum/#!searchin/mojolicious/wishlist/mojolicious/mIRRwNwDLSE/jw-7w48Z7E4J),
so i think it is time for another round!
In this thread you can post changes or features you would like to see
in Mojolicious, no rules, just say what's on your mind. ;)
My wish would be to allow storing secrets in the database :-)

https://groups.google.com/forum/#!searchin/mojolicious/secrets/mojolicious/5HraN26QGvo/7rp2EW6wiPkJ

cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
sri
2015-06-16 10:11:53 UTC
Permalink
Post by Ludwig Nussel
My wish would be to allow storing secrets in the database :-)
What is preventing that now? As far as i can see, you can just query the
database during startup.

--
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.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Ludwig Nussel
2015-06-17 11:40:15 UTC
Permalink
Post by Ludwig Nussel
My wish would be to allow storing secrets in the database :-)
What is preventing that now? As far as i can see, you can just query
the database during startup.
It's been a while since I investigated that issue. IIRC one of the
pitfalls was that one cannot run e.g. script/my_app help or
script/my_app test without an initialized and accessible database
anymore, even though both commands don't actually need a fully set
up app.

cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard,
Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
o***@gmail.com
2015-06-16 10:55:46 UTC
Permalink
Hello,

I wish there was an easy way to configure a "base_path" for Mojolicious
without having to modify the application's code.

Today the only ways to modify the base_path is to use a before_dispatch
hook or to use a plugin like M::P::RequestBase.

But when you are use a Mojo application from CPAN like mojopaste, you are
not supposed to modify it. And anyway, a system administrator should not
have to modify the application to deploy it the way he wants.

I think it would be great if we could set the base_path in the "listen"
string like : listen => ['http://*/prefix:3000']

Or we could just add a "base_path" option.

Thanks!
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Luc didry
2015-06-16 11:08:21 UTC
Permalink
Post by o***@gmail.com
Hello,
I wish there was an easy way to configure a "base_path" for Mojolicious
without having to modify the application's code.
Today the only ways to modify the base_path is to use a before_dispatch
hook or to use a plugin like M::P::RequestBase.
But when you are use a Mojo application from CPAN like mojopaste, you are
not supposed to modify it. And anyway, a system administrator should not
have to modify the application to deploy it the way he wants.
I think it would be great if we could set the base_path in the "listen"
string like : listen => ['http://*/prefix:3000']
Or we could just add a "base_path" option.
+1 for a base_path feature !
--
Luc
http://www.fiat-tux.fr/
Internet n'est pas compliqué, Internet est ce que vous en faites.
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
sri
2015-06-16 11:27:34 UTC
Permalink
Post by o***@gmail.com
I think it would be great if we could set the base_path in the "listen"
string like : listen => ['http://*/prefix:3000']
Or we could just add a "base_path" option.
This proposal ignores many problems, such as alternative deployment methods
like PSG/CGI, and the inconsistency with the proxy option.

--
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.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Helmut Wollmersdorfer
2015-06-18 11:02:56 UTC
Permalink
Post by o***@gmail.com
I think it would be great if we could set the base_path in the "listen"
Post by o***@gmail.com
string like : listen => ['http://*/prefix:3000']
Or we could just add a "base_path" option.
This proposal ignores many problems, such as alternative deployment
methods like PSG/CGI, and the inconsistency with the proxy option.
I strongly agree with sri in this problem. In practice this leads to
unsolvable problems, especially across different deployment platforms.

Been there, tried this, wasted time.
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Ben van Staveren
2015-06-16 12:18:30 UTC
Permalink
I'd love to see a way where Mojolicious autoloads plugins if told to do so
in configuration file or perhaps by naming convention. Given the request
base thing, it'd solve that and let people perhaps solve that particular
wish. I'd have use for it because I keep repeating the same boilerplate in
my startup function that just loads plugins, be easier to run them out of a
configuration file.
It's been almost a year since our last wishlist thread (
https://groups.google.com/forum/#!searchin/mojolicious/wishlist/mojolicious/mIRRwNwDLSE/jw-7w48Z7E4J),
so i think it is time for another round!
In this thread you can post changes or features you would like to see in
Mojolicious, no rules, just say what's on your mind. ;)
P.S.: Quite a few of the features requested last time have actually been
implemented in the meantime, like SOCKS5 support and non-blocking name
resolution.
--
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
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+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
sri
2015-06-16 12:55:23 UTC
Permalink
Post by Ben van Staveren
I'd love to see a way where Mojolicious autoloads plugins if told to do so
in configuration file or perhaps by naming convention.
Sounds like something that can be easily prototyped on CPAN with a plugin.

--
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.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Ben van Staveren
2015-06-16 13:47:15 UTC
Permalink
True, but the idea would be to make all apps do it without having to
explicitly code for it, but it would indeed make a suitable plug-in too
Post by Ben van Staveren
I'd love to see a way where Mojolicious autoloads plugins if told to do so
Post by Ben van Staveren
in configuration file or perhaps by naming convention.
Sounds like something that can be easily prototyped on CPAN with a plugin.
--
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
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+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
sri
2015-06-17 11:01:05 UTC
Permalink
Post by Ben van Staveren
True, but the idea would be to make all apps do it without having to
explicitly code for it, but it would indeed make a suitable plug-in too.
This has been discussed on IRC today, and the only way to get it into
Mojolicious core will be a very popular plugin on CPAN.

--
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.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Ben van Staveren
2015-06-17 11:25:36 UTC
Permalink
guess I've got me a weekend project then :D
Post by Ben van Staveren
True, but the idea would be to make all apps do it without having to
Post by Ben van Staveren
explicitly code for it, but it would indeed make a suitable plug-in too.
This has been discussed on IRC today, and the only way to get it into
Mojolicious core will be a very popular plugin on CPAN.
--
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
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+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Luc didry
2015-06-16 12:45:56 UTC
Permalink
Post by sri
It's been almost a year since our last wishlist thread
(https://groups.google.com/forum/#!searchin/mojolicious/wishlist/mojolicious/mIRRwNwDLSE/jw-7w48Z7E4J),
so i think it is time for another round!
In this thread you can post changes or features you would like to see in
Mojolicious, no rules, just say what's on your mind. ;)
P.S.: Quite a few of the features requested last time have actually been
implemented in the meantime, like SOCKS5 support and non-blocking name
resolution.
I would love a way to use a personnal boilerplate when generating a new app.

Something like this:
mojo generate app MyApp -b ~/.mojo/my_boilerplate

~/.mojo/my_boilerplate/ directory should be a mojo app, which name (let's say Boilerplate) would be replaced by the name of the generated app: lib/Boilerplate.pm would be renamed to lib/Myapp.pm, script/boilerplate to script/my_app and so on.

Maybe ~/.mojo could be a default directory, allowing to use the command like this:
mojo generate app MyApp -b my_boilerplate

And maybe you could still specify the whole path if you don't want to use ~/.mojo directory:
mojo generate app MyApp -b ~/mojo_boilerplate/boilerplate
--
Luc
http://www.fiat-tux.fr/
Internet n'est pas compliqué, Internet est ce que vous en faites.
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Olivier Duclos
2015-06-16 12:51:02 UTC
Permalink
+1 for module auto-loading. That would be a very powerful feature.
Post by Luc didry
Post by sri
It's been almost a year since our last wishlist thread
(https://groups.google.com/forum/#!searchin/mojolicious/wishlist/mojolicious/mIRRwNwDLSE/jw-7w48Z7E4J),
so i think it is time for another round!
In this thread you can post changes or features you would like to see in
Mojolicious, no rules, just say what's on your mind. ;)
P.S.: Quite a few of the features requested last time have actually been
implemented in the meantime, like SOCKS5 support and non-blocking name
resolution.
I would love a way to use a personnal boilerplate when generating a new app.
mojo generate app MyApp -b ~/.mojo/my_boilerplate
~/.mojo/my_boilerplate/ directory should be a mojo app, which name (let's say Boilerplate) would be replaced by the name of the generated app: lib/Boilerplate.pm would be renamed to lib/Myapp.pm, script/boilerplate to script/my_app and so on.
mojo generate app MyApp -b my_boilerplate
mojo generate app MyApp -b ~/mojo_boilerplate/boilerplate
--
Luc
http://www.fiat-tux.fr/
Internet n'est pas compliqué, Internet est ce que vous en faites.
--
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/hZu18SdEmbc/unsubscribe.
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+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
sri
2015-06-16 12:56:21 UTC
Permalink
Post by Luc didry
I would love a way to use a personnal boilerplate when generating a new app.
Also sounds like something that should be prototyped on CPAN with a plugin.

--
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.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
b***@keele.ac.uk
2015-06-17 11:58:35 UTC
Permalink
Not a feature, but I'd ask for something in the vein of Helmut's wish #1
<https://groups.google.com/d/msg/mojolicious/mIRRwNwDLSE/YgsxRYtnah8J> and
expand the documentation for a couple of deeply worked examples. Still
quite new to Mojolicious, I'm working my way through the docs to implement
authenticated sessions for a site and would've appreciated something that
packages all the pieces together: put authentication here, all
authenticated routes go here, non-authenticated routes go over there,
handle authentication failures and logouts this way and implement mixed
http/https calls like so. If this was one chapter in a book, I'd buy the
whole thing just for that as I have this feeling that I'm still missing
something either conceptually or in code.

The quality of the documentation is such that I've been able to get this
far without resorting to the mailing list, something that I maybe should
have done earlier.

best,
Boyd
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
sri
2015-06-17 12:34:57 UTC
Permalink
If this was one chapter in a book, I'd buy the whole thing just for that
as I have this feeling that I'm still missing something either conceptually
or in code.
Not a day goes by where someone doesn't ask for a Mojolicious book, sadly
we are still lacking an author.

--
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.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Stefan Adams
2015-06-18 15:02:00 UTC
Permalink
Post by b***@keele.ac.uk
expand the documentation for a couple of deeply worked examples. Still
quite new to Mojolicious, I'm working my way through the docs to implement
authenticated sessions for a site and would've appreciated something that
packages all the pieces together: put authentication here, all
authenticated routes go here, non-authenticated routes go over there,
handle authentication failures and logouts this way and implement mixed
http/https calls like so.
I second this! The Blog example of Mojo::Pg
<https://github.com/kraih/mojo-pg/tree/master/examples/blog> is really
awesome. We just used it to build a replacement
<https://github.com/KeystoneIT/Ama> for Google Moderator
<https://www.google.com/moderator/> (since it's shutting down in two weeks)!

It would be great to have the simple blog example be expanded to have an
Ajax interface that did not do a page refresh for each action, use
non-blocking form in the Mojo::Pg models, and have a simple authentication
system with authorization requirements for specific routes.

Just like with the blog example, each of the additional examples wouldn't
need to be much, just enough to demonstrate best practices.
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Stefan Adams
2015-06-18 22:50:38 UTC
Permalink
Post by Stefan Adams
It would be great to have the simple blog example be expanded to have an
Ajax interface that did not do a page refresh for each action, use
non-blocking form in the Mojo::Pg models, and have a simple authentication
system with authorization requirements for specific routes.
Just like with the blog example, each of the additional examples wouldn't
need to be much, just enough to demonstrate best practices.
Additionally, it would be great for this enhanced example app to also have
a full suite of tests.

I can understand that you wouldn't want to include such an example app in
Mojolicious core because of the unmet dependencies (such as Mojo::Pg).
Perhaps a separate project repo whose sole purpose is to tie all these
things (Mojolicious, Mojo::Pg, Minion) together and include a few
additional routine bells and whistles like auth/authz, websockets,
non-blocking database model, ajax user interface, etc and have a suite of
tests to make the whole thing test-driven!

I would buy another limited edition shirt. Probably even a couple! :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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
sri
2015-06-19 12:56:41 UTC
Permalink
Post by Stefan Adams
It would be great to have the simple blog example be expanded to have an
Ajax interface that did not do a page refresh for each action, use
non-blocking form in the Mojo::Pg models, and have a simple authentication
system with authorization requirements for specific routes.
It's very unlikely that i'll be able to make more example apps, but anyone
here is welcome to fork and extend the existing ones.

--
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.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Stefan Adams
2015-08-07 17:01:09 UTC
Permalink
I'm not sure if this is something that makes sense to include in core as I
don't know much about it, but I hope it doesn't hurt to ask...

Websockets are built in to mojolicious and available out of the box. Would
it be possible and in line with project mission to do something similar for
WebRTC?
Post by Stefan Adams
It would be great to have the simple blog example be expanded to have an
Post by Stefan Adams
Ajax interface that did not do a page refresh for each action, use
non-blocking form in the Mojo::Pg models, and have a simple authentication
system with authorization requirements for specific routes.
It's very unlikely that i'll be able to make more example apps, but anyone
here is welcome to fork and extend the existing ones.
--
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
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+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
sri
2015-08-07 17:08:56 UTC
Permalink
Would it be possible and in line with project mission to do something
similar for WebRTC?
WebRTC is crazy complicated, so even if we wanted to do it, i doubt we
currently have the resources.

--
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.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
sri
2015-08-07 17:13:50 UTC
Permalink
Post by sri
WebRTC is crazy complicated, so even if we wanted to do it, i doubt we
currently have the resources.
Same problem we already have with HTTP/2 actually.

--
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.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Roger Crew
2015-06-17 22:53:28 UTC
Permalink
could we maybe have a generic [hmac_]sha_foo in Mojo::ByteStream and
Mojo::Util that always points to the currently Best Known [Keyed] Hash,

rather than hardwiring SHA1 into everything -- and in particular having it
be
the only choice for signed cookies and session keys -- which makes me a bit
nervous
seeing as we're really all supposed to be using SHA256 by now.

(and so that whenever it is in the next 5-10 years that something bad
turns up in SHA2, we'll be ready to swap in SHA3)
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
sri
2015-06-17 23:24:21 UTC
Permalink
Post by Roger Crew
rather than hardwiring SHA1 into everything -- and in particular having it
be
the only choice for signed cookies and session keys -- which makes me a
bit nervous
seeing as we're really all supposed to be using SHA256 by now.
Since when is HMAC-SHA1 a problem? Did i miss any new research?

--
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.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Roger Crew
2015-10-10 02:58:55 UTC
Permalink
Post by Roger Crew
rather than hardwiring SHA1 into everything -- and in particular having it
Post by Roger Crew
be
the only choice for signed cookies and session keys -- which makes me a
bit nervous
seeing as we're really all supposed to be using SHA256 by now.
Since when is HMAC-SHA1 a problem? Did i miss any new research
well, this came out today
<http://arstechnica.com/security/2015/10/sha1-crypto-algorithm-securing-internet-could-break-by-years-end/>,
though I'll grant it's only a somewhat more dire version of what Bruce
Schneier was saying 4 years ago
<https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html>,

and yes I get that HMAC is different
(and maybe even HMAC-MD5 is still safe even if I wouldn't want to bet the
farm on it 10 years from now),

but you do have a number of places using unadorned SHA1
(including one where I'm really *not* sure why you're *not* using HMAC
see DefaultHelpers::_csrf_token)

and it seems to me if you genericize (use "...sha_sum" everywhere, point it
to whatever is best-practice these days, let overly paranoid folks like me
bump it up to SHA3 in the config file if we want) then you're basically
done with this forever (ha ha...)
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
sri
2015-10-10 09:08:12 UTC
Permalink
Post by Roger Crew
but you do have a number of places using unadorned SHA1
(including one where I'm really *not* sure why you're *not* using HMAC
see DefaultHelpers::_csrf_token)
The CSRF token just needs to be a reasonably random value, the hash
algorithm is irrelevant.

--
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.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Roger Crew
2015-10-12 10:05:22 UTC
Permalink
Post by Roger Crew
but you do have a number of places using unadorned SHA1
Post by Roger Crew
(including one where I'm really *not* sure why you're *not* using HMAC
see DefaultHelpers::_csrf_token)
The CSRF token just needs to be a reasonably random value, the hash
algorithm is irrelevant.
The CSRF token needs to be unguessable by an attacker.
steady_time() is little more than a counter and rand() shouldn't really be
relied on to be unguessable either.
Which, I assume, is why you're prepending a secret key and hashing the
result.

But this is exactly the problem that HMAC is intended to solve

hmac_sha1_sum ( steady_time . rand(999), $c->app->secrets->[0] )

then no one has to worry about padding oracle attacks or any of that shit..)
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Viktor Nacht
2015-06-18 00:34:37 UTC
Permalink
Rerequest for a way to set a custom error class name to override
field-with-error in TagHelpers. I believe this has been rejected before. :)
- V
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Ben van Staveren
2015-06-18 03:22:45 UTC
Permalink
Small wish: the ability to see if a plug-in has been loaded (eg
$self->has_plugin(...) or something similar)
Post by Viktor Nacht
Rerequest for a way to set a custom error class name to override
field-with-error in TagHelpers. I believe this has been rejected before.
:) - V
--
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
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+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
sri
2015-06-18 11:02:37 UTC
Permalink
Post by Ben van Staveren
Small wish: the ability to see if a plug-in has been loaded (eg
$self->has_plugin(...) or something similar)
Brings back the old question of what problem this would actually solve? If
you depend on a certain helper, can't you just check for that? What about
plugins that get loaded multiple times, like Mojolicious::Plugin::Mount?

--
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.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Ben van Staveren
2015-06-18 13:08:40 UTC
Permalink
For an autoload-bunch-of-plugins plugin it's sort of essential to avoid
loading things multiple times if not needed, thats kind of the only reason
I'd want it.
Post by Ben van Staveren
Small wish: the ability to see if a plug-in has been loaded (eg
Post by Ben van Staveren
$self->has_plugin(...) or something similar)
Brings back the old question of what problem this would actually solve? If
you depend on a certain helper, can't you just check for that? What about
plugins that get loaded multiple times, like Mojolicious::Plugin::Mount?
--
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
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+***@googlegroups.com.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
sri
2015-06-18 11:03:12 UTC
Permalink
Post by Viktor Nacht
Rerequest for a way to set a custom error class name to override
field-with-error in TagHelpers.
Is there an actual use case?

--
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.
To post to this group, send email to ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
Luc didry
2015-06-18 11:39:50 UTC
Permalink
Post by sri
Post by Viktor Nacht
Rerequest for a way to set a custom error class name to override
field-with-error in TagHelpers.
Is there an actual use case?
Yes: using the error class from twitter bootstrap (or any other css framework).

I agree with Ben, it could be really useful.
--
Luc
http://www.fiat-tux.fr/
Internet n'est pas compliqué, Internet est ce que vous en faites.
--
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 ***@googlegroups.com.
Visit this group at http://groups.google.com/group/mojolicious.
For more options, visit https://groups.google.com/d/optout.
sri
2015-06-18 11:44:15 UTC
Permalink
Post by Luc didry
Yes: using the error class from twitter bootstrap (or any other css framework).
And you can't do that by redefining the tag_with_error helper?

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