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

IRC log for #mojo, 2017-01-29

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

All times shown according to UTC.

Time Nick Message
00:04 stryx` joined #mojo
00:39 circ-user-WL3Ni joined #mojo
01:13 litwol yahii
01:13 litwol all works now
01:13 litwol not even going for non-blocking right now. just glad to have basics like form submission and saving to db working.
01:13 litwol plus psql is being nice.. and pleasant to work with so far.
01:13 litwol ++ for all the help
01:13 litwol thank you
01:18 litwol I would like to learn more about templating.. i am getting the hang on basics.
01:19 litwol but coming from php, i'd love to know if mojolicious' templating supports functionality similar to template engines like Twig
01:19 litwol doesn't have to be 1:1, but i'm curious how some of the methodology maps over
01:20 bpmedley litwol++
01:20 litwol i see mojo's templates override is achieved by inlining templates, and then module consumer would inflate them..
01:20 bpmedley What types of features in Twig do you like?
01:20 litwol a bit weird and unusual for me.. but it works..
01:20 sugar joined #mojo
01:20 litwol well.
01:21 litwol i think i'm just confused by syntax for the time being. (not that all the PSR-* are any easier for me to understand)
01:21 litwol but template extends and overrides
01:22 litwol override == ship default, and consumer overrides in a different directory location.
01:22 litwol i am more used to shipping seaprate files and letting users copy to new directory, which has higher priority
01:23 bpmedley litwol : http://mojolicious.org/perldoc/Mojolicious/Renderer#paths <-- one way would be using this
01:23 litwol oh i c
01:23 litwol this way consumer gets to choose which of /their/ folders is higher priority
01:23 litwol cool :)
01:24 blonewolfs joined #mojo
01:25 litwol my background is actually many years in Drupal. very difficult to shake that off and try something new without bias :(
01:26 bpmedley Alternate perspectives are encouraged..
01:26 bpmedley Although, we're very opinionated.. ;)
01:26 litwol for example, right now i'm trying to figure out how to create drupal-equivalent of modules. module being a plugin that responds to system's "hooks"/events. and in terms of packaging it is able to ship with own templates in any folder under own module directory.
01:26 litwol so i'm trying to see if same makes sense in mojo..
01:27 litwol such as using plugin generator (or equivalent) .. but then how to tell that a template should live under that plugin's directory structure?
01:27 litwol and then root level app, which has the 'templates' folder, then has 2nd priority (for overrides).
01:28 litwol i'm here to learn :). the stronger opinion ya'll throw at me the easier it'll be to shed old bias and learn something new. so.. bring it ;)
01:29 sri http://mojolicious.org/perldoc/Mojolicious/Guides/Rendering#Bundling-assets-with-plugins
01:30 litwol oho! just what i was looking for
01:30 litwol thank you
01:31 litwol i saw this documentation before :(. forgot abot it :(
01:31 bpmedley litwol : We're glad you're here.. always difficult remember everything at the beginning..
01:36 litwol :)
01:41 litwol Many "frameworks" and distros built on top of them often have opinions about various Models/Schemas that are "standardizes" within such distros. for example Drupal has "user", and that user model is hooked into login/register workflow, hooked into roles and permissions.
01:42 litwol i am perfectly open to building from ground up whatever i need for my current (hobby) project... but before i do i'd like to explore if mojo "ecosystem"/community has opinons on "standardized" Models.
01:42 litwol if i want to add registrations and user profiles to my site, is there a plugins search site i can go to, find and download it, and be done ?
01:42 litwol Does such "consumer" workflow make sense within mojo community ?
01:45 bpmedley litwol : Most models/schema I've seen are customized for the system/developer building them.  I believe it's been said that Mojo is DB agnostic.
01:50 bpmedley litwol : on that point, have you seen migrations: https://github.com/kraih/mojo-pg/blob/master/examples/blog/lib/Blog.pm#L21
01:52 litwol no
01:52 * litwol reads http://mojolicious.org/perldoc/Mojo/Pg/Migrations
01:53 litwol oh this is cool!
01:53 bpmedley litwol : https://github.com/kraih/mojo-pg/blob/master/examples/blog/migrations/blog.sql <-- See the versioning in comments?
01:54 litwol i was meaning to ask about it.. my curiosity stems from "doctrine" php project.
01:54 litwol i absolutely *love* how doctrine works when connecting to existing db and be able to dump schema into models, and then as models evolve, be able to generate *versioned update steps*
01:55 litwol and be able to "play" those steps for actual upgrade.
01:55 litwol yeah this migration stuff is really cool. ty for pointing out.
01:55 litwol today as i was learning psql i ended up creating and dropping single table some 10 times or so
01:56 litwol until i figured out how to generate uuid by default on insert
01:56 litwol turns out as simple as 'id UUID PRIMARY KEY DEFAULT uuid_generate_v1mc(),'
01:58 litwol Now that i've got Mojo::Pg working.. i've got to ask, what ORM options do we have available?
01:59 litwol https://github.com/kraih/mojo/wiki/Database-support
01:59 litwol "DBIx::Simple in combination with SQL::Abstract is a simple but powerful alternative of a full blown ORM like DBIx::Class."
02:00 bpmedley litwol : I generally do not use an ORM, so I'm not sure..
02:01 litwol from a non-judgemental, learning angle...
02:01 litwol why?
02:02 bpmedley I haven't seen one that I enjoy using with complicated queries.
02:06 Grinnz once you learn SQL to a certain extent, there's less need for an ORM, and it does introduce some overhead in abstraction
02:07 Grinnz sometimes you need to use raw queries anyway in order to have a query perform the way you want
02:14 aborazmeh joined #mojo
02:22 genio funny show suggestions?
02:56 tchaves joined #mojo
03:03 tchaves1 joined #mojo
03:41 noganex_ joined #mojo
04:42 aborazmeh joined #mojo
05:04 dboehmer joined #mojo
06:51 polettix joined #mojo
07:00 Vandal joined #mojo
07:09 sh14 joined #mojo
07:25 sugar joined #mojo
07:34 dod joined #mojo
08:03 Petru joined #mojo
09:29 dod joined #mojo
10:00 marcus joined #mojo
10:25 sri genio: the good place
10:25 purl the good place is http://www.cgi-resources.com
11:01 litwol css on that page is all broken
11:27 polettix joined #mojo
11:53 tchaves joined #mojo
11:55 sugar joined #mojo
12:04 litwol pardon if it's a crazy/silly question.. but for the sake of loose coupling, is it possible or does it make sense to perform intra-app crud via REST calls? for example if i have internal user model, i could easily say 'use namespace::User' and create new instance of that and use methods directly..
12:05 litwol Alternatively, would it be possible to leverage Request package to perform get/post/put/delete on internal data structures?
12:05 litwol and how badly would performance be ?
12:07 sri if you can put something in the model code, put it in the model code
12:08 sri if you follow the blog example you'll see there is no need to include models everywhere, we have helpers to abstract out shared code
12:09 sri http://mojolicious.org/perldoc/Mojolicious/Guides/Cookbook#Adding-a-plugin-to-your-application
12:09 Petru joined #mojo
12:15 * sri still wonders if he wants a Mojolicious::max_request_size
12:16 sri it's kinda ugly how we recommend an env variable in the tutorial http://mojolicious.org/perldoc/Mojolicious/Guides/Tutorial#File-uploads
12:25 mattp is it possible to run test::mojo tests against a remote running instance?
12:44 pink_mist just use the url?
12:44 pink_mist as in, full url to the remote instance
12:44 pink_mist rather than the relative url you normally use locally
12:45 pink_mist unsure if that'll really work tbh, but it can't hurt to try :P
12:45 sri sure does
12:48 Petru joined #mojo
13:12 mattp ah cool. thanks
13:44 sri hmm, i guess the correct implementation would be to overload the max_message_size attribute in Mojo::Message::Response with the 2GB default, and then have Mojo::UserAgent::max_response_size and Mojolicious::max_request_size redefine their respective max_message_size values if they are defined
13:52 Petru joined #mojo
14:26 CW2 joined #mojo
14:57 tchaves joined #mojo
15:04 tchaves joined #mojo
15:12 litwol in examples from http://mojolicious.org/perldoc/Mojo/Pg there is a keyword 'state'.
15:12 litwol What is it? where can i read more about it?
15:17 go|dfish litwol: https://metacpan.org/pod/perlsub#Persistent-variables-via-state()
15:21 pink_mist it's like static function variables in C iirc
15:23 genio sri: I'll check that one out.  too bad it's not on Netflix
15:27 litwol i c
15:35 litwol i have never used 'dependency injection' before, neither with my new experience in perl nor in my past with php..
15:35 litwol but i'm curious to experiment.
15:35 litwol Is there 'mojolicious flavor' of DI ?
15:35 litwol or a /recommended/ approach ?
15:41 good_news_everyon joined #mojo
15:41 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vDUMt
15:41 good_news_everyon mojo/master 334e72b Sebastian Riedel: add max_request_size attribute to Mojolicious
15:41 good_news_everyon left #mojo
15:42 sri little more consistent now
15:42 pink_mist litwol: unsure what you mean by "dependency injection"
15:42 sri not entirely sure if it's the correct solution, but at least it's consistent and very backwards compatible
15:43 litwol pink_mist: just the latest thing with OO. instead of each class instantiating own dependencies inside a constructor, those dependencies would be passed from outside. this way external dependencies can be swapped out more easily.
15:45 litwol However.. i do see with mojo startup {} + helper registration that allows keeping "dependencies" in one place, and consumers of those dependencies just reference $controller->[helper name]
15:45 litwol perhaps "out of the box"/"by default" mojo's helpers are the equivalent of dependency injection.
15:45 pink_mist I really don't understand what you mean by that, sorry
15:45 sri litwol: we use many design patterns, but we're not pretentious about it
15:45 litwol pink_mist: http://modernperlbooks.com/mt/2011/08/youre-already-using-dependency-injection.html
15:46 litwol sri: the thing is that i'm trying to better understand it. thus looking for "how is mojo accomplishing the same?"
15:46 sri https://github.com/kraih/mojo/blob/master/lib/Mojolicious.pm#L43-L45
15:46 sri we use the delegation pattern everywhere, it
15:46 sri 's dependency injection
15:47 sri we do not specifically abstract out the patterns
15:47 litwol i dont know enough perl nor mojo to understand consequence of the syntax you linked to :(
15:47 pink_mist litwol: thanks, that link explained it well ... and yeah, mojo does that a lot
15:48 pink_mist pretty much the same way the link suggested (except in a non-Moose-y way)
15:48 litwol one of the things i like from symfony2 php framework is it's "dependency injection" is (i think?) strongly coupled with /file based configuration/.
15:49 pink_mist litwol: the bits sri linked to are a consequence of the 'has' function from Mojo::Base
15:49 litwol such that names for every controller or just about any class are defined in plain text in a config file
15:49 litwol and then at run time things get instantiated using new $system->config('some.controller.or.service.name')
15:50 litwol mojo helpers also allow dot-based namespacing. that's nice.
15:50 sri mojolicious is not configuration oriented
15:50 sri it's opinionated and tries to guess the best defaults
15:51 sri i wouldn't call the way symfony2 works a consequence of its use of dependency injection
15:52 sri that's more IoC
15:52 litwol but i imagine nothing is stopping me from using config() to keep class/plugin names in a config file, then inside startup {} create helper 'state' objects based on the plugin name from config?
15:53 sri we don't have an IoC framework, but you can change stuff like the app logger in a similar fashion for example
15:53 sri app->log(Mojo::Log::SomeCustomizedLogger->new)
15:54 litwol i c
15:54 matt___ joined #mojo
15:55 matt___ is there a max concurrent query limit on DBD:Pg/Mojo::Pg? im kind of confused
15:55 sri matt___: there is not
15:57 matt___ is maxing out concurrent connections on the database generally not an issue? I'm new to postgres
15:57 litwol perhaps instead of getting self confused around different concepts i best ask... is there some material i can read that give guidance/suggestions on how to write losely coupled/modular .. umm.. "systems". preferably perl centric so i can lean more language from it.
15:57 litwol ?
15:58 matt___ litwol: the mojo docs are actually fairly extensive for the basic idea of decoupling your app
15:58 litwol i do see a lot of examples on how to make plugins and such.
15:58 sri litwol: possibly around Moose, steavan like philosophing about the application of different patterns to the language :)
15:59 litwol but possibly i'm missing a more generic explanation of /why/ do this versus that. a leran the conept type of material.
15:59 litwol 'a learn the concept'* (typo)
16:00 sri perl is a rather diverse community, ask 10 people get 10 different opinions ;)
16:00 litwol heh
16:00 litwol i noticed.
16:00 sri like, most of us agree that the Perl Best Practices book is mostly right, but some of it is totally wrong ;p
16:01 litwol it was entertaining yesterday to watch a little bickering around how best to help me around non-blocking db questions :-p. heh.
16:03 pink_mist litwol: well, if you hadn't already installed perlbrew, I would have agreed with bpmedley that perl-build was much easier to get started with =)
16:03 litwol well. there's also consideration of security.
16:04 litwol for one, i was not familiar with links posted. and asking to freely run them on my system is not something i'd act on immediately :)
16:05 coolo sri: 11 opinions :)
16:06 jberger the two most DI-like systems on CPAN that I'm aware of are Bread::Board and Beam::Wire
16:06 jberger Bread::Board is the elephant in the room, Beam::Wire is a lighter alternative by our own preaction
16:07 jberger (where does that leave the count? :-P)
16:07 dod joined #mojo
16:07 matt___ how should maxing out postgres connection count be handled? just catch the exception and return a 500?
16:10 matt___ hmm, I suppose you have a theoretical maximum of hypnotoad clients attr * workers * maximum queries per request
17:27 Ryoga joined #mojo
17:28 Ryoga joined #mojo
17:28 Ryoga joined #mojo
17:35 bpmedley matt__ : I've used pgbouncer some, although not in production
17:54 DavidSouza joined #mojo
17:56 AndChat-437241 joined #mojo
18:05 bpmedley litwol : Thank you for detailing what the situation looked like from your perspective.  I must try and figure out a way that my opinion can be expressed in a more inclusive manner.
18:49 good_news_everyon joined #mojo
18:49 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vDUdu
18:49 good_news_everyon mojo/master 4912cbc Sebastian Riedel: let basename remove the extension
18:49 good_news_everyon left #mojo
18:50 matt___ joined #mojo
18:50 sri jberger: would appreciate your opinion on the max_response_size/max_request_size changes
18:50 matt___ https://github.com/kraih/mojo/commit/b7a08c33aa720fb4dcc3d6827f29b36d9ec73b98#diff-ccf996555125c90064b288a0e4c139c5R103
18:51 matt___ it looks like json was removed from the renderer list and special cased here. I was using it to provide a ?pretty param to toggle prettifying json
18:51 matt___ it seems I can still monkeypatch over Mojo::Renderer::encode_json .. but I wont have access to params anymore. is what I was doing now impossible?
18:52 matt___ i suppose i could just create an alternatively named renderer
18:52 matt___ avoiding that would be ideal though
18:55 good_news_everyon joined #mojo
18:55 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vDUdM
18:55 good_news_everyon mojo/master 01ad988 Sebastian Riedel: better test deactivating the message size limit
18:55 good_news_everyon left #mojo
18:59 good_news_everyon joined #mojo
18:59 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vDUdN
18:59 good_news_everyon mojo/master 7c9d697 Sebastian Riedel: fix typo in description
18:59 good_news_everyon left #mojo
19:01 matt___ im monkeypatching Mojo::Renderer::render() ... is there a better way?
19:11 Petru joined #mojo
19:13 matt___ actually that approach doesnt seem to work. sri: any ideas?
19:14 good_news_everyon joined #mojo
19:14 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vDUFy
19:14 good_news_everyon mojo/master dbc3393 Sebastian Riedel: fix typo in Changes
19:14 good_news_everyon left #mojo
19:23 PryMar56 joined #mojo
19:24 lluad joined #mojo
19:41 Grinnz matt___: multiple queries per request and clients should not add additional connections. if you use a Mojo::Pg object in a helper you should only have one connection per worker, unless you fork
19:41 Grinnz or do async stuff that needs a second connection
19:51 matt___ grinnz: I don't think thats true
19:53 matt___ https://metacpan.org/source/SRI/Mojo-Pg-2.35/lib/Mojo/Pg.pm#L33
19:54 matt___ new handles spawned per query if instantiated through $pg->db->query instead of my $db = $pg->db; $db->query
19:54 Grinnz no they don't
19:54 matt___ how do you figure? unless you're reading the code differently than I am :)
19:54 Grinnz that would be extremely inefficient
19:54 Grinnz read the _dequeue method
19:55 lluad joined #mojo
19:55 matt___ itll first iterate through queue to see if any handles are still alive via ping, otherwise itll spawn a DBI->connect
19:55 Grinnz after a $db goes out of scope, its handle is added back to the queue
19:56 matt___ yes
19:57 matt___ max_connections only limits the amount of recent db handles to store, not a maximum of connections to the server
19:58 asarch joined #mojo
19:58 Grinnz you shouldnt have more than one $db object in scope at any time anyway
19:58 matt___ unless you want to run more than one query at a time obviously
19:59 Grinnz yes, async is a different matter
20:00 Grinnz my $db = $pg->db; $db->query(...); $db->query(...); # uses the same dbh for each, dbh is requeued once $db goes out of scope
20:01 Grinnz $pg->db->query(...); $pg->db->query(...); # the db is never stored so its dbh is requeued after each query and reused for the next
20:01 Grinnz neither spawns new handles
20:01 matt___ grinnz: no, looks like itll croak https://metacpan.org/source/Mojo::Pg::Database#L73
20:01 Grinnz those are blocking queries
20:02 Grinnz you mean more than one nonblocking query at a time?
20:02 Grinnz only one can be run per $db object
20:02 Grinnz so you would have each get a new $db object
20:02 matt___ what? it clearly says non-blocking
20:02 Grinnz my examples are blocking queries i meant
20:03 matt___ ah. ive been talking about async this entire time
20:03 Grinnz then you cannot reuse the same $db for multiple queries running at the same time
20:03 Grinnz that's a limitations of postgres
20:07 matt___ yes. my original question was "is there no rate limiting of maximum connections spawned (when asynchronously firing $pg->db->query), the answer is no
20:37 Petru joined #mojo
21:07 good_news_everyon joined #mojo
21:07 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vDUj8
21:07 good_news_everyon mojo/master eea826a Sebastian Riedel: help perltidy a little
21:07 good_news_everyon left #mojo
21:22 kiwiroy joined #mojo
21:30 polettix joined #mojo
21:30 good_news_everyon joined #mojo
21:30 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vDTve
21:30 good_news_everyon mojo/master 10ca377 Sebastian Riedel: use the result method in the get command too
21:30 good_news_everyon left #mojo
22:29 polettix joined #mojo
22:51 good_news_everyon joined #mojo
22:51 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vDTTy
22:51 good_news_everyon mojo/master 66a0020 Sebastian Riedel: use current best practices in examples
22:51 good_news_everyon left #mojo
22:52 pink_mist hmm, didn't 7.23 get released an hour ago? but no 'good news' mention of it :(
22:53 sri yea, odd
22:53 good_news_everyon joined #mojo
22:53 good_news_everyon [mojo] kraih pushed 1 new commit to master: https://git.io/vDTT5
22:53 good_news_everyon mojo/master b14603a Sebastian Riedel: use the result method in the README example too
22:53 good_news_everyon left #mojo
22:53 sri think the same happened for 7.22
22:53 pink_mist huh
23:37 jberger sri: sorry I've been a bit distracted today :s
23:38 jberger were there more changes than just adding a higher response size limit to UA?
23:39 jberger actually, I might be off and on here, I'm going to upgrade my convos, been a while since I did that
23:41 litwol I wrote some questions about 'javascript' and 'stylesheets' in wrong channel an hour ago. just realizd :(
23:41 litwol http://dpaste.com/2W1E7QG
23:43 jberger litwol: you could certainly iterate over an array and call the javascript or stylesheet helper for each item
23:44 jberger something else would be to have a layout that has "js_includes" or "stylesheet_includes" content sections and then use content_for to place them
23:44 jberger that's a more advanced topic though I suppose
23:44 litwol yeah.. i guess i can still use stash inside blocks, instead of getting values out of stash, i use some common stash key as array to push data onto
23:44 jberger http://mojolicious.org/perldoc/Mojolicious/Guides/Rendering#Content-blocks
23:45 Grinnz sri: wasn't sure about the max_request_size/max_response_size but now that i see them implemented together it looks great
23:45 jberger see how that header content block is used
23:45 Grinnz much simpler to set max_request_size than max_message_size
23:45 jberger that's basically where you could put css sections
23:45 litwol jberger: yes. i used that. for now i'm calling 'javascript' inside a 'content_for "styles"' or "scripts"
23:46 jberger right
23:46 litwol just didn't get to using array pushes yet.
23:46 litwol i saw there's asset packer.. looking forward to figuring out how it worksand if it accepts list of assets dynamically
23:46 litwol being able to get dyanmic assets processing would be awesome
23:46 jberger oh, well, the idea of using a content block kinda obviates that somewhat, by simply declaring the css or javascript where you need it
23:47 litwol won't have to worry about styles/js management manually, just focus on loading and using the right plugins.
23:47 litwol oh. that's the thing.
23:47 jberger assetpack is really nice if you are going to that level of integration
23:47 litwol i'm hoping for many small-purpose plugins, each owning own views and styles.
23:47 litwol and as my parent app loads and uses the plugins, css/js gets automatically loaded in the right place withut manual intervention
23:48 jberger yeah, in each smaller included template, you can then declare the content_for javascript and content_for stylesheet and they will get put into the appropriate places
23:48 jberger all that you have to be sure of is that the outer template or layout or whatever does eventually include those content blocks
23:49 jberger one sec, restarting my irc client
23:49 jberger biab
23:49 jberger joined #mojo
23:49 litwol ty for tips
23:49 jberger ok that seems to have been mostly painless

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