#jquerymobile-dev_20110601.txt

[06:13:48] <StevenBlack> See ? m1489 ... This month-old pull request fixing a "critical" bug appears good-to-go.
[06:13:50] <bot-t> [#1489] Radio buttons in nested listviews don't work (issue #1486) (open) - https://github.com/jquery/jquery-mobile/issues/1489
[06:14:16] <StevenBlack> ^^^^ related issue is ?m1486
[06:14:32] <StevenBlack> ? m1486
[06:14:33] <bot-t> [#1486] Form elements in nested listviews do not work (open, 5 - Critical, Ghislain) - https://github.com/jquery/jquery-mobile/issues/1486
[09:42:18] <kinblas_> gseguin: _nickel: did you get my email from yesterday regarding nested lists?
[09:42:29] <kinblas_> just curious because I saw no replies
[09:42:34] <gseguin> yup
[09:42:39] <_nickel> gseguin: yes, and I had some thoughts
[09:42:43] <_nickel> kinblas: ^
[09:42:46] <_nickel> let me respond
[09:42:50] <kinblas> okie dokie
[09:43:16] <gseguin> I didn't respond because I don't think I have anything to add
[09:43:42] <kinblas> StevenBlack: so what's your expectation with that cache pull request? Land as is and you'll fix up the nested lists issue? Or are we waiting for another rev?
[09:44:24] <kinblas> gseguin: the one difference in that email was that the count was at the list-level, versus inside your sub-list each() call
[09:44:27] <kinblas> :-)
[09:44:45] <gseguin> oh I missed that
[09:44:47] <_nickel> kinblas: actually I can respond here
[09:44:51] <gseguin> sorry
[09:45:00] <kinblas> I'd rather an email so scott isin the loop?
[09:45:04] <_nickel> kinblas: so, just to verify some of my assumptions
[09:45:09] <kinblas> go ahead
[09:45:09] <_nickel> ah
[09:45:11] <_nickel> good point
[09:45:17] <_nickel> assumptions first though
[09:45:34] <_nickel> do we always treat sub lists as pages?
[09:46:37] <kinblas> yes
[09:47:06] <StevenBlack> kinblas: $.mobile.removePage(), in two of the commits (bb4db50 and a9a12ec), is solid and well supported by tests (0eeec25).  Those three can land.
[09:47:22] <kinblas> so I can land that whole pull
[09:47:24] <kinblas> ??
[09:47:46] <StevenBlack> kinblas: the final commit, 29acda3, is problematic because of the list issue and probably should be skipped for now.
[09:48:11] <StevenBlack> The final commit, 29acda3, is for issue 1554.  Skip that one.
[09:48:19] <kinblas> ok so being I'm not git whiz here
[09:48:29] <kinblas> how do I selectively pull checkins
[09:48:44] * StevenBlack is thinking...
[09:48:45] <_nickel> kinblas: cherry-pick
[09:49:02] <_nickel> git cherry-pick <commit hash>
[09:49:11] * kinblas consults progit
[09:51:48] <StevenBlack> kinblas: I've been using Git Tower since its early beta and I really love it.
[09:52:02] <StevenBlack> (On os-x ^^^)
[09:52:15] <_nickel> kinblas: you may have already considered this, but could we just move the sublists out to their own embeded pages?
[09:52:24] <_nickel> and then us nav as normal?
[09:52:35] <_nickel> obviously we'd have to move the id up a level to the page
[09:53:23] <_nickel> having the concept of a subpage seems like a rabbit hole
[09:53:56] <StevenBlack> Related to that, adding to what _nickel says, we need page-level pointers between sublist and parent pages.
[09:54:50] <kinblas> _nickel: they are embedded pages
[09:54:57] <kinblas> it's just the way the hash is setup that is different
[09:55:10] <kinblas> you can actually navigate to the sub-list if you want to
[09:55:39] <_nickel> kinblas: it looks like the idea is to require the user to specify a unique id then?
[09:56:08] <kinblas> the idea is that we want to identify a specific sub-list for deep linking
[09:56:26] <kinblas> the only way to guarantee that you will get a specific sub-list is if folks put ids
[09:56:38] <_nickel> kinblas: alright
[09:56:43] <kinblas> if they don't, then the best we can do is use tree-node counts
[09:56:44] <kinblas> basically
[09:56:49] <_nickel> I guess my only concern is the seperate hash param
[09:56:50] <kinblas> which is very fragile
[09:56:57] <kinblas> it's always been that way
[09:56:58] <StevenBlack> What if all sublist pages were wrapped in a convenience div container... a physical grouping.
[09:57:09] <kinblas> gseguin: is just adding a way to differenciate between lists on the same page
[09:57:41] <kinblas> StevenBlack: then we would have to special case code that because the page code expects everything in one container
[09:57:50] <_nickel> kinblas: do we currently use "subpage=x"
[09:57:53] <kinblas> The issue here is just how we identify for dep linking
[09:58:01] <kinblas> we currently use ui-page
[09:58:07] <kinblas> not sure where gseguin got subpage
[09:58:31] <_nickel> can we just use the regular old hash like we would normally for pages?
[09:58:37] <_nickel> if we can then I say go for it
[09:58:58] <kinblas> _nickel: the one problem ... and I think this is why scott went the current root
[09:59:11] <kinblas> is that those pages do not exist in the static sense
[09:59:20] <_nickel> right, its post enhance
[09:59:21] <kinblas> they exist only at run-time
[09:59:51] <kinblas> so how do you refer to  sub-list in an external file?
[10:00:00] <kinblas> given the fact that our hash uses the site relative path to the file
[10:00:15] <_nickel> hmmm
[10:00:16] <kinblas> we need some extra data to figure out what inside that page we want to display
[10:00:18] <gseguin> $.mobile.subPageUrlKey was there before I started working on that
[10:00:34] <kinblas> gseguin: right I know, only the name was changed
[10:00:40] <kinblas> the key i meant
[10:02:11] <_nickel> kinblas: gseguin: well now that you've wasted 5 minutes of your lives spelling out reality to me, it seems fine to me
[10:02:25] <kinblas> lol
[10:02:27] <_nickel> s/reality to me/reality for me/
[10:02:29] <gseguin> lol
[10:02:48] <kinblas> _nickel: its not a waste of time, I wanted your and scott's feedback since you're familar with that stuff
[10:02:59] <_nickel> clearly not! :D
[10:03:02] <_nickel> but thanks
[10:03:03] <kinblas> lol
[10:03:25] <gseguin> same here 'cause I'm a newbie
[10:04:42] <StevenBlack> ATM nested lists generate ui-page containers that are direct children of $("body").
[10:05:36] <StevenBlack> I'm thinking, are there benefits to nesting the nested ui-page containers inside another container so these can be grouped?
[10:06:40] <StevenBlack> This container(s) would be direct children of $(body) but provide a way to collect all subpages at once wihout fanfare.
[10:09:37] <StevenBlack> See, ATM /docs/lists/lists-nested.html&ui-page=Colors does not work.
[10:10:01] <StevenBlack> ATM it needs to be http://jqm.site/#/docs/lists/lists-nested.html&ui-page=Colors-4
[10:11:05] <StevenBlack> Whoops.  Local URL.  The point is, the "-4" suffix is now required even though "Colors" is authoritative.
[10:15:32] <StevenBlack> Sematically the current code assumes nested list pages are unique.  What if the lists are drilldowns that lead, in roundabout ways, to the same pages?
[10:16:52] <kinblas> StevenBlack: that's one of the things we're changing ... we can't use labels
[10:16:57] <kinblas> as keys
[10:17:45] <kinblas> we will use ids, if the exist, if not, we use indexes ... supporting the ids gives folks on the backend a chance to make sure things are reliably deep-linkable
[10:18:10] <StevenBlack> kinblas: k
[10:18:34] <kinblas> _nickel: so have you "cherry-picked" checkins from a remote repository?
[10:18:43] <kinblas> or do you merge it and back it out?
[10:20:54] <StevenBlack> kinblas, alternately I can re-branch here and re-submit a clean pull.
[10:21:15] <kinblas> StevenBlack: normally we would ask folks to do that, but you're special
[10:21:20] <kinblas> :-P
[10:21:37] <StevenBlack> I have everything I need here...
[10:21:43] <kinblas> _nickel: so is the idea to do a fetch from steven's repository into my branch then merge the specific checkins by hash?
[10:21:45] <StevenBlack> Can do it easily.
[10:22:03] <kinblas> StevenBlack: that would be easiest if you have time, then I can press the little green button
[10:22:16] <StevenBlack> I'll do that.
[10:22:16] <kinblas> I'd still like to know the procedure though
[10:22:27] <kinblas> I'm thinking it's branch, fetch, merge by hash?
[10:24:26] <StevenBlack> Yes, except that git cherry will give you a txt file to edit wherein there will be 4-lines, one per commit, and you mangle the one you don't want.
[10:25:28] <StevenBlack> It'll be cleaner if I do it because the commits have been on-the-vine for a while which means subsequent merges for each commit, etc.  Yech!
[10:26:03] <StevenBlack> I'll pull a fresh HEAD, apply my edits, and push.
[10:26:24] <StevenBlack> kinblas: do you have any thoughts on the widening gap between our jquery.ui.widget.js and its current version, 1.8.13?
[10:27:00] <StevenBlack> It's mainly about remediating tests since the widget API changed.
[10:27:25] <kinblas> StevenBlack: Actually, I haven't been tracking the changes. Both Todd and Scott are part of the UI team so they are in the loop regarding that
[10:27:37] <kinblas> I did see your previous messages about tests failing when you upgraded
[10:27:44] <kinblas> ideally, we would be using a single codebase
[10:27:50] <StevenBlack> +1
[10:28:04] <kinblas> I'm all about extensibility, modularity, and re-use
[10:28:12] <kinblas> I have 3 middle names
[10:37:49] <_nickel> kinblas: you could do that but really we should ask StevenBlack to clean up the pull request
[10:37:53] <_nickel> since he wrote it
[10:38:01] <_nickel> you're not equiped to resolve conflicts etc
[10:38:11] <_nickel> equiped meaning, you didn't write the code
[10:38:24] <_nickel> and since StevenBlack is here right now its even easier
[10:38:32] <_nickel> sometimes you can't do that with other contribs
[10:38:58] <StevenBlack> _nickel: that's what we agreed to do. :)