fluid-work IRC Logs-2008-08-06

[07:40:30 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[07:46:27 EDT(-0400)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[08:12:41 EDT(-0400)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[08:45:48 EDT(-0400)] * jhung (n=Administ@H25.C206.cci.switchworks.net) has joined #fluid-work
[08:53:27 EDT(-0400)] * anastasiac (n=stasia@142.150.154.160) has joined #fluid-work
[09:28:02 EDT(-0400)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[09:41:13 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279543344.dsl.bell.ca) has joined #fluid-work
[09:42:44 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[10:05:04 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279543344.dsl.bell.ca) has joined #fluid-work
[10:12:14 EDT(-0400)] * apetro-_ (n=apetro@CPE-65-30-162-97.wi.res.rr.com) has joined #fluid-work
[10:32:31 EDT(-0400)] * jhung1 (n=Administ@H25.C206.cci.switchworks.net) has joined #fluid-work
[10:39:15 EDT(-0400)] * jhung (n=Administ@H25.C206.cci.switchworks.net) has joined #fluid-work
[10:42:14 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:50:22 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[11:09:33 EDT(-0400)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[11:54:55 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-74.LIPS.Berkeley.EDU) has joined #fluid-work
[12:02:59 EDT(-0400)] * jacobfarber (n=Jacob@142.150.154.106) has joined #fluid-work
[12:03:21 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has left #fluid-work
[12:03:52 EDT(-0400)] <jacobfarber> ecochran: can we discuss?
[12:04:11 EDT(-0400)] * michelled_ (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[12:04:11 EDT(-0400)] <ecochran> yes
[12:04:20 EDT(-0400)] <ecochran> Skype?
[12:04:26 EDT(-0400)] <jacobfarber> sure
[12:08:59 EDT(-0400)] * jhung1 (n=Administ@H25.C206.cci.switchworks.net) has joined #fluid-work
[12:19:47 EDT(-0400)] <jhung_real> hey Justin_o, if you have time I would like to test this voice chat server with you.
[12:23:23 EDT(-0400)] <Justin_o> jhung_real: one second... just have to find a headset
[12:23:41 EDT(-0400)] <jhung_real> ok
[12:26:05 EDT(-0400)] <Justin_o> okay i think i'm ready.. hopefully i got the headset setup properly
[12:26:15 EDT(-0400)] <jhung_real> ok
[12:26:34 EDT(-0400)] <jhung_real> Go here and download the Mac client: http://www.ventrilo.com/download.php
[12:28:08 EDT(-0400)] <Justin_o> okay.. i have it installed
[12:29:01 EDT(-0400)] <jhung_real> ok.
[12:29:21 EDT(-0400)] <jhung_real> Launche it and create a user name first.
[12:30:28 EDT(-0400)] <Justin_o> user name created (not sure how to do the phonetic part though, but i guess it doesn't matter)
[12:30:42 EDT(-0400)] <jhung> Yeah. Only necessary if using text-to-speech
[12:30:53 EDT(-0400)] <jhung> Then go to Server
[12:30:55 EDT(-0400)] <Justin_o> oh okay
[12:31:05 EDT(-0400)] <jhung> Let me give you an ip...
[12:31:18 EDT(-0400)] <Justin_o> alright
[12:31:21 EDT(-0400)] <jhung> 76.74.206.25
[12:31:38 EDT(-0400)] <jhung> Password is Fluidic
[12:31:40 EDT(-0400)] <jhung> sorry
[12:31:46 EDT(-0400)] <jhung> fluidic (all lower case)
[12:32:40 EDT(-0400)] <Justin_o> do i need to change the port or add a default channel
[12:33:00 EDT(-0400)] <jhung> leave the port as it is. leave the default channel blank for now.
[12:33:07 EDT(-0400)] <Justin_o> okay.. done
[12:33:10 EDT(-0400)] <jhung> ok
[12:33:30 EDT(-0400)] <jhung> Now hit connect
[12:33:42 EDT(-0400)] <Justin_o> it is trying to contact the server
[12:33:53 EDT(-0400)] <Justin_o> there we go
[12:34:12 EDT(-0400)] <jhung> go to open room
[12:34:37 EDT(-0400)] <Justin_o> error message
[12:34:44 EDT(-0400)] <jhung> yeah?
[12:34:46 EDT(-0400)] <Justin_o> "Failed to get encoder for specified Codec"
[12:34:52 EDT(-0400)] <jhung> ok hold on...
[12:35:00 EDT(-0400)] <jhung> the FAQs have something about that
[12:35:33 EDT(-0400)] <jhung> hrm
[12:35:42 EDT(-0400)] <jhung> let me try something.
[12:35:51 EDT(-0400)] <Justin_o> The full message for the error says that mine supports only Speex codec and the channel is using 'GSM 6.10' codec
[12:36:01 EDT(-0400)] <jhung> ah
[12:36:08 EDT(-0400)] <jhung> Ok. Let me try to switch the codec.
[12:36:13 EDT(-0400)] <Justin_o> okay
[12:36:18 EDT(-0400)] <Justin_o> should i log off
[12:36:24 EDT(-0400)] <jhung> yeah
[12:39:30 EDT(-0400)] <jhung> try now
[12:40:50 EDT(-0400)] <jhung> hit "chat"
[12:41:38 EDT(-0400)] <Justin_o> can you see my messages in the chat
[12:41:46 EDT(-0400)] <jhung> no
[12:41:48 EDT(-0400)] <jhung> yes
[12:41:50 EDT(-0400)] <michelled_> colinclark: thanks for looking at my patch for Fluid-1070. I've merged the branch back into trunk
[12:42:02 EDT(-0400)] <michelled_> what is the process now? Do I delete the branch?
[12:42:05 EDT(-0400)] <jhung> Yeah I can see you messages. Seems like once you send, it doesn't echo.
[12:42:48 EDT(-0400)] <jhung> I can hear you.
[12:47:23 EDT(-0400)] <colinclark> michelled_: I'd go ahead and delete the branch. No reason to keep it around.
[12:47:46 EDT(-0400)] <michelled_> thanks
[13:34:33 EDT(-0400)] * davidb (n=davidb@142.150.154.101) has joined #fluid-work
[13:35:57 EDT(-0400)] * davidb is thinking about the topic of using aria properties as css selectors
[13:40:57 EDT(-0400)] <Bosmon> New merging stuff is now documented at http://wiki.fluidproject.org/display/fluid/Options+Merging+for+Fluid+Components
[13:41:51 EDT(-0400)] <Bosmon> I am unconvinced we should be "inferring" the state of components by looking in the DOM
[13:42:09 EDT(-0400)] <Bosmon> In a "model-driven" architecture, we would know what state a component was in by ourselves (like a cat)
[13:43:52 EDT(-0400)] <davidb> yeah cat's don't rely on the DOM for much
[13:45:41 EDT(-0400)] <Bosmon>
[13:58:50 EDT(-0400)] <theclown> davidb, re: aria properties and CSS. I was playing with this a while back. It appears to work in FF:
[13:58:52 EDT(-0400)] <theclown> http://clown.atrc.utoronto.ca/Fluid/Css2AttSelectors.html
[13:59:17 EDT(-0400)] <davidb> theclown: one would hope!
[13:59:32 EDT(-0400)] <davidb> theclown: i snuck it into the user agent BPG
[13:59:48 EDT(-0400)] <colinclark> theclown: Which versions of Firefox have you tested?
[13:59:58 EDT(-0400)] <colinclark> Any luck in IE?
[14:00:05 EDT(-0400)] <davidb> theclown: see 1.17 (11.3.18) of http://developer.mozilla.org/en/docs/index.php?title=ARIA_User_Agent_Implementors_Guide
[14:00:09 EDT(-0400)] <theclown> davidb: I've seen/heard Al muse about this at various times.
[14:00:18 EDT(-0400)] <davidb> cool
[14:00:33 EDT(-0400)] <theclown> colinclark: I've tested FF2 and FF3. I think I tried Safari, but I can't remember. firing up safari
[14:01:40 EDT(-0400)] <davidb> i've not tried any
[14:01:47 EDT(-0400)] <theclown> davidb, colinclark, note that keying off of tabindex didn't work. dunno why... also dunno if that's important... might be dang useful for debugging.
[14:02:19 EDT(-0400)] <davidb> theclown: weird
[14:02:39 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[14:02:52 EDT(-0400)] * davidb wishes jacob was here
[14:03:23 EDT(-0400)] <davidb> don't bother asking Bosmon's cat for help.
[14:03:43 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[14:03:47 EDT(-0400)] <theclown> colinclark, davidb, works in Safari (v3.1.2 on OS X Leopard)
[14:04:03 EDT(-0400)] <davidb> theclown: can you try ie7?
[14:04:17 EDT(-0400)] <theclown> davidb, how much are you paying?
[14:04:33 EDT(-0400)] <theclown> firing up vmware
[14:04:36 EDT(-0400)] * jacobfarber (n=Jacob@142.150.154.106) has joined #fluid-work
[14:04:50 EDT(-0400)] <colinclark> ie6 is the really interesting one
[14:05:25 EDT(-0400)] <davidb> theclown: i'll take it off my bill.
[14:05:25 EDT(-0400)] <davidb> "interesting" yes
[14:05:41 EDT(-0400)] <davidb> although i heard ie7 didn't add anything javascript-wise
[14:05:41 EDT(-0400)] <davidb> (except a bug or two)
[14:06:17 EDT(-0400)] <davidb> ie8 beta1 fails
[14:06:40 EDT(-0400)] <theclown> ie7 fails
[14:06:53 EDT(-0400)] <davidb> if ie6 works i'll buy a round.
[14:06:54 EDT(-0400)] <theclown> ie7 fails even for non-aria CSS2 selectors
[14:06:57 EDT(-0400)] <colinclark> That's a drag.
[14:07:02 EDT(-0400)] <davidb> theclown: same with 8
[14:07:05 EDT(-0400)] <colinclark> It makes this approach fairly useless in practice.
[14:07:11 EDT(-0400)] <davidb> colinclark: yes. major drag
[14:08:27 EDT(-0400)] * jacobfarber (n=Jacob@142.150.154.106) has joined #fluid-work
[14:09:27 EDT(-0400)] <davidb> theclown: will you keep your test page static? i'd like to file a bug report and provide the url
[14:09:27 EDT(-0400)] <davidb> hi jacobfarber
[14:09:34 EDT(-0400)] <ecochran> davidb: surprised that IE8 doesn't work... I know that IE6 doesn't work
[14:09:44 EDT(-0400)] <davidb> ecochran: me too
[14:09:49 EDT(-0400)] <ecochran> doesn't handle the [foo] at all
[14:09:51 EDT(-0400)] <jacobfarber> davidb:hey there
[14:10:11 EDT(-0400)] <ecochran> I wonder if the IE8 team has this on their radar
[14:10:16 EDT(-0400)] <jacobfarber> sorry i've been bounced out of the room occasionally
[14:10:30 EDT(-0400)] <theclown> I'll leave it where it is. I may change the contents in the sense of adding other test cases and/or clarifying the current ones. but, in essence it will stay the same.
[14:10:31 EDT(-0400)] <davidb> jacobfarber: was calling for you earlier but we sort of figured things out... trying css attribute selectors in IE
[14:10:35 EDT(-0400)] <davidb> ecochran: if not, they will shortly
[14:10:50 EDT(-0400)] <jacobfarber> sounds like a good time
[14:10:51 EDT(-0400)] <davidb> i hope
[14:10:53 EDT(-0400)] <jacobfarber> any luck?
[14:10:58 EDT(-0400)] <ecochran> davidb: my thoughts on using ARIA states is more to mimic the states in CSS so we're using the same language for the same stuff
[14:11:04 EDT(-0400)] <davidb> jacobfarber: not a whole lot
[14:11:12 EDT(-0400)] <ecochran> because of IE we'd need the redundancy
[14:11:12 EDT(-0400)] <davidb> ecochran: example?
[14:11:14 EDT(-0400)] <jacobfarber> i just look at this and scowl
[14:11:15 EDT(-0400)] <jacobfarber> http://www.quirksmode.org/css/contents.html
[14:11:25 EDT(-0400)] <davidb> jacobfarber: yeah good pt
[14:11:38 EDT(-0400)] * davidb tries to burn quirksmode site into memory
[14:12:03 EDT(-0400)] <ecochran> well... <foo class="disabled" aria="disabled"> (psuedo code, cause I don't remember the aria syntax)
[14:12:08 EDT(-0400)] <jacobfarber> we could use css expressions for IE specific behaviour, i guess
[14:12:18 EDT(-0400)] <davidb> ecochran: i see.
[14:12:28 EDT(-0400)] <davidb> ecochran: yeah. seems a shame though.
[14:12:55 EDT(-0400)] <ecochran> well unless we personally go smack every IE6 user on the wrist and get them to change
[14:13:18 EDT(-0400)] <ecochran> although now that we know that IE7 doesn't like ARIA attributes either...
[14:13:21 EDT(-0400)] <ecochran> grumph
[14:13:25 EDT(-0400)] <colinclark> ecochran: Not an option, unfortunately.
[14:13:37 EDT(-0400)] <ecochran> really!?!?
[14:13:48 EDT(-0400)] <ecochran> I was going to start this afternoon
[14:13:56 EDT(-0400)] <colinclark> Smacking users tends to make one rather unpopular.
[14:13:57 EDT(-0400)] <davidb> jacobfarber: i'm not understanding the quirksmode css3 chart... seems to me that ie7/8 should support advanced attr selectors?
[14:14:02 EDT(-0400)] <ecochran> I'm sure that there are some IE6 users somewhere on campus
[14:14:09 EDT(-0400)] <colinclark> go get 'em, tiger
[14:14:30 EDT(-0400)] <davidb> ohhhh http://www.quirksmode.org/css/selector_attributeAdvanced.html
[14:14:41 EDT(-0400)] <jacobfarber> davidb: the red NO block covers IE6 as well
[14:14:48 EDT(-0400)] <jacobfarber> stops short of IE7
[14:14:59 EDT(-0400)] <ecochran> davidb: I think that it supports the selectors that it knows about
[14:16:05 EDT(-0400)] <ecochran> worth testing
[14:16:05 EDT(-0400)] <davidb> ecochran: that seems odd... how would one implement it non-generally?
[14:16:21 EDT(-0400)] <ecochran> good point
[14:16:21 EDT(-0400)] <davidb> (i mean the browser impl)
[14:16:22 EDT(-0400)] <davidb> this works in ie8 http://www.quirksmode.org/css/selector_attributeAdvanced.html
[14:16:28 EDT(-0400)] <davidb> theclown: ^
[14:16:31 EDT(-0400)] <theclown> just for completeness: my test page fails in ie6 too.
[14:19:47 EDT(-0400)] <theclown> davidb, it looks like on has to turn off quirks mode by adding a doctype declaration. that's my reading of the quirksmode page. i'll give it a try...
[14:19:48 EDT(-0400)] <davidb> theclown: wanna try p[aria-enabled*=true]?
[14:20:02 EDT(-0400)] <davidb> theclown: good pt!
[14:20:08 EDT(-0400)] <theclown> davidb, sure. what does the * mean?
[14:20:22 EDT(-0400)] <davidb> theclown: try your thang first... i was grasping at straws
[14:20:37 EDT(-0400)] <davidb> * means contains substring 'true' in my example
[14:21:51 EDT(-0400)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[14:21:51 EDT(-0400)] <davidb> "p[testAttr*=foo]: any element whose testAttr attribute has a value that contains "foo". "
[14:22:23 EDT(-0400)] <theclown> davidb, doctype in place. I'll try ie7. you wanna try ie8?
[14:23:48 EDT(-0400)] <theclown> davidb, colinclark, my test page works in ie7 if you include the proper doctype to force ie out of quirks mode
[14:23:49 EDT(-0400)] <davidb> k
[14:23:49 EDT(-0400)] <davidb> works
[14:23:49 EDT(-0400)] <davidb> theclown: nice catch!
[14:23:55 EDT(-0400)] <davidb> ecochran: ^
[14:23:59 EDT(-0400)] <davidb> jacobfarber: ^
[14:24:02 EDT(-0400)] <colinclark> Interesting.
[14:24:05 EDT(-0400)] <colinclark> But no dice in IE6?
[14:24:13 EDT(-0400)] <davidb> my confusion about quirksmode chart is cleared up. thanks theclown
[14:24:27 EDT(-0400)] <theclown> aw shucks. twern't nothin'
[14:24:45 EDT(-0400)] <ecochran> davidb: great!
[14:24:54 EDT(-0400)] <davidb> what do most toolkits state about quirksmode and ie i wonder
[14:24:58 EDT(-0400)] <davidb> in terms of support
[14:25:10 EDT(-0400)] <davidb> ecochran: go team
[14:25:26 EDT(-0400)] <jacobfarber> davidb: can you sum up your discovery?
[14:25:36 EDT(-0400)] <jacobfarber> i havent read the entire thread
[14:26:00 EDT(-0400)] <ecochran> davidb: there are Javascript workarounds for behavior, but no CSS work-arounds for styling that I know of
[14:26:03 EDT(-0400)] <theclown> colinclark, that's right: no dice in ie6
[14:26:19 EDT(-0400)] <jacobfarber> why cant we try combining this with CSS Expressions for IE6?
[14:26:27 EDT(-0400)] <jacobfarber> http://msdn.microsoft.com/en-us/library/ms530710(VS.85).aspx
[14:26:27 EDT(-0400)] <davidb> jacobfarber: i was understanding how http://www.quirksmode.org/css/selector_attributeAdvanced.html could be true and ie7 and ie8 were failing for clown's test page... but it was a quirksmode mode thing
[14:26:27 EDT(-0400)] <davidb> s/was/wasn't
[14:26:29 EDT(-0400)] <davidb> jacobfarber: do tell
[14:26:57 EDT(-0400)] <jacobfarber> MS enables a proprietary tech for running JS expressions in CSS
[14:27:02 EDT(-0400)] <jacobfarber> using :expression
[14:27:15 EDT(-0400)] <jacobfarber> you could run a series of dynamic code snippets
[14:27:30 EDT(-0400)] * davidb learns
[14:27:33 EDT(-0400)] <ecochran> the expression stuff in IE has performance problems
[14:27:45 EDT(-0400)] <jacobfarber> it could prob. be used to create a general purpose CSS 3 selector system in IE6, methinks
[14:27:47 EDT(-0400)] <ecochran> but it might work...
[14:27:59 EDT(-0400)] <davidb> does jquery handle this i wonder?
[14:27:59 EDT(-0400)] <jacobfarber> yeah, buts its a one off for the IE 6 people
[14:28:13 EDT(-0400)] * davidb wishes resig was here
[14:28:17 EDT(-0400)] <theclown> i can't remember but does ie6 support aria?
[14:28:24 EDT(-0400)] <ecochran> additionally we can add classes to elements using code based on the ARIA attributes
[14:28:24 EDT(-0400)] <davidb> hey my wishing worked last time
[14:28:31 EDT(-0400)] <davidb> theclown: nope
[14:29:56 EDT(-0400)] <davidb> nor does ie7
[14:29:56 EDT(-0400)] * davidb feels dizzy... let me check that
[14:30:17 EDT(-0400)] <theclown> davidb, i think you are right about ie7. it's coming back to me...
[14:30:25 EDT(-0400)] <davidb> phew
[14:30:46 EDT(-0400)] <theclown> the old nut: if ie7 does not support aria, why do dojo menus work with jaws?
[14:31:03 EDT(-0400)] <davidb> theclown: "Microsoft – supporting standardization effort, IE 5+ supports ARIA keyboard navigation (via the same tabindex extensions contained in HTML 5). IE 8 (starting with beta 1) will include ARIA support. "
[14:31:17 EDT(-0400)] <theclown> davidb, thanks
[14:31:19 EDT(-0400)] <davidb> theclown: sort of progressive enhancedment meets a11y
[14:31:25 EDT(-0400)] <davidb> -d
[14:31:47 EDT(-0400)] <theclown> another way to look at that is that ie8 is supporting html5...
[14:31:47 EDT(-0400)] <davidb> np
[14:32:12 EDT(-0400)] <davidb> no comment
[14:34:25 EDT(-0400)] <davidb> ecochran: what about accidental conflicts with existing css classes
[14:34:33 EDT(-0400)] <davidb> is that the worry colinclark has?
[14:35:17 EDT(-0400)] <davidb> unless you do something like class="aria-enabled" with the aria prefix
[14:35:20 EDT(-0400)] <jacobfarber> thats why they have to be carefully namespaced
[14:35:27 EDT(-0400)] <davidb> jacobfarber: yeah
[14:35:30 EDT(-0400)] <jacobfarber> that's prolly not enough
[14:35:34 EDT(-0400)] * jhung (n=Administ@H25.C206.cci.switchworks.net) has left #fluid-work
[14:35:56 EDT(-0400)] <davidb> jacobfarber: hmmm maybe not
[14:36:00 EDT(-0400)] <jacobfarber> we should do something more complex with our namespace, like the mozilla vendor recommendation
[14:36:08 EDT(-0400)] <jacobfarber> -vendor-name
[14:37:25 EDT(-0400)] <jacobfarber> just out of curiosity, why would we be using classes that look like other attribute values?
[14:37:33 EDT(-0400)] <davidb> ecochran: ^
[14:37:52 EDT(-0400)] <davidb> i have to let my eyes go off channel for a while
[14:38:23 EDT(-0400)] <ecochran> davidb: sorry, I'm not really paying attention either... talking to Colin about Uploader
[14:38:30 EDT(-0400)] <ecochran> I'll be gone for a while
[14:59:26 EDT(-0400)] <Bosmon> michelled: I am wondering to what extent the "options" structures for the layout handlers and the reorderer itself are really different?
[15:00:57 EDT(-0400)] <michelled> to be honest I need to go look at the wiki docs to be sure. http://wiki.fluidproject.org/display/fluid/Advanced+Reorderer+API
[15:01:54 EDT(-0400)] <michelled> All three layout handlers have an optional orderChangedCallback
[15:02:03 EDT(-0400)] <Bosmon> ....
[15:02:07 EDT(-0400)] * davidb (n=davidb@142.150.154.101) has left #fluid-work
[15:02:09 EDT(-0400)] <Bosmon> Why is this different to the top-level callback
[15:02:52 EDT(-0400)] <michelled> what do you mean by the top-level callback?
[15:02:59 EDT(-0400)] <Bosmon> The one that is actually given to the reorderer
[15:03:03 EDT(-0400)] <Bosmon> Of the same name...
[15:03:26 EDT(-0400)] <michelled> The reorderer is not given a callback.
[15:03:49 EDT(-0400)] <Bosmon> Urgh
[15:03:51 EDT(-0400)] <Bosmon> You are right...
[15:04:46 EDT(-0400)] <michelled> the 'reorderList' 'reorderGrid' and 'reorderLayout' take orderChangedCallback functions which they pass along to the appropriate layout handler
[15:05:29 EDT(-0400)] <Bosmon>
[15:05:37 EDT(-0400)] <Bosmon> So the responsibility for operating the callback is not centralised
[15:05:38 EDT(-0400)] <Bosmon> I see....
[15:06:25 EDT(-0400)] <michelled> no, the layout handlers take responsibility for movement and the associated callback.
[15:06:49 EDT(-0400)] <Bosmon> Ok
[15:06:56 EDT(-0400)] <Bosmon> This might be another thing we end up refactoring a bit...
[15:07:35 EDT(-0400)] <Bosmon> Especially if we end up with the callback reporting something any more useful...
[15:08:15 EDT(-0400)] <Bosmon> Anyway, my current plan is for LayoutHandlers and Reorderer to share the selfsame options structure
[15:08:28 EDT(-0400)] <Bosmon> Since dealing with them having different ones is confusing even me when I try to understand what is happening
[15:09:07 EDT(-0400)] <Bosmon> The awkwardness with moving towards the DOM binder is that this will in general not be constructed for the main Reorderer at the time we want to chuck in the Layout thing
[15:09:07 EDT(-0400)] <michelled> so there are a couple options that are particular to a single layouthandler
[15:09:11 EDT(-0400)] <Bosmon> Yes
[15:09:18 EDT(-0400)] <Bosmon> But the whole point about options is that they express optional conditions
[15:09:43 EDT(-0400)] <Bosmon> Now, the last thing Colin said to me before he disappeared with Eli was that he didn't support the idea of moving the construction of the LayoutHandler itself into the overall options structure
[15:09:47 EDT(-0400)] <Bosmon> But I think this is generally not right...
[15:09:57 EDT(-0400)] <Bosmon> Since at the moment with the DOM binder we now face a "construction race"
[15:10:08 EDT(-0400)] <Bosmon> The DOM binder is not constructed into the overall "that" of the reorderer is constructed
[15:10:19 EDT(-0400)] <Bosmon> Which means that it is not available to be passed in as the argument for the layoutHandler
[15:10:30 EDT(-0400)] <Bosmon> The "immediate" approach to this is to create a "LayoutPromiser"
[15:10:48 EDT(-0400)] <Bosmon> But, looking at it, the only argument it would "curry" would be the "options" argument
[15:10:57 EDT(-0400)] <Bosmon> Which, if it was shared between the two objects would not even need "currying"
[15:11:02 EDT(-0400)] <Bosmon> SO....
[15:11:44 EDT(-0400)] <michelled> I think the only thing the reorderer and the layout handlers share right now is the findItems.
[15:11:55 EDT(-0400)] <Bosmon> Yes.... which is now destroyed
[15:12:10 EDT(-0400)] <michelled> ah, and moved to the options?
[15:12:18 EDT(-0400)] <Bosmon> No, it is now the "dom binder" for the main reorderer
[15:12:26 EDT(-0400)] <Bosmon> options only contain "pure data" and not stuff which actually does things...
[15:12:44 EDT(-0400)] <Bosmon> Ah, I think I misremembered what Colin said
[15:12:52 EDT(-0400)] <michelled> so the dom binder is good with optional things?
[15:13:05 EDT(-0400)] <Bosmon> Scrolling back, what he actually said was that he didn't necessarily support my idea of making the "ListLayoutHandler" into a default
[15:13:22 EDT(-0400)] <Bosmon> He didn't specifically say anything about that plan of moving its specification into the options structure
[15:13:53 EDT(-0400)] <Bosmon> Now, here's a wacky wrinkle.... is there an explicit name for the "top-level" Javascript global object?
[15:15:08 EDT(-0400)] <michelled> are you talking about 'fluid'?
[15:15:09 EDT(-0400)] <Bosmon> You see, my idea is to move the Layout Manager "promise" into the startup of the Reorderer itself
[15:15:16 EDT(-0400)] <Bosmon> No, the global global one
[15:15:26 EDT(-0400)] <Bosmon> I mean, in browser environments you can refer to it by "window"
[15:15:35 EDT(-0400)] <Bosmon> But I was wondering if there is a language-standard name for it...
[15:15:47 EDT(-0400)] <michelled> this
[15:15:55 EDT(-0400)] <Bosmon> That is only sometimes true
[15:16:00 EDT(-0400)] <michelled> yes
[15:16:07 EDT(-0400)] <Bosmon> But it is a cunning idea
[15:16:16 EDT(-0400)] <michelled> what do you want with the global object?
[15:16:26 EDT(-0400)] <Bosmon> You could create a free function which you know is not a member of anything, and then invoke it
[15:16:28 EDT(-0400)] <Bosmon> hahaha
[15:16:29 EDT(-0400)] <Bosmon> hahahahaha
[15:16:44 EDT(-0400)] <michelled> evit
[15:16:46 EDT(-0400)] <michelled> evil
[15:16:55 EDT(-0400)] <Bosmon> My current idea is to try to let the specification of LayoutManager "promises" be simply "in name"
[15:17:05 EDT(-0400)] <Bosmon> That is, that we will simply add to our global options structure, this:
[15:17:38 EDT(-0400)] <Bosmon> layoutHandler: "fluid.listLayoutHandler"
[15:17:52 EDT(-0400)] <Bosmon> The only trick that remains is how to actually "fulfil" this promise without doing something sleazy like an "eval"
[15:18:22 EDT(-0400)] <Bosmon> Now, what you are telling me, is that inside this function environment, we should be able to access the function itself by means of the statement this[options.layoutHandler]
[15:18:33 EDT(-0400)] * Justin_o_ (n=Justin@142.150.154.101) has joined #fluid-work
[15:19:02 EDT(-0400)] <Bosmon> It would be nice if there was a "more standard" way of doing this though
[15:19:23 EDT(-0400)] <Bosmon> All three of "eval", "window", and "this" are for somewhat different reasons to be considered as "unsafe" parts of the language....
[15:19:33 EDT(-0400)] <michelled> yes
[15:19:35 EDT(-0400)] <Bosmon> Although I guess of the 3, my preference would be for "window"
[15:19:47 EDT(-0400)] <michelled>
[15:20:18 EDT(-0400)] <Bosmon> The other option is to simply insist that people "lamba-ise" the layoutHandler before they pass it in
[15:20:32 EDT(-0400)] <Bosmon> That is, every layoutHandler to come with a member of itself which constructs itself....
[15:20:51 EDT(-0400)] <Bosmon> Which to be honest looks a little wacky
[15:21:33 EDT(-0400)] <michelled> I'm a bit lost. why can't the layout handler be constructed prior to the reorderer?
[15:21:43 EDT(-0400)] <Bosmon> Because it needs to access its DOM binder
[15:22:11 EDT(-0400)] <michelled> and they share a DOM binder?
[15:22:29 EDT(-0400)] <Bosmon> Well, the DOM binder "is" the thing which used to be "findItems"
[15:22:36 EDT(-0400)] <Bosmon> It is no longer completely autonomous, unfortunately
[15:23:20 EDT(-0400)] <Bosmon> But I think I never quite understood how "findItems" really could be autonomous anyway
[15:23:31 EDT(-0400)] <Bosmon> There used to be code duplication where each person who wanted one "adapted" it etc.
[15:23:49 EDT(-0400)] <Bosmon> I mean, you can't really know what a "findItems" is going to do, until the "options" structure for the overal reorderer has been resolved
[15:23:56 EDT(-0400)] <Bosmon> Since that is the one which contains the selector information
[15:24:21 EDT(-0400)] <Bosmon> So I feel that we "always" had an implicit construction race, even if ultimately in practice we generally fended it off through code duplication....
[15:24:57 EDT(-0400)] <michelled> meaning findItems contains the selector info or the 'options' structure contains the selector info?
[15:25:03 EDT(-0400)] <Bosmon> Yes
[15:25:10 EDT(-0400)] <michelled> that was an or!
[15:25:12 EDT(-0400)] <michelled>
[15:25:23 EDT(-0400)] <Bosmon> Well, implicit in your question is what the "race" is
[15:25:50 EDT(-0400)] <michelled> so they both contain selector info? I think I'm not not understanding what the options object it
[15:26:02 EDT(-0400)] <michelled> is it not the options listed in the API docs?
[15:26:05 EDT(-0400)] <Bosmon> In our "standard model", the only "authoritative source" of the selector info is the "runtime" options structure in the overall component
[15:26:19 EDT(-0400)] <Bosmon> Yes, but you do not know what that is going to do, until it has been resolved against the component defaults
[15:26:30 EDT(-0400)] <Bosmon> And the only place that is authoritatively done is inside the reorderer's own constructor
[15:26:43 EDT(-0400)] <Bosmon> Therefore the LayoutHandler couldn't possibly be constructed at a time prior to that...
[15:26:49 EDT(-0400)] <michelled> ok! I finally understand
[15:29:07 EDT(-0400)] <michelled> so what you're trying to do is have the reorderer create a layout handler once it has already resolved the defaults
[15:29:25 EDT(-0400)] <Bosmon> thatReorderer.layoutHandler = window[options.layoutHandlerName].apply(null, thatReorderer, options);
[15:29:26 EDT(-0400)] <Bosmon> Yes
[15:29:35 EDT(-0400)] <Bosmon> And, proposedly, with a line looking something like that
[15:34:39 EDT(-0400)] <Bosmon> Don't we really think that the ListLayoutHandler really does represent a sensible default though?
[15:35:03 EDT(-0400)] <michelled> I do, but think Colin and I have had the same disagreement
[15:35:23 EDT(-0400)] <michelled> so, if the layouthandlers live in the fluid namespace you could just do this:
[15:35:33 EDT(-0400)] <Bosmon> Yes
[15:35:42 EDT(-0400)] <Bosmon> avatarCreator: defaultAvatarCreator,
[15:35:42 EDT(-0400)] <Bosmon> keysets: fluid.defaultKeysets,
[15:35:42 EDT(-0400)] <Bosmon> layoutHandlerName: "fluid.listLayoutHandler",
[15:35:42 EDT(-0400)] <Bosmon>
[15:35:42 EDT(-0400)] <michelled> fluid[options.layoutHandlerName].apply ....
[15:35:50 EDT(-0400)] <Bosmon> Oh, that is a good idea
[15:35:57 EDT(-0400)] <Bosmon> But it would prohibit people writing their own layout handlers
[15:36:00 EDT(-0400)] <Bosmon> In other namespaces...
[15:36:38 EDT(-0400)] <michelled> yes, that's true, but is that important?
[15:38:20 EDT(-0400)] <Bosmon> I dunno
[15:38:26 EDT(-0400)] <Bosmon> Would we really want to prohibit that?
[15:38:37 EDT(-0400)] <Bosmon> It feels mean
[15:39:30 EDT(-0400)] <michelled> I guess so.
[15:51:39 EDT(-0400)] <Bosmon> OK
[15:51:42 EDT(-0400)] <Bosmon> Another new idea....
[15:51:45 EDT(-0400)] <Bosmon> "fluid.fail()"
[15:52:04 EDT(-0400)] <Bosmon> Given that the debuggers we work with behave in such a pathetic way in the face of uncaught exceptions
[15:52:11 EDT(-0400)] <Bosmon> Or even caught ones, for that matter...
[15:53:31 EDT(-0400)] <Bosmon> fluid.fail = function(message) {
[15:53:31 EDT(-0400)] <Bosmon> fluid.utils.setLogging(true);
[15:53:31 EDT(-0400)] <Bosmon> fluid.utils.debug(message);
[15:53:31 EDT(-0400)] <Bosmon> message.fail(true);
[15:53:31 EDT(-0400)] <Bosmon> }
[15:53:33 EDT(-0400)] <Bosmon> Currently it does this
[15:53:48 EDT(-0400)] <Bosmon> The last line typically causes the debugger, if it is running, to stop in an actually useful way
[16:00:29 EDT(-0400)] <michelled> should we fail silently if we are not in logging mode already?
[16:00:47 EDT(-0400)] <Bosmon> Yes... that is a good point
[16:00:59 EDT(-0400)] <Bosmon> I was intending the inside of this method to be a bit more "intelligent" in the long run
[16:01:48 EDT(-0400)] <Bosmon> Although it would be a bit awkward to have weird new code paths tested in production that weren't exercised during development/testing...
[16:03:41 EDT(-0400)] <Bosmon> REALLY weird jQuery behaviour....
[16:04:00 EDT(-0400)] <Bosmon> Even if you give it a container as a 2nd argument, it will still give you the bloody document if the selector fails
[16:04:20 EDT(-0400)] <Bosmon> For example, $("", node) is not equal to node, but "document"....
[16:04:53 EDT(-0400)] <Bosmon> Is there an accepted syntax for this?
[16:07:32 EDT(-0400)] <Bosmon> Hah!
[16:07:33 EDT(-0400)] <Bosmon> init: function( selector, context ) {
[16:07:33 EDT(-0400)] <Bosmon> // Make sure that a selection was provided
[16:07:33 EDT(-0400)] <Bosmon> selector = selector || document;
[16:07:35 EDT(-0400)] <Bosmon> Here is the code
[16:07:46 EDT(-0400)] <Bosmon> If your selector is "falsy", it turns your SELECTOR into document!!!!!
[16:07:57 EDT(-0400)] <Bosmon> Complete pants!!!!!
[16:45:52 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[16:59:23 EDT(-0400)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[17:11:23 EDT(-0400)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has left #fluid-work
[17:40:54 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has left #fluid-work
[17:52:06 EDT(-0400)] <colinclark> did Fish leave for the day?
[18:04:59 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-74.LIPS.Berkeley.EDU) has joined #fluid-work
[21:27:04 EDT(-0400)] * apetro-_ (n=apetro@adsl-75-32-40-98.dsl.chcgil.sbcglobal.net) has joined #fluid-work