00:00:05 <ozgura> searching for it now though.
00:06:33 <ozgura> nope, couldn't find it.
00:06:56 <ozgura> would anyone know, how does one set the enctype for an ajax request?
00:07:04 <ozgura> or does this even make sense?
00:07:56 <ozgura> this seems considerably ugly: http://stackoverflow.com/questions/5663207/how-to-submit-form-with-ajax-using-enctype-multipart-form-data
00:08:30 <donri> http://hacks.mozilla.org/2010/07/firefox-4-formdata-and-the-new-file-url-object/ maybe
00:10:16 <ozgura> this is weird. people seem to try to set the enctype to multipart/form-data for uploading files. this is not really what I am after.
00:10:49 <donri> i think the point is it sends the data "raw" without any encoding
00:11:32 <ozgura> hmm
00:12:09 <donri> ozgura: maybe just call encodeURIComponent() on the data first
00:14:09 <ozgura> donri: thanks for trying, but no :)
00:14:18 <donri> no?
00:14:33 <donri> it encodes + so happstack shouldn't interpret it as a space
00:15:16 <stepcut> hmm
00:17:07 <ozgura> I said no too soon. I don't think I tried it at all correctly.
00:17:13 <ozgura> do I need to decode on the happstack side now then?
00:17:48 <donri> don't think so
00:18:10 <donri> i thinkt he issue is that jquery and happstack are defaulting to different encodings
00:18:51 <stepcut> http://en.wikipedia.org/wiki/Percent-encoding#The_application.2Fx-www-form-urlencoded_type
00:18:58 <stepcut> how does that relate?
00:19:23 <donri> yea i think + for space is non-standard
00:19:38 <donri> decodeURIComponent('+')
00:19:38 <donri> "+"
00:19:44 <donri> so if encodeURIComponent works it's a hack :)
00:20:15 <stepcut> donri: http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1
00:20:29 <stepcut> says right there that, Space characters are replaced by `+'
00:20:39 <donri> interesting
00:21:01 <stepcut> for application/x-www-form-urlencoded
00:21:07 <donri> so jquery is wrong?
00:21:13 <stepcut> I didn't say that
00:21:28 <donri> well it sounds like it doesn't do what forms do :)
00:21:48 <donri> ozgura: how are you using jquery anyway
00:22:17 <stepcut> I'm not claiming happstack is doing the right thing either.. just that + for space is a standard
00:22:23 <stepcut> bbiab.
00:22:45 <ozgura> donri: $.ajax({ type: "POST", url: "url", data: "some-data", , success: doSth, async: true })
00:22:54 <donri> ozgura: so you're passing a string to data?
00:23:04 <ozgura> (the double , is copy/paste error)
00:23:06 <ozgura> donri: yes.
00:23:21 <donri> try passing an object instead
00:23:25 <ozgura> and I expect the same string on the server :)
00:23:32 <ozgura> will try.
00:24:10 <ozgura> the data is key value pairs by the way
00:24:12 <donri> well "looks" expects a key name
00:24:18 <ozgura> in this instance it is only one:
00:24:36 <donri> try {key: 'data'} instead of "key=data"
00:24:43 <ozgura> donri: ok.
00:26:26 <ozgura> wow, works!
00:26:35 <ozgura> as if by magic.
00:26:38 <ozgura> to me anyway
00:26:58 <donri> \o/
00:27:23 <donri> the magic of telling underlying code more about your data ;)
00:28:05 <ozgura> I assumed POST would work just like GET
00:28:11 <ozgura> hence the problem I suppose
00:28:27 <ozgura> so I can post a json object as it is, directly
00:28:39 <ozgura> which not only solves my problem, but also simplifies the code
00:28:51 <donri> it is similar... you can't just GET /some/url?with unencoded query string
00:29:23 <ozgura> donri: well but you cannot do GET /some/url?{foo:"bar"}
00:29:24 <donri> it's not json by default, don't think you can post a nested data structure for example
00:29:41 <donri> nah but jquery encodes it in both cases
00:29:56 <ozgura> oh these clever frameworks
00:30:01 <donri> :)
00:30:29 <donri> i recommend yui over jquery... but i don't think it's much difference in this case
00:30:51 <ozgura> any objective reasoning?
00:30:59 <ozgura> or is it just personal taste
00:31:43 <donri> it "feels" more like a programming library/toolkit whereas jquery "feels" more like, "css++"
00:32:04 <ozgura> eheh
00:32:11 <ozgura> anyways, I gotta go now
00:32:16 <ozgura> thanks for all the help
00:32:17 <donri> it's more modular and has a lot of modules that it can load on demand with dependency tracking and minimized http requests
00:32:42 <donri> even for third-party modules you can load those from a hosted CDN
00:33:00 <ozgura> will look into yui when I have the time
00:34:19 <donri> it also includes well-tested and thought-through css "modules"
00:34:43 <donri> and it's very well documented
00:36:56 <donri> plus it has "scoped configurations" to be compared to jquery's use of a global, single-letter object ($)
00:42:04 <alpounet> YUI looks pretty cool
00:42:09 <alpounet> i'll try it some day soon
00:42:28 <donri> it is! people seem to ignore it because they looked at it when it was at version 2. yui3 is quite a different beast...
00:42:39 <luite> donri: you don't have to use that, i think it's even recommended to use jQuery instead
00:43:35 <donri> luite: which is still global :)
00:43:50 <donri> YUI has a global YUI object but its primary purpose is to create these scoped configurations
00:43:50 <luite> yui doesn't have any globals at all?
00:44:04 <donri> it's related to the module system
00:44:18 <luite> hmm, how is that better than a global jQuery one?
00:44:21 <donri> while in jQuery you <link> all the "modules" and they attach themselves to the global jQuery object
00:44:55 <donri> not that i've written anything complicated enough for that to be a problem, but i like to worry about these things up front ;)
00:46:04 <luite> for me, bigger problems are that jqueryui development progress seems to be rather slow
00:46:10 <donri> also works well with jmacro because there's no need to <link> stuff so less need for something like yesod widgets
00:46:20 <alpounet> donri, heh, never tried yui at all, and barely used jquery once, so i'm not really biased here, just being curious
00:46:44 <luite> grid is not going to be stable any time soon, no release plan for 1.9
00:47:42 <donri> luite: http://yuilibrary.com/yui/docs/datatable/ this anything like grid?
00:48:20 <luite> donri: hm say you want to make some server-side component that shows a datagrid, how would you get that to load with yui and jmacro?
00:48:43 <donri> what do you mean
00:49:45 <luite> yeah i know there's something similar in yui, not sure if the jquery one is better in terms of features or other things
00:51:25 <luite> donri: well you said that yui reduces the need for yesod-like widgets. for a datagrid jquery widget, i'd add the datagrid .js scripts to the widget with addScript, then output the relevant html for this particular grid. that way the required .js sources get added to the minified bundle served for that page.
00:53:01 <luite> for jmacro, you might do something like yui.load('grid'); and then run the rest of the code?
00:53:21 <donri> i mean if you have third-party modules like "datatable" you load those via yui instead
00:53:50 <luite> hmmm that seems a bit less scalable
00:53:53 <donri> YUI().use "datatable" \y { y.DataTable... }
00:54:39 <donri> how do you mean?
00:55:23 <luite> well it depends a bit... but usually modules would be loaded from separate files, or does it have some way to optimize that?
00:55:43 <donri> modules can be "combo loaded" by having the server concatenate them (that's done for you for hosted modules, but it's easy to write your own "combo handler")
00:56:13 <luite> hmm, i was planning something like that for ghcjs, but i'm still not sure that's a good idea
00:57:26 <luite> ghcjs now makes a javascript global var for all haskell symbols :)
00:57:30 <donri> the plus side is that it tracks js dependencies, i think you'd have to do that manually with yesod widgets?
00:58:03 <donri> there's still a place for yesod-like widgets though... i have some thoughts about how it might be done with hsp
00:59:11 <luite> yesod itself doesn't know about dependencies no
01:00:03 <luite> you could build something around the addScripts to deal with dependencies for your particular javascript setup, but it's really js-framework specific of course
01:00:40 <donri> as i noted yui is very modular, when you "use" one module it typically actually loads perhaps 10-15 modules... but they're merged server-side
01:00:57 <luite> yes i do something like that for ghcjs now
01:01:04 <luite> except the merging
01:01:11 <luite> since i'm undecided on that
01:02:21 <luite> since bundles are less likely to be cached on the client than individual js files
01:03:22 <donri> one might think so, but how often are you changing those "use" calls? they'll continue to result in the same bundles...
01:03:27 <luite> (there's a similar problem with yesod widgets of course, if you bundle lots of js together in a minified bundle, and you change a tiny bit for one page, you need to download it again)
01:03:42 <donri> true
01:03:55 <luite> i'm thinking about different pages that all have a different set of widgets that they actually use
01:04:20 <luite> yui's code is probably still relatively small
01:04:40 <luite> but if you have some heavy dependencies, you could end up with 10MB js code with ghcjs
01:04:53 <donri> i suppose it works well for versioned modules like yui's own, and perhaps less well for "my scattered scripts of about ten lines each"
01:05:22 <donri> especially if you load the larger modules together... though i think you can configure multiple "module sets" separately...
01:05:36 <donri> larger modules together with your own small stuff, i mean
01:06:31 <luite> hmm, do you have a link for such configuration? I was thinking to do something along those lines: request individual modules, but configure something that bundles some modules together
01:07:01 <luite> where one bundle would be base+integer-gmp+ghc-prim, another could be most of a package, except perhaps some big rarely used modules
01:08:50 <luite> (for most sites, an alternative ghcjs deployment would be better actually, with ghcjs-link, that actually removed all unused code from imported modules)
01:08:52 <donri> perhaps this? http://yuilibrary.com/yui/docs/api/classes/config.html#property_groups
01:09:38 <donri> http://yuilibrary.com/yui/docs/yui/ for where that configuration goes
01:10:02 <donri> "how many times can you fit 'yui' in a URL"
01:10:13 <luite> hehe
01:10:20 <stepkut> :)
01:10:48 <luite> ah that looks quite similar to what i have with requirejs
01:12:58 <luite> i still hope to remove all (manually created) javascript from my web projects :p
01:14:45 <donri> :)
01:20:06 <stepkut> It is easy to remove all manually created javascript from web projects -- the hard part is making that easier than just writing the javascript by hand :-/
01:21:50 <luite> yeah so far it isn't :)
01:22:05 <luite> also trying to install boot libs with cabal-install is a pain :(
01:22:20 <stepkut> :-/
01:23:15 <luite> (trying to register base, ghc-prim, integer-gmp, rts and a few more in ~/.ghcjs-7.4.1.0.1.0/package.conf.d/
01:23:18 <luite> )
01:24:01 <stepkut> i did some experimentation with a reactive widgets system built on top of HJScript -- which feels similar to the stuff the yesod people were recently experiment with. It became impossible to understand very quickly. And I keep trying to do, map someJavascript [0..10], which of course, generates someJavacript(0); someJavascript(1); someJavascript(2)... instead of a loop :)
01:24:12 <stepkut> (this was a while ago)
01:24:36 <luite> right, i think taht's why it's not really going to work in the end
01:25:08 <luite> you can really only program javascript semantics, even though you might make the interface a bit safer or cleaner
01:26:05 <stepkut> compiling haskell-to-js is attractive -- as long as you can live in an island. But, if you have to interactive with other javascript libraries that all objecty.. then you still have a big impendance problem
01:26:58 <stepkut> both it terms of ADTs vs Objects, and type system issues
01:28:57 <stepkut> I think I want a language that is designed from the ground up to intergrate easily with javascript, but suck far less. And it should also include simple mechanisms for specifying how to marshal its datatypes <=> JSON <=> Haskell types in some sort of simple, and type-checked manner. probably autogenerating the boilerplate code on both sides.
01:29:39 <donri> opa!
01:30:20 <stepkut> perhaps
01:30:30 <stepkut> I haven't had time to investigate
01:30:33 <donri> you still mean for use from haskell though?
01:30:36 <luite> opa also has server side, right?
01:30:38 <donri> (plus opa is agpl :p)
01:31:21 <donri> luite: https://github.com/MLstate/hello-opa
01:32:21 <donri> note how "action" is both server and client-side... that shit "just works" in opa
01:32:34 <luite> :)
01:33:27 <luite> maybe opa is a mcuh better solution for a single language on server and client, but fortunately i have a great excuse for my approach :p
01:34:27 <donri> ?
01:34:37 <donri> you mean beacuse the whole app is "haskell in the browser"? :p
01:34:43 <donri> hey you should compile hint with ghcjs ;)
01:35:03 <luite> yes
01:35:05 <luite> hehe
01:35:23 <luite> compiling hint means compiling the whole ghc of course
01:36:20 <donri> yea joking, though it would be interesting to try...
01:37:43 <luite> i think that targeting emscripten might work
01:37:55 <luite> not sure about doing it directly in javascript
02:10:27 <stepkut> if a form fails to validate and you redisplay the form with an error message.. is 200 OK still the best http response code?
02:10:54 <luite> hmm, i don't know a better one
02:11:00 <stepkut> me neither
02:12:31 <stepkut> bad request is due to syntax errors.. not bad data :)
02:12:54 <luite> 418 I'm a teapot maybe?
02:13:13 <stepkut> hmm
02:14:07 <luite> http://en.wikipedia.org/wiki/List_of_HTTP_status_codes <- was skimming this list for codes that looked relephant
05:04:17 <stepkut> k. the second draft of the formettes tutorial is 98% done. time for bed now.
20:18:45 <donri> stepcut: how's it going? :)
22:12:26 <stepkut> donri: good! Added CRSF prevention. Just tweaking the api for that a bit.
22:13:14 <donri> ok :)
23:18:33 <stepkut> tweaking done. Also made it easier to use multiple forms on the same page.
23:19:36 <donri> i'm so curious!
23:21:07 <stepcut> one moment
23:21:15 <donri> :)
23:23:04 <stepkut> darcs get http://src.seereason.com/formettes/
23:23:09 <stepkut> the tutorial is in the docs directory
23:24:02 <stepkut> the last tasks are to copy Text.Formettes.HSP.String to Text.Formettes.HSP.Text and change all the Strings to Text. And then to split formettes.cabal into formettes, formettes-happstack, formettes-hsp, etc.
23:24:21 <stepkut> and, to actually finish the formettes-blaze and formettes-heist support -- those are just proof of concept at the moment
23:25:00 <stepkut> also, I need to update the tutorial to talk about the CSRF stuff. It doesn't actually require you to do anything -- but it is nice to know that it happens :)
23:25:05 <donri> so the formettes name is final?
23:25:13 <donri> ACTION still likes "reform" :)
23:47:05 <donri> Forms have the type Form which looks like:
23:47:05 <donri> ] newtype .... (should be > not ])
23:47:35 <donri> can i record patches?
23:55:21 <donri> there are more of those