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

IRC log for #mojo, 2018-01-10

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

All times shown according to UTC.

Time Nick Message
00:28 marty joined #mojo
00:53 marty joined #mojo
01:22 purplecoffee joined #mojo
01:24 purplecoffee Hello, I am at the early stages of migrating some old CGI code to mojolicious, and I'm trying at this point to use some templates within a CGI script
01:25 mohawk purplecoffee, is there a question there? :-)
01:25 purplecoffee I wonder if I could show you what I'm doing and it might be obvious to you what's wrong?
01:25 purplecoffee my $c = Mojolicious::Controller->new;
01:26 purplecoffee $c->stash(recordarray => $recordarray);
01:26 purplecoffee my $text = $c->render_to_string("$FindBin::Bin/../../templates/edit_records");
01:26 purplecoffee I get an error about calling plugins on undefined values
01:28 purplecoffee I've been going round in circle trying different approaches according to where google and the docs lead me, and I guess I'm on the wrong track still
01:28 purplecoffee Can't call method "plugins" on an undefined value at /usr/local/share/perl5/Mojolicious/Controller.pm line 168
01:29 Grinnz you should not be needing to construct a new controller. use the one provided when handling the request
01:29 Grinnz also, paths to template are relative to your app home, not an absolute path
01:29 purplecoffee this is in a cgi script called by apache
01:30 Grinnz more specifically they are relative to https://metacpan.org/pod/Mojolicious::Renderer#paths
01:30 Grinnz well then you are at too early a stage to use controllers. you would need to use Mojo::Template directly
01:31 Grinnz you dont have an application yet
01:31 purplecoffee ok thanks, I tried that at one point but I guess I gave up to quickly
01:31 purplecoffee Now I know that's the correct direction I will stick to it - thank you
01:32 Grinnz well the correct direction would be to work on turning it into an application
01:32 purplecoffee Definitely :)
01:33 purplecoffee But the current application needs to be replaced yesterday, so I have thrown the scripts onto a new centos 7 server and am trying to bring this live quickly
01:33 purplecoffee Maybe I should hold off on trying to do any templating then, until I can replace entire scripts
01:34 Grinnz its not the first step i would take, for sure
01:34 purplecoffee What would be the first step?
01:34 Grinnz thoguh using Mojo::Template directly is fine for instances where there never will be an application involved
01:36 purplecoffee I am very torn between trying to get this replacement into production quickly, and trying to make changes before I do that
01:36 Grinnz turning it into an application in some form, i cant speak to what would be the best approach for your situation, but you can turn each cgi script into a mini application using Mojolicious::Lite, or you can build up a real application encompassing all their functionality, or you can serve them as-is from mojolicious using Mojolicious::Plugin::CGI (but i dont think that last one is very helpful for what you're trying to do)
01:36 Grinnz but for any approach modularizing is always helpful
01:37 Grinnz i dont think theres really anything useful to do "quickly"
01:37 Grinnz but could be, i dont know what your scripts are doing :)
01:37 purplecoffee It is modularized - I wrote it in 2001 and it has several modules and objects involved
01:38 purplecoffee I hadn't thought of replacing each script with a mojolicious::lite one - that sounds promising!
01:38 Grinnz the downside of that is it could get very redundant
01:38 Grinnz but it's the most in-place method
01:39 Grinnz and separate CGI.pm scripts are already redundant
01:39 purplecoffee Right, it's a really big change!
01:39 purplecoffee I wish I could redo it from scratch
01:40 purplecoffee my scripts produce a web front end for people to edit data in a mysql database
01:48 purplecoffee Can't locate object method "render_to_string" via package "Mojo::Template
01:49 purplecoffee How do I use Mojo::Template to generate the string to print?
01:51 mohawk purplecoffee, maybe you're trying to "render" something and there's something more mojo-ish you could do, like be app-ish and $c->render(data => $the_string)?
01:52 mohawk as far as i know, in mojo-land you don't want to "print" things even though that's how business is done in CGI-land
01:52 mohawk Grinnz, can you advise?
01:53 purplecoffee It's in the middle of a cgi script though - maybe I am just wrong-headed in trying to use a template in a small way like this instead of tackling an entire script at a time
01:53 purplecoffee I made a small template for one part of the page
02:01 Grinnz purplecoffee: Mojo::Template does not have a render_to_string method... did you read its docs?
02:01 purplecoffee Yes, that's how I ended up back at Controller.
02:02 Grinnz there are no controllers involved
02:02 Grinnz if you just want to use Mojo::Template, you'd do something similar to its synopsis
02:03 gizmomathboy joined #mojo
02:03 purplecoffee Gotcha, that makes sense of it for me.
02:03 purplecoffee I will need to take bigger steps at a time.
02:04 purplecoffee Thank you both for your time!
02:05 Grinnz rule of thumb is that Mojo:: is a toolkit, and Mojolicious:: is for web applications; you can use Mojo:: modules piecemeal however you want, but to step into Mojolicious:: you usually need to have an actual application set up
02:05 Grinnz whether lite or full
02:06 mohawk nicely put
02:06 purplecoffee OK thanks
02:07 mohawk doing it piecemeal you can obviously do Mojo:: stuff
02:07 mohawk whether it makes more sense to go full-mojo and turn each thing into a web-app is situational and only you can judge that
02:25 stokachu joined #mojo
03:27 orev joined #mojo
05:04 dboehmer joined #mojo
05:08 Kharec joined #mojo
05:24 gordonfish joined #mojo
06:19 jamesaxl joined #mojo
07:32 inokenty-w joined #mojo
08:00 AndrewIsh joined #mojo
08:25 trone joined #mojo
08:42 Vandal joined #mojo
08:51 McA joined #mojo
09:26 Dandre joined #mojo
10:01 kes joined #mojo
10:05 coolo sri: is MOJO_REVERSE_PROXY=1 still required? the documentation says mojo won't pick up forwarded-for headers otherwise, but in my experiments it does
10:09 Ricaz joined #mojo
10:55 tchaves joined #mojo
10:57 tchaves joined #mojo
11:07 trone joined #mojo
12:14 pink_mist 0_o it shouldn't if you don't set that
12:15 pink_mist coolo: that could be a security issue if it picks up forwarded-for headers without that env var set
13:06 sri coolo: yea, that would be a serious bug
13:07 sri should be fairly well tested though, so i think it's more likely your environment is just not clean
13:41 itaipu joined #mojo
13:45 marty joined #mojo
13:47 perlpilot joined #mojo
14:02 maschine joined #mojo
14:12 dotan_convos joined #mojo
14:51 Dandre left #mojo
14:52 ChmEarl joined #mojo
14:55 gryphon joined #mojo
15:13 tyldis my $self = shift->SUPER::new(@_); <- I learned something new today!
15:14 mohawk #winning
15:15 tyldis I have been adding an init method to my EventEmitters. Ugly.
15:16 tyldis Some::Thing->new()->init
15:19 FROGGS joined #mojo
15:39 purplecoffee joined #mojo
15:49 bwf joined #mojo
15:49 Seth joined #mojo
15:55 gizmomathboy joined #mojo
16:04 webart shift->SUPER::new(@_) does that make sure some other required parent module is loaded?
16:05 webart by using its "new" method?
16:05 jberger it calls the new method on the parent class
16:06 jberger SUPER is a magick class that resolves to the invocant's parent
16:06 webart cool
16:06 genio right. it's a common idiom to call the parent's method before the child's method does what it does.
16:07 jberger I'm not sure why but there is now a second way to do it that people say is "better"
16:07 genio what's that, jberger?
16:07 jberger use mro; sub new { my $self = shift; $self->next::method(@_); ... }
16:07 webart right
16:07 jberger handles multiple inheritance better
16:07 genio oh, yes. that way it resolves multiple... yea
16:08 jberger but since mojo doesn't allow multiple inheritance it isn't any different (I don't think)
16:08 genio but multiple inheritance == bad
16:08 webart genio: yeah
16:09 haarg next::method is also rather slow
16:09 purl okay, haarg.
16:09 jberger botsnack
16:09 purl thanks jberger :)
16:09 genio Roles make life betterer
16:10 webart hmm trying to figure out a way to try the REST OpenAPI Swagger  stuff from the Mojo Advent Calendar
16:10 haarg i wouldn't say multiple inheritance is specifically "bad", but it is often hard to reason about.  any large inheritance tree usually is as well.
16:12 webart One idea was to make a Mojo web interface for moonphases using Astro::MoonPhase to do the work :-) ... a bit like http://www.moongiant.com/phase/today/
16:12 webart but http://www.moongiant.com/phase/today/ seems too simple to need an OpenAPI description etc. eve n for a toy application
16:13 webart or is just the wrong kind of web application for REST/OpenAPI
16:15 webart anyway a realtime screen capture based video using vim to write a mojolicious based moon phase app might be shorter than 10 minutes ;-)
16:20 esh joined #mojo
16:26 esh joined #mojo
16:32 webart ok maybe a bit longer :-D
16:33 mohawk webart, you should probably still make an openapi spec
16:33 mohawk if it's as simple as you say, it won't take much time at all
16:34 dod joined #mojo
16:34 mohawk and there are other benefits (*cough*easy graphql interface*cough*)
16:40 marty_ joined #mojo
16:46 esh joined #mojo
16:47 purplecoffee joined #mojo
16:59 djk joined #mojo
17:26 dod joined #mojo
17:30 McA joined #mojo
17:55 ghenry joined #mojo
18:15 Pyritic joined #mojo
18:32 jberger webart that seems like a great first use
18:34 mib_tiu5in joined #mojo
18:34 mib_tiu5in left #mojo
18:51 marty joined #mojo
19:02 itaipu joined #mojo
19:05 Pyritic joined #mojo
19:15 ghenry joined #mojo
19:17 esh joined #mojo
19:30 esh joined #mojo
19:33 esh joined #mojo
19:36 esh joined #mojo
19:43 esh joined #mojo
19:48 ghenry joined #mojo
19:49 D joined #mojo
19:54 stryx` joined #mojo
20:05 Grinnz well this is an unfortunate name https://gotmojo.com/
20:10 ribasushi https://gotmojo.com/project/trumpy-bear/ <--- this makes up for it
20:12 Grinnz that's how i noticed it :P
20:14 ghenry joined #mojo
20:26 maschine it's like a web platform for As-Seen-On-TV products lol
20:41 ghenry joined #mojo
20:53 jberger it looks like it has too much hair
20:53 jberger or should I say ... too much scalp coverage
20:57 itaipu joined #mojo
21:24 itaipu joined #mojo
21:25 tianon joined #mojo
21:26 tianon joined #mojo
21:27 tianon joined #mojo
21:28 ghenry joined #mojo
21:29 tianon joined #mojo
21:37 tianon joined #mojo
21:38 tianon joined #mojo
21:46 tianon joined #mojo
21:53 Repaster joined #mojo
21:55 itaipu joined #mojo
21:57 marty joined #mojo
22:56 gizmomathboy joined #mojo
23:02 maschine if you wanted to stream a zip file on the fly, what module would you recommend with mojo?   IO::Compress::Zip?
23:02 maschine i'd like the inputs for my zip file to be Mojo::Asset::File objects
23:07 Grinnz it might be a little complicated to stream the output; i would simplify it by zipping from one Mojo:::Asset::File to another and then serving that asset
23:08 marty joined #mojo
23:09 haarg i don't know if IO::Compress::Zip has enough API to do streaming zip files
23:10 haarg unless you are dealing with single file archives
23:11 Grinnz right, if you actually want to make a multi-file zip you need something like Archive::Zip
23:12 Grinnz which is probably not going to be able to stream the result either
23:42 marty joined #mojo

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