The web in a box - a next generation web framework for the Perl programming language

IRC log for #mojo, 2017-03-10

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:19 sugar_ joined #mojo
01:18 aborazmeh joined #mojo
02:25 dave hey guys, just noticed a typo at: http://mojolicious.org/perldoc/Mojolicious/Guides/Tutorial#User-agent
02:25 dave look at the non-blocking example...there's a missing right paren
02:27 dave wait ... nm ... my browser has a rendering error there O.o ... sorry to bother you
02:47 sugar_ joined #mojo
02:49 asarch joined #mojo
03:45 noganex joined #mojo
03:53 zivester joined #mojo
03:57 litwol joined #mojo
04:41 inokenty-w joined #mojo
05:04 dboehmer joined #mojo
05:37 irqq_ joined #mojo
06:15 marty_ joined #mojo
06:53 stryx` joined #mojo
07:03 dod joined #mojo
07:49 AndrewIsh joined #mojo
08:14 trone joined #mojo
08:53 rshadow joined #mojo
09:03 sugar_ joined #mojo
09:08 salv0 joined #mojo
09:23 prg joined #mojo
09:29 prg joined #mojo
09:41 sugar_ joined #mojo
10:07 itaipu joined #mojo
10:30 sugar_ joined #mojo
10:36 itaipu joined #mojo
10:37 irqq joined #mojo
11:08 tchaves joined #mojo
11:12 sugar_ joined #mojo
11:17 tchaves joined #mojo
11:50 rshadow joined #mojo
11:59 aborazmeh joined #mojo
11:59 rshadow joined #mojo
12:35 aborazmeh joined #mojo
12:47 rshadow joined #mojo
12:53 rshadow joined #mojo
12:56 rshadow joined #mojo
13:02 sugar_ joined #mojo
14:13 sugar_ joined #mojo
14:37 gizmomathboy joined #mojo
14:43 * sri needs to talk to Akron
14:43 sri the CHI plugin really sucks for testing
14:51 sugar_ joined #mojo
15:12 sri in case anyone wants to know, you can reset it with a different config in your test with "delete $t->app->chi_handles->{default}; $t->app->plugin(CHI => {default => {...}});"
15:12 sri not particularly comfortable
15:13 sri brings back the old topic of how to do testing with apps and config files
15:13 sri and that there's no easy way to override the config file before the app calls ->startup
15:40 rshadow joined #mojo
16:03 zivester joined #mojo
16:04 mishanti1 sri: for our tests we've gone the slightly ugly route of using Test::MockModule and mocking `app->config()` so that we can serve test-specific configuration.
16:05 mishanti1 Not sure if that's the same thing as what you are looking into though.
16:09 jabberwok i wound up with a config file with a hash like this, to select for different modes: » db => { production => 'postgresql://user@/prod_db', test => 'postgresql://user@/test_db' ... } « and then using » $db = DBIx::TempDB->new($dbname); « in the case of 'test' mode.
16:27 itaipu joined #mojo
16:45 jberger jabberwok: you can just do that with the actual mode
16:45 jberger make a config file called myapp.test.conf and run the tests with MOJO_MODE=test
16:46 jberger which is something we do at $work in certain projects
16:46 sh14 joined #mojo
16:48 sri we do need a good solution for that
16:48 sri really too bad tests don't automatically use the mode test
16:49 rshadow joined #mojo
16:55 jberger sri: the biggest problem for that is say you have a db connection string to a test database that say you CI has
16:55 jberger but now in my local environment I want to run my tests before commiting and I have a local test database
16:56 jberger its just not an easy problem to solve
16:56 sri and then there's the problem with per test settings
16:57 sri like postgres search_path
17:02 jberger right
17:02 jberger I built a system of test helpers for that in my tests
17:03 jberger but it really isn't generic in any way
17:09 sugar_ joined #mojo
17:13 jabberwok Ahh jberger I had missed the bit in Plugin::Config about the mode.
17:14 jberger its a really handy thing
17:14 jberger for lots of phases
17:18 sri now that i think about it
17:18 sri we do allow attribute values to be passed to MyApp->new(...)
17:19 sri Test::Mojo should have a way to set a config that perhaps somehow overrides the plugin config
17:19 sri hmm
17:20 jberger that'd be interesting
17:20 sri the attribute bit is less important for this... i guess the plugin would need a switch to allow it to be disabled
17:21 sri Test::Mojo->new(MyApp => {pg => '...', chi => {...}});
17:22 sri and it sets maybe MyApp->new(config => {'mojo.no_config_plugin' => 1, %$test_config})
17:22 sri and the plugin bails when it sees the setting exists already
17:22 jberger I want to just offer one thing to keep in mind though
17:23 jberger I think the relative simplicity of our config system is very helpful
17:23 sri this doesn't really make it harder though
17:23 sri just offers an override for test
17:23 sri *tests
17:24 jberger but how would that work
17:24 jberger it would have to prevent your call to $app->plugin(Config => ... ) in your startup
17:24 sri no
17:25 sri the resgister sub in the config plugin has a return $config if $config->{'mojo.no_config_plugin'}; in the beginning
17:25 sri it doesn't read the file if the override is active
17:25 jberger really?
17:25 sri and sticks with the default you set in Test::Mojo->new(...)
17:25 jberger does that exist already or you are proposing that?
17:26 sri i'm proposing it
17:26 jberger that's a relatively non-starter for me because it is something that cpan config loaders couldn't do
17:26 jberger unless we could think of a way to do that
17:26 sri i think they all subclass Mojolicious::Plugin::Config
17:26 sri and would get it automatically
17:27 jberger assuming that's true that would be something
17:27 sri case in point https://st.aticpan.org/source/KIMOTO/Mojolicious-Plugin-INIConfig-0.03/lib/Mojolicious/Plugin/INIConfig.pm
17:28 sri https://st.aticpan.org/source/DATA/Mojolicious-Plugin-YamlConfig-0.2.1/lib/Mojolicious/Plugin/YamlConfig.pm
17:28 jberger https://metacpan.org/source/ZITSEN/Mojolicious-Plugin-ConfigAny-0.1.3/lib/Mojolicious/Plugin/ConfigAny.pm
17:28 sri JSONConfig is a subclass of Config
17:28 sri that just copypastas everything from Config
17:28 sri meh
17:28 jberger anyway, just to finish my previous thought
17:29 sri Mojolicious::Plugin::Config has the hooks
17:29 jberger Dancer recently had a big to-do about revamping their config system
17:29 sri yea, please explain what's your point
17:29 jberger and when I was talking to one of their core team I described how simple our config system was, in that it is literally just a hash bucket that anything can toss stuff in and read stuff out of
17:30 jberger and they seemed to be taken aback by the beauty in simplicity that was
17:30 jberger all I'm saying is, the more we take control of that, the less beauty in simplicity it has
17:30 sugar_ joined #mojo
17:30 sri it doesn't do what it's supposed to do
17:31 jberger what do you mean by that?
17:31 sri BEGIN { $ENV{MOJO_MODE} = 'test' }
17:31 sri there is no beauty in that
17:31 sri BEGIN { $ENV{MOJO_MODE} = 'my_other_test' }
17:31 jberger that's a property of the config plugin not the config attribute
17:31 sri BEGIN { $ENV{MOJO_MODE} = 'that_user_test' }
17:31 jberger I don't mind hacking up the config loaders
17:32 sri BEGIN { $ENV{MOJO_MODE} = 'that_foo_bar_test' }
17:32 sri BEGIN { $ENV{MOJO_MODE} = 'what_the_hell_am_i_doing' }
17:32 jberger but by putting privileged code into Test::Mojo that affects how the config loaders work or need to work, now they all have to do the same thing
17:32 sri please make a different proposal, you know what we need
17:33 jberger my proposal is to leave it alone
17:33 sri imagine me swearing over here
17:35 jberger ok then, how about this, my proposal is not to use a `mojo.` config variable to indicate not to load
17:35 jberger we have `file` and `default` keys that I think most plugin loaders have used by convention
17:36 sri a more public api is fine for me too
17:36 sri the mojo. key was just an example
17:37 sri i don't care about the exact implementation, that was just to illustrate one way to do it
17:37 sri i just want for tests to be able to override the config
17:37 sri easily
17:38 jberger how about something like "when Test::Mojo sets initial configuration it also sets test_mojo => 1 so that config loader plugins can choose what to do about it"
17:38 jberger and I'd then encourage config loading plugin authors to add behavior for that
17:39 sri sure
17:39 jberger and indeed we could make it so that if you inherit from the core plugin you get it for free
17:40 jberger I guess, to distill my point, I really want to keep this as public api as possible, and as non-intrusive as possible, because I see that as a great strength of our config sysmte
17:40 sri or name it even more generic config_override => 1
17:40 jberger sure
17:41 PryMar56 joined #mojo
18:02 dod joined #mojo
18:07 sugar_ joined #mojo
18:27 asarch joined #mojo
18:31 robert joined #mojo
18:33 rwh21 joined #mojo
18:37 bjoernfan left #mojo
18:37 rshadow joined #mojo
18:38 FROGGS joined #mojo
18:43 howitdo joined #mojo
18:48 itaipu joined #mojo
18:50 sugar_ joined #mojo
18:58 rshadow joined #mojo
19:05 rshadow joined #mojo
19:09 ooo joined #mojo
19:11 rshadow joined #mojo
19:12 ooo mojo template, i have the following line and want to transform it to template syntax: <a href="#" class="dropdown-toggle" data-toggle="dropdown" role="button" aria-haspopup="true" aria-expanded="false">dropdown <span class="caret"></span></a>
19:12 ooo thats, what i have:  %= link_to 'dropdown' => '#' => (class => 'dropdown-toggle') => ('data-toggle' => 'dropdown', role => 'button', 'aria-haspopup' => "true", 'aria-expanded' => "false")
19:13 ooo i don't how to get the <span class="caret"></span> into it
19:14 ooo any ideas?
19:17 coolo ooo: use the link_to variant with begin
19:19 robinsmidsrod joined #mojo
19:20 * jberger likes that c(oo)l(o) is helping (ooo)
19:20 ooo coolo: does that mean, inside begin i can somehow nest the span tag? :)
19:22 coolo in that begin end block you can put everthing
19:22 coolo jberger: you are just jealous there is no ee to help :)
19:23 jberger /o\
19:24 ooo somehow, i don't get the right syntax, but i will try...
19:25 coolo completely untested: http://paste.opensuse.org/41428291
19:27 ooo thank you very much!
19:30 ooo i didn't know howt to get from: %= link_to 'dropdown' => '#' => to %= link_to '#' ... => begin ... dropdown - i know that your suggestion works but i don't understand it logically, any docs i'm missing?
19:40 rshadow joined #mojo
19:56 tchaves joined #mojo
20:10 sugar_ joined #mojo
20:12 irqq joined #mojo
20:38 gryphon joined #mojo
20:42 sugar_ joined #mojo
20:47 irqq_ joined #mojo
20:54 sri so, i guess we are doing the Test::Mojo->new thing :)
20:55 sugar_ joined #mojo
21:04 eseyman joined #mojo
21:23 bif joined #mojo
21:44 bif @batman, I notice that in a M::L app, if I load the OpenAPI plugin before my routes are defined, OpenAPI cannot see them and returns "501 Not Implemented". If I put the plugin after routes are defined, it's all good. M::P::OpenAPI docs suggest that x-mojo-name can be used to help find routes if they're defined after plugin is loaded but I can't seem to figure that out for a M::L app. Any ideas?
22:08 ashimema joined #mojo
23:14 Zx3 joined #mojo
23:17 asarch joined #mojo
23:19 Zx3 joined #mojo
23:25 Zx3 joined #mojo

| Channels | #mojo index | Today | | Search | Google Search | Plain-Text | summary