[00:04:16] YaronK, still around? [00:04:30] Yeah, I'm here... [00:04:53] What's the deal. [00:05:23] I've been doing some research on templates [00:05:23] http://en.wikipedia.org/wiki/Template:Chess_diagram#Standard_diagram [00:05:45] there are weird ones like that, where it would just look silly to put that in a form [00:05:51] Oh, man... I've seen that one. [00:05:59] Maybe... [00:06:16] yeah, among other things, they totally make up chess pieces for that template =) [00:06:29] What do you mean? [00:06:55] well, in normal chess there's no such thing as a "wizard" piece for instance [00:07:02] but anyways, that's beside the point [00:07:24] There's a wizard? :) [00:07:46] Holy crap! Crazy. [00:07:59] It's for "fairy chess". [00:08:02] Hokay... [00:08:07] my point is that a template writer should also be able to specify "don't use a form for this template" or something like "use only form type 'X'" [00:08:22] Right, yeah. [00:08:38] "Don't use a form" makes sense; what would be the other one? [00:10:40] well I was thinking it should be a top-level parameter tag, so it would look something like this [00:10:47] that way it would expressly say no handler [00:10:48] OR [00:10:58] Yeah, that makes sense. [00:11:47] let's say .... that way only if there's such a thing as a "chess" handler, it will be used, otherwise it defaults to 'none'... basically a way of saying "ok, if you don't have this kind of handler, you're better off showing the plain text version [00:11:49] " [00:12:15] Right... [00:12:48] What would a handler correspond to, though? Might that not be an example of app-specific data? [00:15:17] Like you could have "no" [00:15:20] it's stronger than app-specific data...it's a way for the template author to expressly say "if you parse this data as though it were standard field:value data, your end result won't make sense. Either pass it expressly to something of type X or just show it as text" the handler would be a type, not a specific app name. For instance if the hander were of type "chess", let's say, you'd be free to do any sort of "chess" visualization you want [00:15:56] My example would be, I guess, for *non*-chess templates. [00:16:43] Well, what would the chess handler be? A separate extension? A Javascript library? [00:32:09] ok, so we were just looking at the stuff returned by the API [00:32:37] with the XML returned, the root tag can only be one element, and as the API returns it, the root tag is [00:33:09] which means if there were multiple groups, the API wouldn't return valid XML [00:33:51] *TrevorParscal agrees with nimish and stuff [00:33:56] soo...instead of saying we would have be exclusively a *parser* tag, and inside of it have some sort of root element that indicates these things are key-value pairs [00:34:56] so, it'd look like

