Camelia, the Perl 6 bug

IRC log for #mojo, 2013-03-02

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

All times shown according to UTC.

Time Nick Message
00:00 sri it gets more complicated on the Mojo::URL layer :)
00:00 * jberger kinda figure it must, since you are asking about it
00:01 sri the host can always be unicode characters, due to IDNA
00:01 sri we have to punyencode it
00:02 jberger anyway back to format detection
00:02 sri so... you can't really look at all elements of a URL as one thing... it's different parts that need to be processed very differently
00:02 sri userinfo also has its own rules
00:02 sri scheme needs to be normalized... and so on
00:02 jberger gotcha
00:02 sri complicated :)
00:04 ka2u joined #mojo
00:04 jberger I'm not sure what to say on extension based format detection
00:05 jberger the problem I guess is that people want to use . in their route?
00:05 jberger by default
00:05 sri nope, . in route "just works"
00:05 jberger so what is the problem?
00:05 sri it's about control, "you know exactly what it will match"
00:06 sri making route matching more obvious
00:06 jberger again, I think that turning format detection on manually where desired isn't a problem
00:06 jberger because, at least in my apps only certain routes can handle it anyway
00:06 jberger and usually I know which ones those are
00:06 sri it's enabled by default currently
00:06 jberger right
00:07 sri ah, you're saying you don't really care either way?
00:07 jberger as long as I can turn it on
00:07 jberger preferably if I can turn it on per-route
00:07 jberger I've never used format => 1,0
00:08 sri it would be equivalent to format => 0 currently, inherited by nested routes only
00:08 jberger how about a halfway house then? a routing method that turns that on?
00:09 * sri starts to get the impression he might be overthinking this, format => 0 seems to work out well for everyone
00:09 jberger $r->route_with_formats->to...
00:09 jberger or something
00:09 sri that would suck for $r->get() and friends
00:10 sri not to mention format alternatives and regex matching
00:10 jberger maybe,
00:10 sri anyway, how to enable it is not really the problem
00:10 jberger I guess I'm just saying I usually know which routes might have the ability to return structured data and which won't
00:10 sri the question is what should be default
00:11 jberger and I think I'm saying it should be off, as long as it can be easily turned on where needed
00:11 sri $r->get('/foo' => [format => [qw(txt html xml)]]) would automatically enable it
00:12 jberger is my echo working?
00:12 jberger hahaha
00:12 jberger cant start an irc message with /
00:12 jberger the route /logout.json isn't likely to be useful for example
00:12 sri you can with //
00:13 jberger good to know
00:13 jberger yeah I think your example works fine
00:13 jberger "this route knows how to handle different formats"
00:14 jberger "others dont and so shouldn't try"
00:14 jberger makes sense to me
00:14 sri $r->get('/foo' => [format => 1) would only be necessary if you accept arbitrary formats
00:14 sri if you restrict it with alternatives or regex it gets enabled automatically
00:15 jberger what about simple cases? does /hi.html match '/:word'?
00:15 sri the :placeholder does not match .
00:15 jberger so there is a big difference
00:16 jberger so far I can usually ask for /hi.html and still match get the same page as /hi
00:16 sri yes, that's the big difference
00:16 jberger not saying which is correct, but its a big change
00:17 sri that's why we are discussing it now before 4.0 ;)
00:18 jberger it really comes down to how much do people still mentally map their concept of routes to old apache-esque route-as-file-path metaphor?
00:18 jberger and I mean the end-users
00:18 jberger I don't see too many people expecting to need a format on the end anymore
00:19 mattastrophe joined #mojo
00:20 jberger the public conciousness of at least mod-rewrite seems to have taken hold (not that they understand how it works, but that they don't need /index.html or /myapp.php?page=hi or whatever anymore)
00:20 sri if we decide not to change anything in the end i'm fine with that too... those are just design questions we left unanswered when format => 0 and Mojo::Path::charset were added (at the time to solve an urgent problem)
00:21 jberger having format=>0 by default signals a shift to a more truely RESTful system imo
00:21 sri 4.0 is allowed to break everything, so it's our yearly chance to get the design "right" ;)
00:21 jberger only appending .html if your really want it
00:22 jberger api.myapp.com/pod/Mojolicious.html gets you the pod in html format
00:22 jberger api.myapp.com/pod/Mojolicious gives you what we think your browser wants to see
00:23 sri jberger: i suppose the /foo.:format option is also out of the question for you?
00:23 jberger not out of hand, but I think it looks a little bit more strange
00:23 jberger did I see someone say that that is railish?
00:24 sri me
00:24 jberger I just have no experience with rails
00:24 sri rails does /foo(.:format)
00:24 sri () to signal that it's optional
00:24 sri /:controller(/:action(.:format))
00:24 sri :)
00:25 jberger I think personally I like the [format => ] idea better personally
00:25 jberger but I won't gripe about the other
00:25 * jberger isn't being very definitive is he
00:26 jberger I think setting format => 0 with the old system ( [format => ...]) is less breakage
00:26 jberger which is good
00:26 jberger the shift is "please define the formats that your route can accept" not "we are changing how you define routes"
00:27 sri i suppose this example would get easier if we change the default http://mojolicio.us/perldo​c/Mojolicious/Lite#Formats
00:28 sri but we would have to extend the respond_to one to cover the new special case
00:28 jberger becomes more explicit
00:28 jberger what special case? no format?
00:29 sri no format detection meand repond_to can only use Accept header and format GET/POST parameter
00:29 sri s/d/s/
00:29 sri you have to pass [format => 1] to get the current respond_to behavior
00:30 jberger unless you turn it on for that route, which is what I would recommend anyway
00:30 sri but that's a special case
00:30 jberger just by using respond_to you acknowledge that the route can handle multiple formats
00:30 sri it needs to be explained
00:30 jberger oh yeah, it would need to be explained
00:30 jberger definitely
00:31 jberger thinking a little further out of the box, might you want to distinguish between extension (ext) and format?
00:31 jberger maybe not
00:32 jberger too many edge cases probably
00:32 jberger nm, really bad idea
00:33 jberger anyway, I have to head out soon
00:33 jberger talk went well last night, people were excited
00:33 jberger and I hope to release Mojolicious::Plugin::SimpleSlides soon
00:33 jberger needs more doc and tests but its more-or-less ready to go
00:34 * jberger really likes Mojo::Template
00:34 jberger + TagHelpers
00:37 jberger to summarize my thoughts (I think I've made myself clear, but different phrasing)
00:37 jberger I think its ok to have to request format detection
00:38 jberger busy day, I'm off again, I'll check back in a few hours o/
00:40 anewkirk in all of my usage of Mojolicious, I've only found one flaw (imho)
00:41 anewkirk ... which is in the rendering of error pages
00:42 anewkirk I wish there was a simple hook one could use when not using Mojolicious template rendering
00:43 anewkirk in the past I've used the around_dispatch hook approach but that path it riddled with gotchas
00:46 anewkirk as it is now, it works beautifully if you're doing everything "inside-the-box"
00:50 dvinciguerra joined #mojo
01:04 mattastrophe joined #mojo
01:14 xaka joined #mojo
01:30 jontaylor joined #mojo
01:34 ka2u joined #mojo
02:08 asarch joined #mojo
02:10 ka2u joined #mojo
02:50 jnbek joined #mojo
03:11 ka2u joined #mojo
03:20 mport joined #mojo
03:45 tempire how would /foo(.:format) work?
03:47 ka2u joined #mojo
03:47 tempire oh, I guess it would make the format optional
03:47 tempire I have to wonder whether the current format handling is a problem.
03:47 tempire doesn't seem like there's been much issue
03:48 tempire the biggest problem I've seen is confusion between the full and lite handling of it
03:49 basiliscos joined #mojo
04:12 basiliscos joined #mojo
04:16 rem_lex| joined #mojo
04:17 ka2u joined #mojo
04:18 phillipadsmith Any thoughts / help on this confusing behaviour appreciated: https://gist.github.com/philli​padsmith/91a7999ae9b9233405ac
04:25 tempire You'll notice that Mojo::DOM in fact has no html method
04:25 tempire http://search.cpan.org/~sri/Mo​jolicious-3.87/lib/Mojo/DOM.pm
04:32 mauke_ joined #mojo
04:33 preflex_ joined #mojo
04:47 ka2u joined #mojo
04:48 mport left #mojo
04:57 mattastrophe joined #mojo
05:10 d4rkie joined #mojo
05:15 jberger tempire, true, but neither does it have a title method, but it work because of AUTOLOAD
05:16 jberger phillipadsmith, it works if you remove the html and head methods
05:16 jberger the title method does work
05:16 jberger and yes IMO that seems a little inconsistent
05:16 jberger I'll dig a little deeper
05:19 jberger the AUTOLOAD is basically just a wrapper for ->children
05:25 jberger ok here is the final work on the matter
05:26 jberger there is no html or head AUTOLOAD method because you are receiving malformed html
05:28 jberger actually there is a head method via AUTOLOAD but the malformed html doesn't have the title tag inside the head tag, so that fail
05:29 jberger phillipadsmith, all that said, you don't need to drop down tag by tag, thats what the selectors are for :-)
06:17 berov joined #mojo
07:00 hrupp joined #mojo
07:06 sh4 joined #mojo
07:06 Vandal joined #mojo
07:06 Mike-PerlRecruiter_ joined #mojo
07:08 ACE joined #mojo
07:08 ACE_ joined #mojo
07:17 jzawodn joined #mojo
07:28 xaka joined #mojo
07:32 andrefs joined #mojo
07:35 Britzel joined #mojo
08:11 anewkirk joined #mojo
08:43 jnbek joined #mojo
08:46 ObseLeTe joined #mojo
08:46 dod joined #mojo
08:56 basiliscos joined #mojo
09:02 ruz joined #mojo
09:13 trone_ joined #mojo
09:18 arpadszasz joined #mojo
09:45 arpadszasz joined #mojo
10:20 mauke_ joined #mojo
10:20 preflex joined #mojo
10:25 Vandal Is there a good auth plugin?
10:30 mauke_ joined #mojo
10:30 preflex_ joined #mojo
10:38 Britzel_ joined #mojo
10:45 Britzel_ Yes
10:52 mauke_ joined #mojo
10:53 preflex_ joined #mojo
10:58 mauke joined #mojo
10:58 preflex_ joined #mojo
10:59 kitt_vl joined #mojo
11:08 Vandal Britzel_, name?
11:10 Britzel_ Vandal: I use Mojolicious::Plugin::Authentication for most stuff requiring logins, and basicAuth for uploads which use HTTP basic auth.
11:11 Vandal Mojolicious::Plugin::Authentication is sux - it jerks DB on every request
11:11 Vandal I'll see basicAuth, thanks
11:29 jamesw joined #mojo
11:41 D4RK-PH0ENiX joined #mojo
11:41 maxhq joined #mojo
11:52 jontaylor joined #mojo
11:56 maxhq1 joined #mojo
12:05 vervain Vandal: M::P::Authentication is database agnostic.  Not sure what you mean by your statement.
12:07 Vandal vervain, it uses load_user on every request

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