Camelia, the Perl 6 bug

IRC log for #mojo, 2012-10-22

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

All times shown according to UTC.

Time Nick Message
00:00 marcus joined #mojo
01:02 laouji joined #mojo
01:31 gryphon joined #mojo
01:51 d4rkie joined #mojo
02:08 sri sent something to the list http://groups.google.com/group/mojolicio​us/browse_thread/thread/13ecacdb64c65eb1
02:11 sri should it ever make it into core, i think it would become app->pipeline, since asset is already used by Mojo::Asset
02:15 crab how do people who deploy to heroku handle mojo app configuration?
02:16 crab they want all configuration stuff in the environment, right? do you just write your apps to pull out $ENV{BLAH} and use it?
02:39 noganex_ joined #mojo
04:04 sri hmmm
04:04 sri there is a huge advantage to reusing the normal static file handling for assets
04:05 sri static files shipping with plugins would automatically work
04:41 laouji joined #mojo
04:59 xaka joined #mojo
05:27 Foxcool joined #mojo
06:11 perler joined #mojo
06:13 perler joined #mojo
06:21 Averna joined #mojo
06:27 ovnimancer joined #mojo
06:28 dpetrov_ joined #mojo
06:33 spleenjack joined #mojo
06:39 fhelmber_ joined #mojo
06:43 memowe \o/
06:44 duncanthrax_work joined #mojo
07:08 Vandal joined #mojo
07:15 Vandal how can I disable auto_escape?
07:18 baton8 joined #mojo
07:20 Mike-PerlRecruiter_ joined #mojo
07:26 yakudza joined #mojo
07:28 pau4o joined #mojo
07:29 cosimo joined #mojo
07:30 Kwa Vandal: In templates?
07:30 Vandal yes
07:31 Kwa vandal: http://mojolicio.us/perldoc​/Mojo/Template#auto_escape
07:31 Vandal so?
07:31 Vandal I read this
07:31 Kwa Vandal: but if using templates and you just want to return the result, see http://mojolicio.us/perldoc/Mojolic​ious/Guides/Rendering#Embedded_Perl
07:32 Kwa s/return/print/
07:32 Kwa <%== Perl expression, replaced with result %>
07:32 Vandal I know ep syntax
07:33 Kwa Excellent.
07:33 Vandal I don't want to print <%== for unescaped strings
07:33 Vandal I want <%=
07:33 Vandal for this I need to desable http://mojolicio.us/perldoc​/Mojo/Template#auto_escape
07:34 Vandal but I don't see how to do it from app or controller or else
07:38 Kwa Vandal: Ah, OK. I don't know what you do and don't know, so covering bases. :)
07:39 Kwa You probably need to set options: http://mojolicio.us/perldoc/M​ojolicious/Plugin/EPRenderer
07:40 Kwa Vandal: Auto escape is set by default to prevent XSS attacks, but I think you can overwrite it. (Don't hold me to that though.)
07:41 Vandal it wasn't enabled in v2, so I just trying to make my code work without rewrite every template
07:45 Kwa Ah. Unless you have hundreds of templates, it's probably worth leaving it on by default, and finding the places where you need it to be off. Your call obviously.
07:45 ladnaV joined #mojo
07:53 Vandal Kwa, it helped, thanks
07:53 Kwa No worries.
07:58 spleenjack joined #mojo
08:05 davido joined #mojo
08:10 batman joined #mojo
08:19 Vandal joined #mojo
08:27 davido joined #mojo
08:33 ladnaV joined #mojo
08:37 Vandal joined #mojo
09:06 judofyr joined #mojo
09:20 Lucas1 joined #mojo
09:29 Vandal joined #mojo
09:29 cosmincx joined #mojo
09:34 ladnaV joined #mojo
09:36 daxim joined #mojo
09:44 Britzel_ joined #mojo
09:44 batman left #mojo
09:45 batman joined #mojo
09:46 Lucas11 joined #mojo
10:03 cosmincx joined #mojo
10:10 tholen joined #mojo
11:02 Lucas1 joined #mojo
11:12 baton8 joined #mojo
11:14 AmeliePoulain joined #mojo
11:22 rem_lex joined #mojo
11:49 baton8 joined #mojo
11:50 SmokeMachine joined #mojo
12:47 d4rkie joined #mojo
12:49 diegok sri: Looks nice, but I think it needs pre-filters and post-filters. Also it need to be possible to configure/predict a static file name so you can serve from outside mojo app.
12:50 diegok Actually I'm using a really small hack where I set which files produce which processed file and my app generate a signature for each at startup time
12:51 diegok I have a helper for those things that put all source files on devel and minified with query string signature on production
12:51 diegok I'm using bbb on deploy time to create the processed files.
12:52 diegok having filters and wrap each external tool looks really nice :)
13:31 cosimo joined #mojo
13:41 mikegrb joined #mojo
13:48 Vandal joined #mojo
13:53 inokenty joined #mojo
14:00 jnap joined #mojo
14:02 batman joined #mojo
14:02 sh4 joined #mojo
14:05 Adura joined #mojo
14:07 batman left #mojo
14:11 batman joined #mojo
14:19 batman joined #mojo
14:19 cosimo joined #mojo
14:29 knshaum joined #mojo
14:29 inokenty joined #mojo
14:31 gryphon joined #mojo
14:33 pau4o left #mojo
14:36 sri Vandal: auto_escape was not disabled in Mojolicious 2.x
14:36 Vandal well it acts like it was
14:37 sri i bet it has been enabled since 1.0 or so
14:37 Vandal %= was unescaped
14:37 Vandal %== was escaped
14:37 Vandal now it opposite
14:40 sri this is from 1.0 https://github.com/kraih/mojo/blob/9b25​6ec60b9d15183419603e37463b76b097c121/li​b/Mojolicious/Plugin/EpRenderer.pm#L22
14:40 sri it has been enabled ever since
14:41 sri diegok: what's the point of pre filters?
14:42 sri diegok: and what do i need to predict/configure static names? i'm afraid i don't understand
14:42 sri *+for
14:42 diegok sri: sorry.. I'll try to explain it better :)
14:43 labrown joined #mojo
14:43 diegok You have filters now. but a filter can be a minifier but also a pre-processor, right?
14:43 diegok coffee for example
14:43 diegok (or that's the idea)
14:44 sri i have a filter chain though
14:44 diegok but you might want to process ep first, then cofee, then join all together and then uglify
14:45 sri ('app.js' => ['*.coffee'] => 'coffeescript' => 'js_min' => 'whatever')
14:45 diegok pre and post I've named for before and after joining
14:45 sri how would the dsl look for that?
14:46 diegok hm... so you have to define every processor for every final file?
14:46 sri i think i understand that point now, and it's something i considered an open problem
14:47 diegok sure... I was reading backlog and comments on gh
14:47 diegok And I'm not bringing anything new I think
14:47 sri diegok: what's the better solution?
14:47 diegok that's the good question :)
14:47 diegok hm...
14:48 sri ah, i thought you had an answer
14:48 diegok I'm thinking on a perl plugin config plus perl file config.
14:48 sri the second part i don't undrstand... predicting names
14:48 diegok I like the idea of using extensions
14:49 diegok You have the name... it's app.js in this case.
14:49 diegok app.js is made from all this cofee files plus this js file
14:50 diegok so, that's ok. We only need to store app.js somewhere 'predictable' so my webserver can do it's job without mojo.
14:50 batman left #mojo
14:51 sri that's also an open problem i talked about before ;p
14:51 diegok I think judofyr also said that.
14:51 sri and very easy to solve
14:51 judofyr I believe I did
14:51 diegok :)
14:51 sri pretty sure i mentioned the solution
14:51 diegok sure, it's easy solvable
14:52 judofyr sri: there are some cases where you need to filter before concatenating (e.g. coffee-script)
14:52 sri and it's imo not very important for the first version
14:52 diegok thats my 'pre-filters' :)
14:52 sri judofyr: but how should pre-filters work?
14:53 sri app->asset('app.js' => ['*.js', ['*.coffee' => 'coffeescript']]); ?
14:54 judofyr I think that makes the most sense
14:54 sri or rather app->asset('app.js' => ['*.js', ['*.coffee' => 'coffeescript']] => 'js_min'); for a pre and post filter
14:55 diegok is there any need for module.coffee.ep ? (I'm not doing this)
14:55 judofyr the nested array isn't very pretty, but I'm not sure if there's a better way :/
14:55 sri currently all assets are required to have only one extension
14:56 diegok I seem to like this last one..
14:56 sri judofyr: nested assets i guess
14:57 sri app->asset('coffee.js' => ['*.coffee'] => 'coffeescript'); app->asset('app.js', ['*.js', 'coffee.js'] => 'jsmin');
14:57 diegok well, what I mean is it can be useful, for example for embeding templates into a js file, to process ep before coffee...
14:57 judofyr hm…
14:58 sri diegok: problem is everything with two extensions in DATA belongs to the renderer and is considered templates
14:58 diegok ouch :-/
14:58 diegok sure... I've read that on the backlog...
14:59 sri judofyr, diegok: which pre-filter version you like more
14:59 sri ?
14:59 diegok I like first more. Seccond seems more extensible.
15:00 sri oh, 5 positive responses to the asset pipeline on twitter, no negative :)
15:00 sri diegok: i think they are equally extensible
15:01 judofyr I'm kinda partial to the second right now
15:01 judofyr but maybe it'll get messy quick
15:01 sri :S
15:01 judofyr sri: does this mean that /one.coffee will serve the (unfiltered) file?
15:02 sri currently it does
15:03 sri only files with double extension are protected (since they belong to the renderer, not the static dispatcher)
15:03 sri it might be possible for us to use double extensions for assets too though
15:04 sri (or more extensions)
15:05 diegok I'm not using coffee so I can see I need to serve js files on dev mode and js-min file on production... but when you have coffee kind of filters you also need partial files to be filtered...
15:05 diegok (I'm just thinking loud)
15:06 * sri doesn't understand again
15:06 diegok double extensions seems the right way to me but I need to understand better all implications...
15:08 diegok means: app.js is made from jquery.js, jquery.plugin.js, jquery.plugin2.coffee and my_dirty_code.coffee
15:08 cosimo joined #mojo
15:08 sri didn't we solve that problem already?
15:09 sri dev vs production filters is kind of a problem, not sure how to solve that
15:09 diegok in development I serve it without moining nor minifing right?
15:09 sri how do we say which filters are required during development?
15:09 diegok taking pre-filters out is not a big problem
15:10 diegok that's my point
15:10 sri huh? coffeescript is a pre-filter
15:11 diegok you convert coffee to js and then you join+minify
15:11 sri yes, you can't take out coffeescript
15:11 diegok so, how I see this is pre-filter join post-filter
15:12 sri i think there's a better solution
15:12 sri you just say if a filter is important when registering it
15:12 diegok hm... coffee runs on the browser too... but I've never tried.
15:12 sri app->pipeline->filter(coffeescript => sub {...}); app->pipeline->optional_filter(jsmin => sub {...});
15:13 sri and you get enough methods on ->pipeline to switch things around
15:13 diegok optional filters only runs on production?
15:13 sri yea
15:13 diegok why not production_filter then?
15:13 diegok :)
15:14 diegok but yes... this can work :)
15:14 diegok besides naming
15:15 diegok so, you pre-define your filters on you pipeline singleton and then you name all your asset groups? (I like that)
15:15 sri biggest open problem now is dirct access to /foo.coffee through the static dispatcher
15:16 sri diegok: it's not a singleton
15:16 sri app specific instance
15:16 sri the /foo.coffee file may contain .ep code and the like...
15:16 diegok oh!, sure!
15:18 diegok so, we process every file with ep before any external filter?
15:18 sri no
15:18 diegok only coffee?
15:18 sri but ep may be a pre-filter
15:18 diegok ok
15:18 sri 'ep' => 'coffeescript' => 'jsmin'
15:18 diegok so, I need to say some way that
15:20 diegok ep and coffee are pre, jsmin is post...
15:20 diegok ok, but you've defined that before...
15:20 sri yes, but the course file is public atm
15:20 sri *source
15:20 sri *files are
15:20 diegok yes... that still an open problem.
15:21 diegok (I'm still trying to fully understand what we have)
15:21 sri only way to hide assets would be to require double extensions and go through the renderer
15:22 diegok we want to go through the renderer anyway when using ep... what will be another usercase for double extensions?
15:22 sri disadvantage of that however would be that we have no access to static files in plugins
15:22 sri diegok: that's not a problem, inline rendering
15:23 * diegok has fish memory
15:23 sri i think we have absolutely everything solved, except for source files being public
15:23 sri and we have not decided if source files being public is a bad thing
15:24 diegok It's not a big problem to me to have source files public. I can set nginx to forbid the thing.. but it would be nice to have it solved anyway :)
15:24 diegok is it for you?
15:25 sri since assets source files need to be named explicitly with extensions, we could just take files from the static dispatcher (one extensions) *and* files from the renderer (with multiple extensions) and not treat them special
15:26 sri i don't think atm it's a problem
15:26 diegok :)
15:26 sri and it's easily solved by allowing one extension for a public source file and multiple for a hidden one
15:27 diegok On my use-cases it seems completely fine...
15:27 sri asset 'app.js' => [['*.js.ep' => 'ep'], '*.js'] => 'jsmin';
15:28 diegok but I can't see any use-case for double extension more than something plus ep
15:28 bobkare would a possible solution be to have the asset plugin also look in a separate dir instead of or in addition to /public?
15:28 sri you could name them foo.js.asset just to hide them without special meaning
15:28 diegok oh, ok.
15:29 diegok having separate folder seems also right to me
15:29 sri bobkare: directories are not a problem, files in the DATA section are
15:30 bobkare ah, of course, since they are named just foo.ext and not public/foo.ext. Right, didn't think of that.
15:31 bobkare hiding by adding a second extension sounds a bit hacky though, the kind of non-obvious thing you have no chance of guessing without reading (and remembering) docs
15:32 sri bobkare: you should know templates (indicated by multiple extenions) are hidden
15:32 sri it's nothing new
15:32 diegok well... having single file app that depends on node and another gazillion tools is also a rare case...
15:33 diegok but I know.. it can still use pp filters...
15:33 bobkare that makes intuitive sense - they are templates that need to be processed further before they are useable on the client. Not so obvious for a plain CSS file or something
15:33 sri btw. another solution for optional filters app->pipeline->production_filters([qw(jsmin cssmin)])
15:34 sri bobkare: why would you hide a plain css file?
15:34 bobkare some people want to obfuscate as much as possible
15:35 sri i don't think minority cases need to be obvious
15:35 sri just being possible should be more than enough
15:36 bobkare yeah, I guess it's a pretty rare thing to actually need
15:39 bobkare that last solution for optional filters sounds good
15:40 skrife joined #mojo
15:41 sri we may also need a new helper name
15:42 rem_lex|pivo joined #mojo
15:42 sri since the word asset is already in use for Mojo::Asset, which i guess could be confusing
15:42 sri perhaps filter
15:43 sri i guess it would be a lite keyword if it was in core
15:43 sri filter 'app.js' => [['*.js.ep' => 'ep'], '*.js'] => 'jsmin';
15:43 xaka joined #mojo
15:47 pierrick joined #mojo
15:49 diegok *.js will pick all js files from where?. In some of my use-cases I will have several dirs with js files...
15:51 diegok filter 'app.js' => ['modules/*.js', ['app/*.coffee.ep' => ep => 'coffeescript']] => 'jsmin';
15:51 diegok looks fine :)
15:53 diegok pipe 'app.js' => ['modules/*.js', ['app/*.coffee.ep' => ep => 'coffeescript']] => 'jsmin';
16:00 good_news_everyone joined #mojo
16:00 good_news_everyone [mojo] kraih pushed 1 new commit to master: http://git.io/Jl6niw
16:00 good_news_everyone [mojo/master] fixed json_is bug in Test::Mojo (closes #401) - Sebastian Riedel
16:00 good_news_everyone left #mojo
16:02 sri diegok: pipe is a perl function
16:06 bluescreen joined #mojo
16:09 diegok grrr :-(
16:14 sh4 joined #mojo
16:25 SirG joined #mojo
16:27 SirG What's the difference between 'bridge' and 'under'? Any pointers to info appreciated...
16:38 davido joined #mojo
16:41 dpetrov_ joined #mojo
16:56 sri perhaps using asset is ok too and there is not much potential for confusion
16:57 * sri shrugs
16:57 batman joined #mojo
16:57 kthakore hi sri
16:57 kthakore what did you pick for your DB?
16:57 sri \o
16:57 sri mongodb
16:57 kthakore coolio
16:58 kthakore using KiokuDB to talk to mongoDB?
16:58 sri no
16:59 sri SirG: ->under is to ->bridge what ->get and friends are to ->route
17:03 kthakore http://redisconf.com/video/ <-- very cool redis pres
17:03 sri marcus, tempire, crab: what are your thoughts on an asset pipeline?
17:03 SirG sri: now all I have to do is grok ->route :) But I suspect I get it; thx
17:03 sri :)
17:20 gryphon joined #mojo
17:22 njlg joined #mojo
17:39 sri think i like this option the most asset 'app.js' => [['*.js.ep' => 'ep'], '*.js'] => 'jsmin';
17:41 sri not sure it should be production_filters or development_filters though
17:41 sri we usually make development the exception
17:41 sri development_filters could be the ones that are always required
17:44 sri so much complexity, perhaps it shouldn't be in core
17:54 bobkare joined #mojo
18:22 cosimo joined #mojo
18:57 rem_lex| joined #mojo
18:57 abra joined #mojo
19:20 Mike-PerlRecruiter_ joined #mojo
19:23 vervain joined #mojo
19:24 sri http://groups.google.com/group/m​ojolicious/msg/e71a2d27e9fa35f1
19:24 sri i've sent a mail to the list with some of the open questions
19:25 Adura Wonder why they didn't call it BJSON...
19:40 sri hmmmmm, maybe splitting filters in categories does make more sense
19:42 sri compilers and compressors
19:42 sri compilers are required and tied to the source file extension, compressors optional and tied to the target file extension
19:45 sri app->pipeline->filters->{coffee} = ['coffee_script'];
19:45 sri app->pipeline->filters->{js} = ['jsmin'];
19:46 sri coffee_script is a compiler, and jsmin a compressor
19:47 sri asset 'app.js' => '*.coffee', '*.js';
19:47 sri just not sure how multiple extensions would fit in
19:59 sri yko: why did you poke me in the commit message?
20:05 Adura A filename convention could determine the order of parsing. "name.coffee.jsmin.js.asset": coffee script, then jsmin, then js content type, where .ass indicates it should be handled as an asset source.
20:06 sri why would you compress a source file?
20:07 Adura Well, no...
20:07 Adura the .coffee part comes before .jsmin.
20:07 sri you compress before concatenating all js files
20:07 xaka joined #mojo
20:08 sri and the problem with .asset is that we can't use normal static files shipping with plugins
20:09 Adura Well then, new directory time.
20:09 sri there may be Mojolicious::Plugin::jQuery providing jquery.js
20:10 Adura That's a... core plugin?
20:10 sri new directory would mean we can't have asset files in the DATA section and would also prevent static file plugins like the one above
20:10 sri no, that plugin does not exist
20:10 sri but it could
20:11 Adura So, assets aren't on the level of templates... yet.
20:11 sri assets don't exist yet
20:11 Adura Well, in your mind. :P
20:12 sri we have static files and templates
20:12 sri assets are just preprocessed and cached versions of those
20:14 Adura Subdirs in the static dir?
20:16 sri then it's again all public
20:16 Adura Doesn't seem horrible, but, alright.
20:17 sri which might not be desirable for foo.css.sass.ep
20:20 sri i just don't see a clean solution for the source file storage problem
20:21 sri this might be the end of the assit pipeline as a core feature
20:21 sri *asset
20:21 Adura So... templates/assets/jsmin/{cof​fee,sugar}/sourcefile.js.ep
20:22 sri and without ep preprocessing?
20:22 Adura Well, could drop the .ep at the end?
20:23 sri and then it wouldn't work in the DATA section again
20:23 sri since one extension means static file there
20:24 sri and of course once again the jquery static file plugin problem
20:25 Adura I don't know if core files should be biased towards certain libraries.
20:25 Adura Core files don't touch CPAN, right?
20:25 sri plugin 'jQuery'; could add a static path to app->static->paths that makes /jquery.js available
20:26 Adura So, don't touch jQuery...!
20:26 sri the point is that we *want* to touch it
20:27 sri you add features from plugins that might have javascript attached which we want to include in the app.js file
20:27 Adura Then, plugins will need to register as asset-able...?
20:28 sri when would a plugin not be asset-able?
20:28 perlite joined #mojo
20:28 Adura Just a flag.
20:28 sri assets are not supposed to replace normal static files
20:29 sri but what's the point of the flag?
20:30 Adura Well, I assume your concern about having jquery and an asset'd file on a single page would cause some sort of toes being stepped on...
20:30 sri nope, i don't care about that
20:30 Adura Oh, ok.
20:31 sri the problem is how do we say what needs to be preprocessed when and how
20:31 sri if you don't want jquery.js in your asset don't use a greedy glob, that's no problem at all
20:32 lukep joined #mojo
20:32 sri only the developer knows what is asset-able and what isn't
20:33 Adura templates/{assets_ep,assets_static}/j​smin/{coffee,sugar}/sourcefile.js.ep, assuming it's easy to change the template handler at that stage...
20:34 sri directories still make no sense
20:34 Adura They don't?
20:34 sri nope
20:34 Adura Oh... hmm, make sense to me.
20:34 Adura They tell what you're doing.
20:35 sri how would you say that you want to jsmin and include jquery in your asset?
20:36 sri it is available as /jquery.js and you can't change its path
20:36 sri or /someplugin/js/foobar.js
20:36 sri that's what we have
20:37 sri we encourage doing that in the documentation
20:38 sri if we could go with directories we could just as well go with multiple extensions like foo.css.sass.ep
20:38 sri it's an entirely separate system
20:38 sri the point is to make an asset pipeline work with what we have
20:38 dabudabu joined #mojo
20:39 Adura Dispersed JS files?
20:39 sri yes
20:39 Adura Well... that's not going to be intuitive or fun.
20:39 sri dispersed in many many different root paths and DATA sections under all kinds of arbitrary names
20:39 Adura Godo luck?
20:39 Adura *Good
20:40 sri my original proposal does just that
20:40 sri but you have me worried now... perhaps folks didn't actually understand it :/
20:41 sri one more reason against it
20:41 Adura Or, I just had my own idea.
20:41 Adura My own idea based off of my personal usage of Mojolicious.
20:42 Adura So, don't take it as expert Mojol user opinion.
20:42 sri maybe this can only exist as plugins and not in core
20:42 sri well, the only framework that has it in core is rails, and i hate the rails version :)
20:43 Adura I think css and js should be statically dealt with anyways.
20:43 Adura I don't even use Mojol's static handling, I use lighttpd.
20:51 GabrielVieira joined #mojo
20:53 Adura Ah, reddit had bad weather in the cloud.
21:01 zivester joined #mojo
21:07 rem_lex|pivo joined #mojo
21:14 tempire sri: my proposal for asset config
21:14 tempire https://gist.github.com/3934394
21:16 sri tempire: what is paths?
21:17 tempire for adding optional asset paths
21:17 tempire would default to assets
21:17 tempire or whatever makes the most sense
21:17 sri tempire: so assets are completely separate from static files and templates?
21:18 sri or where are the source files located in your system?
21:19 tempire It could be templates.  Might make more sense to have the default be the home directory, and the names in the asset groups specify from there.
21:20 sri afraid i did not understand that
21:20 tempire the home directory meaning the level above templates/public
21:20 tempire and then specify exactly where you want everything in the asset groups.
21:20 sri $HOME/assets ?
21:22 tempire I was originally thinking $HOME/assets, but thinking now that the root should just be $HOME
21:22 sri wut?
21:22 tempire and then specify the glob paths in the asset groups.
21:22 sri $HOME/jquery.js?
21:22 tempire I'm not sure where the miscommunication is.
21:23 sri maybe give an example?
21:23 sri the config file doesn't answer any of the interesting questions i'm afraid
21:25 sri like where is it getting file.scss.ep from?
21:26 tempire in the gist, it's getting them from js_name1, some-arbitrary_name, css_name1
21:26 sri now you lost me completely :)
21:28 * sri tries again
21:28 sri what is "/css/some/file.css"?
21:28 sri where is it?
21:28 tempire reload the gist
21:29 tempire Took the root path off - in this case, it would be $HOME/assets/css/some/file.css
21:29 tempire because of the paths parameter
21:29 tempire with the prefixed /, it would be $HOME/css/some/file.css
21:29 sri i see, so assets can't be in the DATA section
21:30 sri (or rather asset source files)
21:30 tempire you mean like for lite apps?
21:30 sri yes
21:30 sri or plugins that embed files in DATA
21:30 tempire if they had the right path, I don't see why not.  it would be more work, since the preprocessor would have to load every file.
21:30 tempire @@ css/some/file.css
21:30 sri DATA is everywhere now that we have app->static->classes and app->renderer->classes
21:33 tempire I don't see why it would be a problem.  The pipeline would have to look as all those files, but the renderer has to do that anyway.
21:34 sri i'm afraid it doesn't work that way
21:35 sri the static dispatcher has /public and all DATA files with only one extensions in its classes, and the renderer has /templates and all DATA files with multiple extensions in its classes
21:36 sri everything that belongs to the static dispatcher is always public, everything that belongs to the renderer is hidden
21:38 sri the pipeline will have to deal with all that and combine it somehow
21:41 sri your config file has more problems though, some_arbitrary_name seems useless
21:42 sri how are we supposed to know if it's css or js?
21:43 tempire how else would you specify different blocks of assets in different places.
21:43 tempire *?
21:43 sri asset 'foo.js' => '*.js';
21:43 sri i give it a real name with extension
21:46 tempire I guess that's fine.  easier to implement, certainly, I was thinking the ext should be specified in the file names, and the pipeline would output whatever html tags were necessary.
21:47 tempire maybe it's just too much of a hassle to specify .scss.ep.some_other_handler
21:48 sri yea, far too many problems
21:49 sri i'm -1 on the asset pipeline now
21:49 tempire because?
21:49 sri too many ways to implement it wrong
21:50 sri and we are not even close to getting it right
21:50 tempire ok, so -1 on asset pipeline with the current proposals.
21:50 sri well, yea
21:51 sri the biggest problem is interaction between static dispatcher, renderer and pipeline
21:51 sri a good solution would make it look like they were designed for each other
21:52 zivester joined #mojo
21:55 sri and i don't think that's possible with the current DATA section design
21:56 sri should maybe have used prefixes like @@ public/foo.txt
21:58 sri wouldn't solve the overlap problem between assets and public though
22:00 sri we mostly use static classes/directories atm like rails uses asset directories
22:00 zivester_ joined #mojo
22:23 sri tempire: i can still be a CPAN plugin of course
22:23 sri *it
22:23 * sri can't
22:32 jzawodn joined #mojo
22:44 zivester joined #mojo
22:45 kvorg_ joined #mojo
22:46 kvorg_ Hi. I am a bit late to the asset pipeline discussion. Any decisions?
22:53 tempire sri: understood.  the problem is as you implied - I don't want to release a cpan plugin unless it's clean.  it doesn't feel right as it is.
22:54 sri kvorg_:  yea, there are too many unsolved problems, so odds are there will be no asset pipeline in core for now
22:55 zivester joined #mojo
22:55 sri see also backlog
22:59 sri you're welcome to solve the problems ;)
23:00 kvorg_ One of the problems seems to be exposing public/ or mot including things such as jquery.js? What if it allowed a default dir,  i.e.  filtered/, but also a helper to expose/include/register specific files?
23:01 sri that seems rather pointless, you could just as well be more specific when compiling your assets
23:02 sri the exposing public problem is about exposing source code to the world, not the asset pipeline
23:02 kvorg_ Ok, obviously i am missing the point...
23:03 sri it seems the problems are rather hard to grok
23:05 kvorg_ Yes, but then new source files are in a different dir (prefix for DATA), and hidden from static dispatcher. Anyway, i probabl don't fully understand.
23:06 sri prefix for data would break backcompat
23:14 kvorg_ If you allow asset register=>jquery.js to include a file, the compatibility is back, and any source from existing data section (besides templates) is obviously already public, no?
23:15 kvorg_ I am probably too far behind to provide useful input anyway. Sorry for interrupting.

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