if you do, you end up with sillyness =) So, instead, we can expressly have a tag saying "this stuff should be interpreted as a key-value pair", we're using 'list' for now, we could name it whatever [00:44:35] so, if you have a root node, but no node, then we can ignore those elements and will just render them as text. You could surround them in or or whatever tags instead [00:44:42] and we'd still ignore them [00:46:19] so if we saw something that went like this: ...stuff for us here ... we'd go "aha, we'll use this stuff!" [00:47:23] if we saw ... stuff here... we'd expressly render it as text since we don't have any way to deal with "grid" data yet [00:48:06] so basically if there *is* a templateinfo tag, but the element is blank, we interpret that to mean "don't bother with forms, show the raw wikitext" [00:48:31] otherwise, no templateinfo tag, we show it as a 'default' key/value pair kind of list thingy [00:48:47] and of course, if there's a templateinfo tag with useful information, we use that accordingly [00:48:49] =) [00:49:54] Well, would there ever be anything between the templateinfo and "list" tags? [00:50:46] Oh, never mind... now I get it. [00:51:31] So "list", "grid" and "globe" are all different options? Where does it end? [00:52:33] I mean... what if there potentially more options than that? [00:58:07] Sorry, "where does it end?" sounds harsh. :) [00:59:27] it doesn't end [00:59:31] why would it end? [01:03:03] hm, would you prefer ? [01:04:48] :( [01:05:14] That, to me, seems to make a lot more sense... [01:05:44] TrevorParscal - I'm surprised that you'd prefer the other way, since you were always pushing for a smaller set of tags... [01:06:09] fieldtype is really amiguous [01:06:48] yeah - I do agree that we should limit the tags... [01:06:54] fieldtype is a crappy tag name though [01:07:04] Yeah, I agree the naming leaves something to be desired (here we go again... :) ) but the concept in principle makes sense. [01:07:17] sure [01:07:21] ? [01:07:26] hmm [01:21:02] YaronK...so if we were to have etc, our DTD wouldn't even make sense [01:21:37] so how bout back to the original idea of or whatever we want to call it [01:21:49] and making sure that propogates all the way up [01:22:00] Was that the original idea? [01:22:02] or [01:22:06] well, not quite [01:22:13] it's some version of the original idea =) [01:22:35] but...I kinda have to get going now too, email or whatnot with thoughts =) nimish@wikimedia.org [01:22:37] later! [01:22:57] Alright, I'll start off an email discussion... [18:35:59] adam_miller, TrevorParscal (in absentia): Please remember to bump style versions when changing JS [18:36:43] style version? even if you only js files? [18:42:53] Well versions [18:43:05] In UsabilityInitiative.hooks.php [19:53:44] *RoanKattouw wonders where Trevor is [19:53:54] He was in the meeting but he's not on IRC or Google Chat [19:57:00] out for lunch I guess [19:57:33] roan, are u finsihing the preview? [19:57:41] Finishing how? [19:57:53] or is it on adams agenda? [19:58:02] did you guys already have the meeting? [19:58:07] yes [19:58:25] Yeah I'm the one doing that [19:58:28] Not much left to do really [19:58:34] some layout changes [19:58:36] Cleaning up after Trevor's refactoring a bit [19:59:04] do you have the mockups for the preview? [19:59:21] No [19:59:35] hmm...hold on... I ll search them [20:00:09] hmm It appears I confused the time zones... [20:00:39] http://collab.wikimedia.org/wiki/File:091108_preview_3.jpg [20:00:53] mdale: Where are you then? [20:01:30] roan: if there is a second row we should not use the gradient as a bg [20:01:38] hannes-__: Oooh that's just styling changes, that's Trevor's piece of the pie [20:01:52] yeah - I am talking about styling [20:01:57] "layout changes" [20:02:12] ok, I ll poke trevor in that case [20:02:29] shooot, where is michael? [20:02:41] I was up to talk with him next [20:03:57] He's back [20:04:13] *mdale ? [20:04:41] mdale: Apparently hannes-__ wanted to talk to you [20:04:46] oky [20:04:48] And I was wondering where you were [20:05:12] been here all morning... [20:06:25] I mean like what's your location [20:06:49] I am in Mexico +2 hours from PST [20:07:10] Ah, so that's Central Time [20:07:30] yea [20:08:56] michael, you did the contentgenerationdialogs, right? [20:09:26] is there an uptodate version on prototype or sandbox? [20:10:12] .. I did not do the content-generation-dialogs [20:11:03] there are some helper functions for dialogs in js2 but i don't think those are not being used. ... [20:11:15] hannes-__: I wrote them [20:11:31] Nope, we've got our own dialogs plugin, but that works off jQuery UI dialogs too [20:11:41] hannes-__: Lemme update that for you [20:12:05] hmm... [20:12:23] who worked on the add media wizard? [20:12:36] That's Michael's baby [20:12:57] ahh ok... that's what I meant [20:13:54] Ooh, I like the new theme Trevor designed [20:14:01] *hannes-__ wanna see [20:14:18] jquery theme? [20:19:40] Sec [20:20:00] http://prototype.wikimedia.org/s-3/index.php?title=Category:Foo&action=edit [20:20:11] The dialog form fields freeze up, working on that [20:49:04] WTF [20:49:16] The dialog isn't broken on fr prototype, why the hell is that