[09:01:42] hey [09:01:42] (89 hours 30 mins ago) tell rworth sorry i missed your message, ping me when you get back [09:02:51] let's get this rolling [09:03:13] looks like we don't have an updated agenda [09:03:32] ugh, I just updated the old agenda [09:03:34] hold on [09:03:39] haven't gotten to that yet due to non-stop skype meetings... [09:04:08] haha [09:04:08] i dont have much/ant to report or add this weel [09:04:11] *week [09:04:16] *any [09:04:19] undo spans multiple sheets [09:04:26] I just lost my changes [09:04:37] doh [09:04:39] good to know [09:04:49] can't you redo? [09:07:12] nope [09:07:19] not sure why [09:07:26] ok, ready [09:07:37] ok [09:07:43] danheberden: infra updates [09:07:54] danheberden: is view. now on a cronjob? [09:08:16] rworth clarkbox is out of town for a bit - it isn't on crontab, but he said he had it on one [09:08:27] so i need to ask what he did before i break stuff - also there is a bug [09:08:36] so if it is cronning, it's not pulling for each branch [09:08:45] small bugs that i'm sure will be fixed by next week [09:08:50] ok [09:10:03] code.jquery.com listing? [09:10:35] eddie said he was working on it, but he's been missing-ish [09:10:55] this is just a static file, right? [09:11:00] yeah [09:11:24] just low priority busy work [09:11:31] I can update the file and send it to you [09:11:39] k [09:12:20] though i don't see the need to list them all [09:12:22] any update on recruiting? [09:12:28] google doesn't list all versions and they seem to do ok [09:12:41] no - adam and I haven't had time to talk about that [09:12:45] no new recruits [09:12:46] we list all versions of everything else [09:13:09] we never had our widget factory docs talk, i'm good to do that whenever in the next 3 days pretty much [09:13:28] scott_gonzalez if you want to spend the time on it, i'll make sure it gets up [09:13:38] Google also doesn't host alpha, betas, rcs [09:13:59] ok, it's only gonna take like 2 minutes [09:14:04] I'm only going to list 1.8.x versions [09:14:14] and then we'll add all future releases [09:14:23] we should probably also have 1.9m releases [09:14:49] which don't appear to be on the CDN right now [09:14:54] keep in mind those don't have themes, if that makes a difference [09:15:05] they have base [09:15:13] right, just not the rest [09:15:19] which is the only thing we're going to link to for old versions anyway [09:15:24] whereas alphas betas and finals have all [09:15:27] oh, ok [09:15:29] otherwise the list would be crazy to look at [09:15:37] confirm [09:15:40] :-) [09:15:52] ok, docs [09:16:15] rworth: want to talk about what you were able to get done [09:16:48] yeah [09:17:05] so, I created a node.js script to migrate xml docs from github into wordpress [09:17:19] it matches based on slug which it computes based on filename [09:17:37] if the post exists in wp_posts mysql wordpress table it updates the content [09:17:47] that is, if the slug is found [09:17:51] if not, it inserts it [09:18:13] script is at https://github.com/jquery/jquery-docs/blob/master/git2wordpress.js [09:18:37] I'd like to move it to either a different repo or a different folder so it can have a node-modules subfolder for dependencies [09:18:44] and a README for installation and use instructions [09:19:18] I also tested it out on my own dev server http://li367-225.members.linode.com/accordion/ [09:19:31] waiting for Darcy or Doug to help me touch up that theme a bit [09:20:00] but the content is all driving from wordpress posts sourced from xml in github, could be automated by cron or github commit hook [09:20:10] any questions? [09:20:30] oh, I also touched up the xslt a bit along the way. Not done, but better [09:20:52] next step is to automate migration of docs content from mediawiki into new xml schema [09:21:07] I need to summarize this status and next steps on the wiki page [09:22:04] that's it for me for docs [09:22:10] thanks [09:22:18] I updated the widget factory demo [09:22:25] so it has a generated element now [09:22:44] I also made some updates the widget factory docs [09:22:49] rworth, how about just adding package.json for npm-install to work and adding node-modules to .gitignore? [09:23:07] we need to setup a meeting to discuss the docs [09:23:21] jzaefferer: sure, that works [09:23:27] ajpiano, jzaefferer, and anyone else interested: let's pick a time next week [09:23:56] * rworth is out the next two full weeks btw [09:23:58] monday at 1pm? [09:24:35] (7pm CET jzaefferer :) ) [09:24:41] I'm pretty open the whole week, would prefer it in the morning (afternoon for me) [09:24:48] hm [09:25:40] scott_gonzalez the docs as the xml? [09:25:42] or deployment? [09:25:44] what about next thursday at like 10am/4pm [09:26:03] or the docs for widget factory [09:26:09] widget factory [09:26:11] ajpiano, that sounds good [09:26:16] scott_gonzalez coo [09:27:28] ajpiano: are there any days where morning works for you? [09:27:38] isn't 10am the morning [09:27:56] oh, sorry, didn't see that line [09:28:07] ah ok [09:29:21] that works for me [09:30:01] ok, that's it for docs [09:30:11] I landed 1.6.2 in master [09:30:21] everything seems to be working [09:30:22] sry, runnin late today [09:30:25] yay [09:30:49] we still need to land support in 1-8-stable [09:31:01] we still need to test that? as we did for master? [09:31:27] yeah, we have to do the whole process over [09:31:35] and it'll be different in 1.8.x [09:31:38] wanna pick the compsite testsuite to stable? [09:31:45] because we can't blindly use .prop() [09:32:15] jzaefferer: yeah, we'll get to that [09:33:04] we'll probably need to create a proxy like .attrProp() [09:33:20] and it'll go to prop() if it exists and fallback to attr() if it doesn't [09:33:22] gnarf, did you start on animation-related tests? [09:33:35] jzaefferer: can we go in order? [09:34:23] the compound test suite that jzaefferer mentioned is at http://view.jqueryui.com/master/tests/unit/all.html [09:34:33] it runs all of the (usable) test suites on a single page [09:34:43] we'll end up with a lot of compound test suites [09:35:09] we need to add support to run a test suite with different versions of jQuery core [09:35:33] right now we miss a lot of bugs because we only test against the latest version that we support [09:36:14] once we have the ability to run test suites with different versions of jQuery, we should create compound tests that run a plugin's test suite against all versions [09:36:34] so something like /autocomplete/all.html should run autocomplete against 1.6, 1.6.1, 1.6.2 [09:37:25] ok, now we're up to testing animations [09:38:01] gnarf did write some initial tests, but I don't think they're what we want [09:38:03] :) [09:38:12] we should probably have a discussion about what we're looking for [09:38:35] I think it's a bit confusing because the tests for animations should actually tests non-animation stuff [09:38:41] https://github.com/gnarf37/jquery-ui/commit/909f0683cde98a968a8e2193e0979a7bed5709d3 [09:38:42] http://bit.ly/o85Sge gnarf37 (2 days ago) on jquery-ui: Tooltip (Unit Tests): Asserting that hide/show options call correct functions for UI Effects and basic jQuery effects [09:39:05] apparently i missed the boat on the asserts with those tests :) [09:39:38] I think what we want to test is that the plugin behaves correctly when an animation is used [09:40:00] so looking at things like events firing at the right time (before or after the animation), position working properly [09:40:12] in the case of dialog, focus still being placed on the right element [09:40:24] basically making sure that the async path works properly [09:40:50] the other interesting thing to look at is whether the effects wrapper breaks anything [09:43:08] makes sense, and we can still use a bit of that approach i thin [09:43:22] just need to know the "final case" type stuff to add to those [09:44:21] yeah, I think we'll be able to just use one effect type [09:44:33] no need to test an effect and a jQuery method [09:44:46] since we have tests that show/hide actually works with all the various cases [09:44:51] right, stick to the "plain" effect [09:44:54] yeah [09:45:00] just make it async [09:45:03] right [09:45:30] and then test that whatever is supposed to happen after show happens after anim complete and whatever happens b4 show is done before anim start [09:46:07] right [09:47:47] i can dig in a bit more this week [09:47:57] cool [09:48:04] just wanted to start an approach, glad i did cuz i missed the point ;) [09:48:24] jzaefferer: wanna cover the rest of the items? [09:48:36] sure [09:49:02] landed the topalignment menu demo today, its just customizing the position option [09:49:17] the navigation menu demo is still pending, need to review that [09:49:27] (afk a bit pre-grid mtg) [09:49:29] kborchers, am I missing something else? [09:49:38] jzaefferer: any word from Hans on the focus stuff for the nav menu? [09:50:25] ah, right - nope, not yet, but he updated the datepicker PR, he's got some other tasks on his plate that are probably more priority right now [09:50:40] ok [09:50:53] still need to review the datepicker PR, that's a bit more involved, also includes updates for Popup [09:51:05] is anyone working on this jqbug.com/ui/5284 for todo #1 in menu? [09:51:09] as for selectmenu, I've emailed Felix, haven't heard back yet [09:51:24] kborchers, I don't think anyone is working on that [09:51:36] I had asked @wilto back in Toronto to take a look, but don't think that happened [09:52:35] any thoughts on an autoClose option to close menu on mouseout like with the autoOpen option in Menubar? [09:53:58] is that on the menu page? [09:54:03] in the comments [09:54:11] from Dalia [09:54:15] ah, okay [09:54:18] have to take a look [09:54:39] can you delete comments on the wiki? [09:54:47] yes [09:54:49] k [09:55:02] the only other issue is structures other than UL/LI or should that wait until the next version of Menu? [09:55:41] there's actually a visual test for a table based menu [09:55:50] tests/visual/menu/tablemenu.html [09:56:12] I'd still rather push that back before others issues are done [09:56:24] but if you want to dig into that, the test is a starting point [09:56:29] ok [09:56:45] I should probably put together an autocomplete example that uses a non ul menu [09:56:48] wanna look at the smarter collision detection? [09:57:00] sure [09:58:11] okay [09:58:24] for downloadbuilder: I haven't heard anything from Felix [09:58:32] @felixge that is [09:58:40] not the selectmenu felix [09:59:01] I think that's about it for UI [09:59:17] perfect timing :-) [09:59:40] there's actually another PR still open: https://github.com/jquery/jquery-ui/pull/406 [09:59:56] that should help with visualizing focus on menu, even without the native outline [10:00:31] should we do another pulls review soon? [10:00:48] or rather group pulls review [10:01:15] ok, time to start grid meeting [10:01:22] yeah, let's try to do one next week [10:02:40] let's get started [10:02:53] first item is Editing. jzaefferer you want to start? [10:03:23] sure [10:03:30] we've overhauled the editing events: http://wiki.jqueryui.com/w/page/40632995/Grid-Editing-Events [10:04:00] and wrote down the spec for the Editing API, which is basically $.observable with some modifications: http://wiki.jqueryui.com/w/page/41891169/Grid-Editing-API [10:04:15] going to implement that in the ui-repo soon, integrate it into the editing demos [10:04:38] started a page for databinding (aka data linking), not much there yet: http://wiki.jqueryui.com/w/page/43684051/Grid%20Editing%20Databinding [10:05:05] will also implement various updates on the editing widgets, like the inline editor and on grid itself [10:05:18] got a better concept now for integration between column configuration and the editor [10:05:29] jzaefferer: re: the removeProperty, what if the "newValue" was just null/undefined [10:05:34] expand the grid's columns option, have the gridEditor pick that up [10:05:46] gnarf: null is a valid value [10:06:16] newValue would have to not include the key while oldValue has it [10:06:19] that could work [10:06:25] gnarf: we don't want to detect the difference between passing undefined vs not having passed that argument [10:06:30] but null/undefined could be an actual value [10:06:48] or also, maybe a "removedValue" [10:07:03] seems like a solid api tho [10:07:09] we're going for parity with attr/removeAttr [10:07:25] Seems reasonable. [10:07:57] any objections to having removeProperty trigger a chance event where newValue is missing that removed path? [10:08:01] What's the rationale behind no "move" on $.observable? [10:08:22] jzaefferer: I don't understand. Can you use an example? [10:08:42] $.observable had a "move" operation for arrays...now it doesn't. [10:09:02] The example would be drag/drop a row in the Grid. [10:09:05] delete myCustomer.firstName; [10:09:05] $(myCustomer).triggerHandler("change", { oldValues: { firstName: "Bob" }, newValues: { }}); [10:09:21] Sorry, I'm talking about your editing API. [10:09:33] "move" on arrays [10:09:43] brado23, getting there in a minute [10:09:48] sorry [10:09:57] jzaefferer: is there going to be some sort of helper to help make those calls? [10:10:12] jzaefferer: if you do the operation yourself your only recourse is to call refresh [10:10:23] that's basically the implementation of removeProperty('firstName') [10:10:39] because it's only safe to assume we don't know the effect of what you did if you did anything without going through the API [10:11:03] rworth, that's how the events examples all look like, pseudo-implementation [10:11:04] doh, sorry I'm always interpreting your implementation examples as use examples, sorry [10:11:21] aha [10:11:24] so sthat is the helper [10:11:27] I blame brado23, he started those :p [10:11:31] k, up to speed ;) [10:11:44] so, any objections? [10:11:54] im worried that detecting the lack of newValue might be a bitch [10:11:55] so, can you give me the use example, so I can fully understand what you're suggesting? [10:12:07] thinking that people are going to probably be looping newValue not oldValue [10:12:10] removeProperty('firstName') [10:13:12] caught up [10:14:05] not having a separate event for removing properties would be nice [10:14:06] I agree change event is sufficient with the property there in the old, not in the new [10:14:20] so like, if a property is removed, and you were looping newValue looking for the "changed" values, and none are there [10:14:43] but it makes sense [10:14:57] so basically what we're saying is newValues will contain 0 keys in the case of removeProperty [10:15:19] and 1 for old [10:15:31] right, i guess so long as thats documented, end users will be aware of that [10:15:32] yeah [10:15:34] so going the other direction... [10:15:37] assuming removeProperty doesn't take an array of keynames, nor a space-separated list of them [10:15:40] if you .property( "foo", "bar" ) [10:15:45] and foo didn't exist before [10:15:53] would you not anything in oldValues? [10:15:58] yeah [10:15:59] yup [10:16:03] its oldValue: {}, newValue: {foo: "bar"} [10:16:10] sounds good [10:16:10] +1 [10:16:16] confirm [10:16:22] okay, updated [10:16:23] sounds fine [10:16:26] ok, on to template? [10:16:32] nah [10:16:39] more on editing? [10:16:53] I have more feedback on the api. Possibly more than IRC [10:16:53] Brad had a question [10:17:05] give us the brief? :) [10:17:32] The "move" operation on arrays is worthwhile to retain state on a row when it's drag/dropped to move. [10:17:40] brado23: we removed move as that can be achieved with seperate insert and remove calls; yes, it'll trigger two events, but there's a lot of cases where you want to have some kind of batching on the listener, its not a problem that observable should tackle [10:18:01] right, it should exist at a higher level [10:18:10] move dealt with just one special case [10:18:47] i think brado23 is worried about preserving state on the "moved" item tho [10:18:55] Yes, that's right. [10:19:04] if its removed and inserted [10:19:08] does it retain say "selected" [10:19:33] Yes, if clients do .data() on the TR...then it is removed/inserted? [10:19:40] If there is a higher level for batching, will the Grid have that layer to enable it to preserve state on move? [10:19:43] What of the .data() the client stashed? [10:19:49] considering the two selectable implementations, that's not a problem; either selected state is on the object itself, or its separate and not affected here [10:20:04] What about client state though (not selection)? [10:20:17] our concern was the required implementation for usrs [10:20:20] *users [10:20:26] what client state? [10:20:29] having to listen to insert, delete and move [10:21:05] I'm an app....I create a Grid...I do $.data() on its TRs to pin some JS object to them... [10:21:21] ...Like as if I was building selection on the outside of the Grid. [10:21:31] ...in my app code. [10:21:45] (I'll try to mine our prototypes for a better scenario...sorry) [10:21:57] thinking about it now, there may not be much conceptual overhead for users that don't care about move [10:22:15] exactly [10:22:21] they could themselves do delete and insert? [10:22:28] Many listeners on the corresponding event will just ignore it. [10:22:32] if they can just do something like .bind( "move", function( event, data ) { this.insert( data.newIndex, this.remove( data.oldIndex ) ); }); [10:22:38] yeah [10:23:09] From a perf standpoint, other UI controls that are listening on "move" events can save reconstructing DOM. [10:23:50] I'd like to see a more convincing usecase/example [10:23:53] let's verify that we can provide a dead simple way for people to handle move without any additional logic [10:24:21] I'd rather start without it, add it later if it turns out we need it, I don't see that right now [10:24:29] can't remove it later [10:24:37] if you move an array of non-index-contiguous objects, do they stay in their same order but all sequentially at the new index? [10:25:18] that's where it starts getting really complex from my view, that's where (if I remember right) we decided it was a rabbit hole [10:26:01] agreed...perhaps it's worth considering bracketing change events instead...rather than developing macro-like APIs/events [10:26:01] anyone have a hard stop in 5min? [10:26:22] bracketing? [10:26:31] like a transaction? [10:26:39] Yes, similiar...like this... [10:26:46] what about a piece of additional data in the remove/insert event that states the object is "moving" [10:26:57] i.e. you are removing just to insert [10:27:06] gnarf: the problem is tying those together [10:27:09] trigger("beginChanges")...trigger("remove")...trigger("insert")...trigger("endchanges") [10:27:24] btw. brado23, is that first item under Open issues still valid? [10:27:27] Then listeners can determine that remove/insert is actually a move [10:27:29] that still a pia [10:27:48] that seems a bigger pain than the move event w/ non-index-contig [10:27:48] pia? [10:27:57] pain in ass i assume (missing the t) [10:28:01] :) [10:28:26] the other option is limiting move to single element or groups of contiguous elements, it does simplify the issue I brough up [10:28:29] (though there may be others) [10:28:34] if you bracket the remove/insert you might as well raise move [10:28:40] .trigger("remove", { index: 10, moving: true }) [10:28:59] lets table this, anyone interested in a move method and event, please put together a usecase and example of why you need it [10:29:01] yes, but bracketing reaches more scenarios that listeneres will want to consider atomic [10:29:23] like Richard's non-contiguous move, others... [10:29:23] Yes, - multiple moves, etc [10:29:39] providing an undo queue.... [10:29:43] i can see the need for a begin change/end change if you're moving a lot of stuff [10:29:43] any sort of bracketing can happen simply at a higher level [10:29:45] (good case for transactionality) [10:30:02] But the Grid needs to have that higher level to preserve state [10:30:11] IN the general case, there will be UI controls that want to listen on a batch of events, develop a damage list and then rerender on "endChanges" [10:30:25] requires both parties to use that higher level, but I don't think it belongs here [10:30:30] gnarf, you don't need transctions for undo, just need to ensure that each modification and be reversed and redone and is in order [10:30:46] we're trying to represent the discrete changes that occur on the object and array [10:30:57] this isnt' transactions...that's a whole bigger nut. [10:31:04] ok, moving on [10:31:04] it's merely bracketing [10:31:19] Template? [10:31:35] rado23, is that first item under Open issues still valid? [10:31:40] near top on http://wiki.jqueryui.com/w/page/40632995/Grid-Editing-Events [10:32:02] If we dont' have a use case, then I'd say no. [10:32:18] k, removing that [10:32:21] This came from an IRC brainstorm. [10:32:26] ...not my issue :) [10:33:10] I'm probably going to remove that bubble stuff, too, already dropped from main editing page, gonna try to approach the problem from another direction [10:33:44] so yeah, if you have more feedback on the API and events, post comments on the wiki and we can get together in another meeting to discuss them [10:33:45] Generally, I agree. jzaefferer...I might talk with you offline about this. [10:33:53] ...as I have some thoughts. [10:34:09] alright, lemme know [10:34:16] rworth: now! [10:34:18] ok, so, Scott and Jörn and I did a bunch of work on template-comparison [10:34:46] we moved the table to a google docs spreadsheet the world can edit [10:35:04] pivoted the table to have the features as rows, implementations as columns [10:35:09] http://wiki.jqueryui.com/w/page/41375604/Template-Comparison [10:35:12] added min+gzip files sizes [10:35:24] then we categorized features into 2 groups [10:35:52] first is features essential to a core javascript template engine that will not have any dependency on jQuery or any other environment thing, like a dom [10:36:02] just string+object in, string out [10:36:31] with some basic built-in tags like {{if}} and {{each}} (maybe a couple others) but beyond that a simple way to define custom tags [10:36:38] handlebars calls these helpers [10:36:49] oh yeah, we also added handlebars and mustache to the comparison [10:37:05] the second block of features are ones we don't see as central to this core engine [10:37:26] but we still want to consider as features for a jQuery/jQuery UI template plugin that we'll build on top of this central core [10:37:29] what's "this core engine"? [10:37:34] that grid and the rest of UI will use [10:37:36] thx [10:37:59] we have decided this core engine will not have logic, that is, no JS Expressions [10:38:02] yeah, so the idea is that there are two levels [10:38:21] the template engine, which is environment independent and just works with strings [10:38:36] and a jQuery plugin which leverages the template engine and adds on additional functionality [10:38:48] such as generating a DOM, possibly data binding, etc. [10:39:19] the jQuery plugin should also be capable of using other template engines [10:39:33] seems jsViews looks to pull ahead by those standards [10:39:35] but we'll only have one officially supported template engine [10:39:59] How will users of Grid be aware of the template engine? [10:40:12] and another one used (even if not supported) need not match our syntax and can go well beyond our limited capabilites [10:40:25] as long as it takes in a string and an object and outputs a string [10:41:15] brado23: we haven't figured out the exact API between grid -> jQuery template -> template engine yet [10:41:19] brado23: if they write a row template, they'll write it against that engine [10:41:32] k thx [10:41:32] if they plugin in their own, they'll write a different kind of row template [10:41:44] Why no JS expressions? What's the concern? [10:42:11] logic, complexity, separation of concerns, best practices [10:42:19] support, maintainability [10:42:43] by logic I mean logic vs logic-less [10:42:55] But the complexity will get pushed into the helpers/custom tags, data wrappers etc right? [10:43:07] In the prototyping my team has done, many of our scenarios have used JS expressions in templates. This will be missed, methinks. [10:43:27] The custom tags will need to be packaged along with the templates, so not really separation [10:43:31] brado23: are you able to share those examples? [10:43:38] there's a tradeoff to the complexity and power and simplicity of any tool [10:44:10] borismoore: that's true only of custom tags that aren't provided by us [10:44:23] we'll have plenty of custom tags beyond the 2-5 in the central core [10:44:31] which we'll ship and support and document and maintain [10:44:34] But I need to do {{if a===b}} so I need to do a custom tag [10:45:02] That I ship to my page developers/designers along with the template that uses it [10:45:07] we're not going to have the same debate we spent about 3hrs on yesterday [10:45:23] it's a different model [10:45:39] but it's not one that's infeasible or broken or anything of the sort [10:45:39]