fluid-work IRC Logs-2011-07-18
[08:13:02 CDT(-0500)] <huslage> mornin
[08:35:35 CDT(-0500)] <heidi_> huslage i no longer have permission to access dev.inclusivedesign.ca - did something change?
[08:35:43 CDT(-0500)] <huslage> sucks2beU
[08:35:46 CDT(-0500)] <huslage> oh wait
[08:35:50 CDT(-0500)] <huslage> lemme look
[08:35:52 CDT(-0500)] <heidi_> ha
[08:36:06 CDT(-0500)] <huslage> what's the error?
[08:36:31 CDT(-0500)] <heidi_> huslage You don't have permission to access / on this server.
[08:36:41 CDT(-0500)] <huslage> oh bother
[08:36:43 CDT(-0500)] <huslage> ok
[08:37:04 CDT(-0500)] <huslage> everything is in subdirectories on that server
[08:37:13 CDT(-0500)] <huslage> because i didn't know what was supposed to be "home"
[08:37:22 CDT(-0500)] <huslage> so i put things in /wordpress and /mediawiki
[08:37:26 CDT(-0500)] <heidi_> huslage ah i see sorry - i just have to do /wordpress
[08:37:32 CDT(-0500)] <heidi_> thanks
[08:39:18 CDT(-0500)] <heidi_> huslage we can make 'home' /wordpress
[08:39:22 CDT(-0500)] <heidi_> no rush
[08:39:36 CDT(-0500)] <huslage> sure
[08:48:53 CDT(-0500)] <heidi_> hey Justin_o when you were doing html5 research... did you find out if browsers are properly exposing the new elements to AT?
[08:49:12 CDT(-0500)] <heidi_> i'm assuming AT doesn't make use of most of it yet, but are browsers at least allowing that option?
[08:51:57 CDT(-0500)] <heidi_> maybe clown would know?
[08:56:35 CDT(-0500)] <clown> heidi_: sorry, I have not done any testing of HTML5 elements with browser/AT combinations.
[08:56:55 CDT(-0500)] <heidi_> clown okay thanks
[08:56:57 CDT(-0500)] <clown> i'm thinking maybe davidb would know.
[08:57:06 CDT(-0500)] <heidi_> yeah good idea
[08:57:20 CDT(-0500)] <heidi_> jessm was there any talk about idi site being html5 ?
[08:57:34 CDT(-0500)] <jessm> heidi_: not yet, but i think it's a great idea
[08:57:37 CDT(-0500)] <jessm> what did you have in mind?
[08:57:46 CDT(-0500)] <clown> heidi_: there is an #accessibility channel on irc.mozilla.org for FF a11y issues.
[08:57:54 CDT(-0500)] <heidi_> jessm nothing in particular- there are just a lot of new ways of doing things w html5
[08:57:55 CDT(-0500)] <anastasiac> heidi_, Justin_o: the manual test page for UIOptions is broken - it wasn't updated to the new iframe work. It's a small fix: add a selector and a demands block. Should I file a blocker and submit a pull request?
[08:58:10 CDT(-0500)] <heidi_> clown ah thanks - dave hang out there?
[08:58:33 CDT(-0500)] <heidi_> anastasiac sounds like a good plan to me!
[08:58:49 CDT(-0500)] <clown> heidi_: yup. he's one of the admins on that channel.
[08:58:56 CDT(-0500)] <heidi_> excellent, thanks
[08:59:00 CDT(-0500)] <clown> wlcm
[08:59:13 CDT(-0500)] <anastasiac> I'll check if Justin_o agrees that it should be a blocker
[09:03:33 CDT(-0500)] <Justin_o> anastasiac: yes.. i think you should make that blocker
[09:03:43 CDT(-0500)] <anastasiac> thanks, Justin_o
[09:04:31 CDT(-0500)] <Justin_o> heidi_: you can take a look at this page
[09:04:32 CDT(-0500)] <Justin_o> http://html5accessibility.com/
[09:05:03 CDT(-0500)] <Justin_o> That's the most comprehensive list that i know of
[09:07:30 CDT(-0500)] <heidi_> Justin_o thanks
[09:07:38 CDT(-0500)] <heidi_> i'm hesitant to use stuff like... putting h1's everywhere
[09:07:44 CDT(-0500)] <heidi_> before AT has caught up
[09:08:41 CDT(-0500)] <heidi_> Justin_o jessm davidb suggests "for non-experimental parts of the IDRC site I'd try to make it accessible to the largest audience, otherwise I'd forge ahead on other parts."
[09:09:10 CDT(-0500)] <Justin_o> heidi_: seems reasonable
[09:11:48 CDT(-0500)] <heidi_> Justin_o yeah might just take playing... not sure how <header> and <hgroup> etc would be handled by AT right now, hopefully just ignored?
[09:12:07 CDT(-0500)] <heidi_> this site is really helpful tho, thanks again
[09:13:17 CDT(-0500)] <Justin_o> heidi_: no problem.. i think i'd stay away from hgroup.. i think I've heard of people trying to change that tag.. also i think that the header will just be treated like a div
[09:13:36 CDT(-0500)] <jessm> heidi_: were we thinking of *not*making non-experiemental parts of the IDI site accessible to the largest audience?
[09:13:53 CDT(-0500)] <heidi_> Justin_o yeah it looks like no browsers are even using hgroup
[09:14:59 CDT(-0500)] <heidi_> jessm no no... just something to keep in mind when getting html5-y... just need to make sure the new stuff won't hurt that mandate
[09:16:39 CDT(-0500)] <Justin_o> heidi_: for your html5 tags.. they may not work in IE out of the box, since it doesn't like having tags it doesn't know about.. but you can work around this.. take a look at http://diveintohtml5.org/forms.html.. you can also use some code i wrote for the HTML5 demo we gave at the a11y conference https://github.com/jobara/workshops/blob/master/examples/HTML5-inputs/js/HTML5-backcompat.js or something like modernizr http://www.modernizr.com/ you should al
[09:16:39 CDT(-0500)] <Justin_o> make sure that you have styles that set the properly display type (i.e. block or inline)
[09:18:18 CDT(-0500)] <heidi_> Justin_o in your opinion is adding in html5 smart to do at this point or should we stick with html4 for the new idi site and revisit it later once browsers/AT have caught up? it'd be nice to start using the new stuff, but if IE doesn't even deal with it well... that's pretty bad
[09:19:49 CDT(-0500)] <heidi_> i think maybe in the case of a new tag being treated like a regular div, that might be work-with-able
[09:22:42 CDT(-0500)] <Justin_o> heidi_: i'm currently of the opinion that we should start moving to HTML5 where possible.. the work around to get it backwards compatible is pretty minor
[09:23:13 CDT(-0500)] <Justin_o> it's just creating elements in IE6 and making sure that there are default styles (like a reset) to set the display type to block or inline for the new elements
[09:23:33 CDT(-0500)] <Justin_o> should be IE not IE6
[09:23:35 CDT(-0500)] <heidi_> Justin_o some parts of html5 at least, just to point us in the right direction
[09:24:06 CDT(-0500)] <heidi_> i think i'll still keep traditional header h1 h2 h3 hierarchies
[09:24:07 CDT(-0500)] <Justin_o> heidi_: yes.. like i think we should be using the new section types and inputs
[09:24:16 CDT(-0500)] <heidi_> thoughts on that?
[09:24:17 CDT(-0500)] <Justin_o> heidi_: yes.. that's fine
[09:24:29 CDT(-0500)] <heidi_> k thanks
[09:24:57 CDT(-0500)] <Justin_o> I think for those H1, H2, and etc. they will still work with the new system as well... once it's in place
[09:25:51 CDT(-0500)] <huslage> Justin_o: i'm going to get your stuff done shortly.
[09:28:07 CDT(-0500)] <heidi_> Justin_o i think in html5 headers are relative to the section
[09:28:17 CDT(-0500)] <heidi_> so you would have h1's all over
[09:29:54 CDT(-0500)] <Justin_o> heidi_: yes.. that's true, but i think it will be fine if you they aren't h1's in the section.. meaning.. if you put an h2.. as the first header of an article for example, but i could be wrong
[09:30:12 CDT(-0500)] <Justin_o> huslage: thanks.. looking forward to trying out those new jira plugins
[09:35:57 CDT(-0500)] <heidi_> Justin_o ah, i think so too. eventually it won't make sense but i think it's ok for now
[09:36:55 CDT(-0500)] <Justin_o> heidi_: yep.. agreed
[09:37:46 CDT(-0500)] <huslage> Justin_o: bonfire needs Jira 4.3…we're at 4.1
[09:38:18 CDT(-0500)] <Justin_o> huslage: ah.. would it be a problem to upgrade?
[09:38:23 CDT(-0500)] <huslage> dunno
[09:38:24 CDT(-0500)] <Justin_o> or too dificult
[09:38:24 CDT(-0500)] <huslage> looking
[09:38:26 CDT(-0500)] <Justin_o> huslage: thanks
[09:39:39 CDT(-0500)] <colinclark> What's bonfire?
[09:40:05 CDT(-0500)] <Justin_o> colinclark: http://www.atlassian.com/en/software/bonfire
[09:40:20 CDT(-0500)] <Justin_o> basically it's a allows you to use a browser plugin to file jiras
[09:40:38 CDT(-0500)] <colinclark> Ah, right
[09:44:30 CDT(-0500)] <huslage> Justin_o: see /msg
[10:28:52 CDT(-0500)] <lahabana> colinclark: you're there?
[10:30:38 CDT(-0500)] <lahabana> hi michelled have you got a few minutes I need your help ...
[10:36:51 CDT(-0500)] <lahabana> Is somebody here have a few minutes?
[10:38:51 CDT(-0500)] <huslage> jura is upgraded. source control integration isn't complete yet.
[10:38:53 CDT(-0500)] <huslage> jira
[10:38:55 CDT(-0500)] <huslage> i can't type
[10:44:18 CDT(-0500)] <michelled> lahabana: I'm here now
[10:44:24 CDT(-0500)] <lahabana> hi
[10:44:28 CDT(-0500)] <michelled> hi 
[10:44:40 CDT(-0500)] <lahabana> I've just a change applier into the videoPlayer
[10:44:55 CDT(-0500)] <lahabana> and now I've got some really repetitive code: https://github.com/lahabana/videoPlayer/blob/FLUID-4297/js/VideoPlayer_controllers.js#L12-58
[10:45:20 CDT(-0500)] <lahabana> as you see it's always the same
[10:45:34 CDT(-0500)] <lahabana> so I tried to create a function to factor all that
[10:45:53 CDT(-0500)] <lahabana> toggleChangeClick (on line 12)
[10:46:33 CDT(-0500)] <lahabana> but the value parameter should be a reference to the model element not its value
[10:46:43 CDT(-0500)] <lahabana> so I was wondering how I could do that?
[10:46:55 CDT(-0500)] <lahabana> through fluid.demands maybe no?
[10:47:24 CDT(-0500)] <lahabana> do I make sens michelled?
[10:49:29 CDT(-0500)] <anastasiac> huslage, could you tell me the proper URL to access the fluid project continuum instance now?
[10:49:41 CDT(-0500)] <huslage> anastasiac: um.
[10:50:01 CDT(-0500)] <huslage> i thought it was build.fluidproject.org/fluid
[10:50:35 CDT(-0500)] <anastasiac> huslage, did you mean http://build.fluidproject.org/continuum ? and if so, that's not working now
[10:50:43 CDT(-0500)] <huslage> ohhh
[10:50:44 CDT(-0500)] <huslage> ok
[10:50:52 CDT(-0500)] <huslage> i haven't changed anything
[10:50:54 CDT(-0500)] <huslage> odd
[10:50:54 CDT(-0500)] <huslage> ok
[10:51:12 CDT(-0500)] <huslage> lemme look
[10:51:14 CDT(-0500)] <anastasiac> ok, I didn't know if the url changed with server changes, or anything. so I guess the issue is "continuum seems to be down"
[10:51:38 CDT(-0500)] <huslage> yes.
[10:56:11 CDT(-0500)] <michelled> lahabana: I'm not sure I understand what's wrong with the value parameter - can you explain more?
[10:56:33 CDT(-0500)] <lahabana> well the value parameter will change through the time
[10:56:39 CDT(-0500)] <lahabana> as it's part of the model
[10:57:03 CDT(-0500)] <lahabana> but how I do it now : toggleChangeClick(that, "playButton", "states.play", that.model.states.play);
[10:57:18 CDT(-0500)] <lahabana> it will stay to the same value all the time
[10:57:32 CDT(-0500)] <michelled> right, so what you actually want to do is pass in the model and then extract the value at the time the fireChangeRequest happens
[10:57:49 CDT(-0500)] <lahabana> yes
[10:57:50 CDT(-0500)] <lahabana>
[10:58:05 CDT(-0500)] <michelled> since you are already passing the 'path' you even know what you want to extract
[10:58:06 CDT(-0500)] <lahabana> sorry if I'm not clear
[10:58:13 CDT(-0500)] <lahabana> yes
[10:58:18 CDT(-0500)] <michelled> you are perfectly clear
[10:58:48 CDT(-0500)] <lahabana> but I want to change the value of it to it's contrary (it's a boolean
[10:59:08 CDT(-0500)] <lahabana> that's where I'm stuck
[10:59:17 CDT(-0500)] <michelled> hang on a sec
[11:00:29 CDT(-0500)] <lahabana> ok
[11:02:09 CDT(-0500)] <huslage> Justin_o: everything should be fixed now with JIRA. Your new plugins are installed
[11:02:45 CDT(-0500)] <Justin_o> huslage: thanks a lot
[11:06:09 CDT(-0500)] <michelled> lahabana: sorry - I was a little distracted
[11:06:18 CDT(-0500)] <lahabana> michelled: it's ok
[11:06:35 CDT(-0500)] <michelled> lahabana: you should be able to use 'fluid.get' to get the value at 'path' in the model
[11:06:46 CDT(-0500)] <michelled> something like this maybe: http://pastebin.com/m3BYzKYM
[11:06:46 CDT(-0500)] <lahabana> really?
[11:07:03 CDT(-0500)] <michelled> then when you call toggleChangeClick you'll pass in that.model
[11:07:20 CDT(-0500)] <lahabana> great didn't know fluid.get
[11:07:28 CDT(-0500)] <lahabana> but it seems to be what I need
[11:07:39 CDT(-0500)] <michelled> lahabana: although since you already passing in that, you don't even need to pass in the model
[11:07:48 CDT(-0500)] <michelled> you can just get it out yourself
[11:07:58 CDT(-0500)] <lahabana> yes it's what I thought
[11:08:00 CDT(-0500)] <lahabana> great
[11:08:09 CDT(-0500)] <lahabana> thx a lot I'm going to try that
[11:08:17 CDT(-0500)] <michelled> np - glad I could help
[11:08:18 CDT(-0500)] <huslage> anastasiac: it's fixed
[11:09:52 CDT(-0500)] <lahabana> michelled: it's perfectly working thx again 
[11:10:04 CDT(-0500)] <michelled> great
[11:10:05 CDT(-0500)] <anastasiac> huslage, thanks - what was the problem?
[11:10:22 CDT(-0500)] <huslage> there were two instances of continuum running for some reason
[11:10:32 CDT(-0500)] <huslage> the database is kinda dumb
[11:10:40 CDT(-0500)] <huslage> so it crashed
[11:11:26 CDT(-0500)] <huslage> oh Justin_o, there is now an official github plugin so when we add new JIRA projects you can just point them at the repo and cut and paste the callback URL. no more editing stupid little scripts
[11:11:50 CDT(-0500)] <michelled>
[11:34:23 CDT(-0500)] <colinclark> Justin_o: Fairly interesting news: http://functionsource.com/post/john-j-barton-and-the-future-of-firebug
[11:56:35 CDT(-0500)] <Justin_o> colinclark: that's interesting
[12:21:43 CDT(-0500)] <Bosmon> Justin_o, cindyli1 - checking in on how UIO is getting on
[12:21:56 CDT(-0500)] <Bosmon> Do all the FatPanel tests run now?
[12:22:27 CDT(-0500)] <Justin_o> Bosmon: hello.. not sure.. i think cindyli1 is still working on it..
[12:22:38 CDT(-0500)] <Bosmon> Justin_o - and how about TOC?
[12:22:58 CDT(-0500)] <Justin_o> Bosmon: harris is just refactoring his code a bit, but other than that it should all be working now
[12:23:06 CDT(-0500)] <Bosmon> That's cool
[12:23:13 CDT(-0500)] <Justin_o> Bosmon: i'm hoping harriswong will have a pull request by the end of the day
[12:23:24 CDT(-0500)] <huslage> awesome new node tool: http://tamejs.org/
[12:23:31 CDT(-0500)] <Bosmon> anastasiac - to answer your mail of earlier, further than saying that we will discourage use of UIO without a wrapper, I think it is more likely that it will be completely impossible
[12:24:14 CDT(-0500)] <huslage> turns Node into Smalltalk
[12:24:32 CDT(-0500)] <Bosmon> Erm, yay, huslage 
[12:24:41 CDT(-0500)] <Bosmon> Let's party like it's 1985
[12:25:11 CDT(-0500)] <huslage> who's teaching me javascript, btw?
[12:32:56 CDT(-0500)] <huslage> fail
[12:34:02 CDT(-0500)] <Bosmon> I'll give it a go
[12:34:09 CDT(-0500)] <Bosmon> Although michelled is our Head of Mentouring
[12:34:33 CDT(-0500)] <huslage> heh
[12:35:31 CDT(-0500)] <Bosmon> My CATTT knows a little FORTRAN
[12:40:19 CDT(-0500)] <harriswong> Justin_o: I will make a pull request at the end of the day regardless if there is a better generateTree() or not?
[12:41:03 CDT(-0500)] <Justin_o> harriswong: okay.. you don't have to rush it though if it's not ready
[12:41:09 CDT(-0500)] <harriswong> k
[12:48:48 CDT(-0500)] <Justin_o> huslage: i'm having problems when i'm trying to use bonfire.. this is the error i'm getting
[12:48:49 CDT(-0500)] <Justin_o> Error communicating with the JIRA server, please check your settings. Hide details The URL http://issues.fluidproject.org/rest/auth/latest/session responded with a status code of 200
[12:54:48 CDT(-0500)] <Justin_o> huslage: there seems to be some other oddities too
[12:54:57 CDT(-0500)] <Justin_o> with jira in general
[12:55:27 CDT(-0500)] <Justin_o> for example when i try to login it fails, but if i refresh the page it works
[12:55:44 CDT(-0500)] <cindyli1> Bosmon: sorry, just saw ur question about the status on UIO. somehow my pidgin stops giving a blinking alert when my name is mentioned in the channel. will have to restart pidgin later . anyway, the status, as u know, the original issue was that UIO worked on firefox but not other browsers
[12:56:06 CDT(-0500)] <Bosmon> cindyli1 - did you find the cause for that?
[12:56:22 CDT(-0500)] <cindyli1> i've fixed a part that full page with and without preview works across all browsers.
[12:56:28 CDT(-0500)] <cindyli1> but not the fat panel yet
[12:57:03 CDT(-0500)] <cindyli1> the problem is that the component uiOptions, a child of uiOptions.loader, is not instantiated in time
[12:58:27 CDT(-0500)] <cindyli1> trying to figure out why
[13:21:11 CDT(-0500)] <Bosmon> cindyli - cool - any ideas about why it might be?
[13:24:22 CDT(-0500)] <cindyli> Bosmon: apparently something on the fatPanel tree structure. but haven't pinpointed where
[13:24:27 CDT(-0500)] <cindyli>
[13:25:36 CDT(-0500)] <Bosmon> cindyli - I'm sure you are equal to the task
[13:26:31 CDT(-0500)] <cindyli> Bosmon: i initially thought might be the {} on loader that references to other component that are still in creation or not ready. but i've removed all the {} still the same issue. sigh... now trying to compare the debug flow of ff and chrome
[13:27:07 CDT(-0500)] <Bosmon> I guess best to understand what the event sequence is first
[13:27:16 CDT(-0500)] <Bosmon> In what way is uiOptions "not in time"?
[13:27:40 CDT(-0500)] <Bosmon> It sounds like you think it is "too late" somehow - but is that possible?
[13:27:43 CDT(-0500)] <Bosmon> What is it later than?
[13:29:04 CDT(-0500)] <cindyli> well, might not "not in time", it doesn't get instantiated at the location that it gets instantiated in firefox
[13:29:19 CDT(-0500)] <cindyli> so, might be something delay it to later or not happened at all
[13:29:35 CDT(-0500)] <Bosmon> Does it happen at all?
[13:31:43 CDT(-0500)] <cindyli> no, because of the js error
[13:31:50 CDT(-0500)] <Bosmon> aha
[13:31:52 CDT(-0500)] <Bosmon> What is the error
[13:32:34 CDT(-0500)] <cindyli> "uiOptionsLoader.uiOptions.events" not found
[13:32:41 CDT(-0500)] <Bosmon> Aha
[13:32:44 CDT(-0500)] <Bosmon> And what is it not found BY
[13:32:46 CDT(-0500)] <cindyli> because "uiOptionsLoader.uiOptions" is undefined
[13:40:57 CDT(-0500)] <Bosmon> cindyli - and what is trying to evaluate the events - is the event binder component?
[13:41:36 CDT(-0500)] <cindyli> yes
[13:41:51 CDT(-0500)] <cindyli> on eventBinder, we have a listener:
[13:41:55 CDT(-0500)] <cindyli> listeners: {
[13:41:55 CDT(-0500)] <cindyli> // This literal specification works around FLUID-4337
[13:41:55 CDT(-0500)] <cindyli> onUIOptionsComponentReady: fluid.uiOptionsEventBinder.bindModelChanged
[13:41:55 CDT(-0500)] <cindyli> }
[13:42:22 CDT(-0500)] <cindyli> the error occurs in "fluid.uiOptionsEventBinder.bindModelChanged"
[13:42:23 CDT(-0500)] <Bosmon> So - we expect that uiOptions is actually ready, when onUIOptionsComponentReady fires
[13:42:31 CDT(-0500)] <Bosmon> The question is - why is it not?
[13:42:31 CDT(-0500)] <cindyli> exactly
[13:42:38 CDT(-0500)] <cindyli> yes
[13:43:36 CDT(-0500)] <cindyli> by reading the console log, in ff, right before resolving "onUIOptionsComponentReady", it has
[13:43:37 CDT(-0500)] <cindyli> v
[13:43:38 CDT(-0500)]
<cindyli> Finished instantiation of component with name "uiOptions" as child of
[13:44:18 CDT(-0500)] <cindyli> but this lovely "Finished instantiation uiOptions" statement never happens in chrome
[13:44:37 CDT(-0500)] <cindyli> that's what i'm trying to find out
[13:46:49 CDT(-0500)] <Bosmon> It looks like just a random ordering of listeners
[13:47:03 CDT(-0500)] <Bosmon> If you look at line 116 of FatPanel, there is no priority assigned to the listener
[13:47:19 CDT(-0500)] <Bosmon> So the ordering of eventBinder will be random with respect to the actual creation of UIOptions component
[13:47:31 CDT(-0500)] <Bosmon> You should write a priority annotation here and it will probably fix the problem
[13:48:27 CDT(-0500)] <Bosmon> well... just a second
[13:48:42 CDT(-0500)] <Bosmon> So... i) template loads, ii) fires templateReady
[13:48:56 CDT(-0500)] <Bosmon> iii) this creates uiOptions
[13:49:46 CDT(-0500)] <Bosmon> iv) UIoptions loads template, which we hope is synchronous... v) fires UIOptionsComponentReady
[13:50:21 CDT(-0500)] <Bosmon> So - actually it is impossible for uiOptions not to be loaded when ComponentReady is fired - since it is the last action of its own finalInit function
[13:50:43 CDT(-0500)] <Bosmon> ah!
[13:50:46 CDT(-0500)] <Bosmon> But the component is not constructed yet
[13:51:10 CDT(-0500)] <Bosmon> That is, until finalInit returns, the subcomponent is not delivered to uiOptionsLoader
[13:51:31 CDT(-0500)] <Bosmon> So, the difference must be a difference of whether the I/O on line 459 of UIOptions.js is synchronous or not
[13:51:41 CDT(-0500)] <Bosmon> Somehow, on Firefox, it is asynchronous, and on other platforms, it is synchronous
[13:52:10 CDT(-0500)] <Bosmon> And, I suspect the reason it is different on firefox is because of that crazy branch that is in the framework that calls "setTimeout(1)" ONLY on Firefox, to avoid blowing up Firebug
[13:53:05 CDT(-0500)] <Bosmon> cindyli - what I suggest is that we avoid relying on the nesting of uiOptionsLoader.uiOptions in the binder - but instead fire the uiOptions component itself as the argument to UIOptionsComponentReady.fire on line 463
[13:53:16 CDT(-0500)] <Bosmon> In general we should avoid relying on particular component nesting in any case
[13:53:24 CDT(-0500)] <cindyli> ic
[13:53:26 CDT(-0500)] <Bosmon> Since "in the far future" there will not be any component nesting
[13:54:54 CDT(-0500)] <cindyli> thanks alot, Bosmon. trying out
[14:13:54 CDT(-0500)] <cindyli> Bosmon: u r truly the genius. the problem is fixed with ur suggestion!!! :-D
[14:14:23 CDT(-0500)] <Bosmon> cindyli - I'm glad the problem has gone away
[14:14:27 CDT(-0500)] <Bosmon> Are there still test failures?
[14:15:13 CDT(-0500)] <cindyli> Bosmon: the test will fail for now because i reconstructed loader structure to fix full page versions
[14:15:52 CDT(-0500)] <cindyli> Bosmon: should be quick to fix tests at ff first. will let u know if they pass on other browsers
[14:18:59 CDT(-0500)]
<cindyli> Bosmon: fyi, the loader used to have 4 subcomponents - uiOptions and 3 controls components. 3 controls components use
to refer to events/applier of the sibling "uiOptions", which is only accepted by firefox. reconstructing 3 controls to sub-components of uiOptions fixed the problem
[14:21:53 CDT(-0500)] <Bosmon> cindyli - That's interesting
[14:49:29 CDT(-0500)] <cindyli> Bosmon: now uiOptions-tests passes in ff but hangs on chrome due to the similar uiOptions-not-ready issue
[14:49:55 CDT(-0500)] <cindyli> Bosmon: as u've known that each uio tests fires at uiOptionsLoader onReady event
[14:51:11 CDT(-0500)] <cindyli> at the time loader is ready but the readiness of uiOptions is not guaranteed
[14:51:34 CDT(-0500)] <Bosmon> Ok - then that event is firing at the wrong time
[14:51:46 CDT(-0500)] <Bosmon> The purpose of the event is to fire at a time when readiness of uiOptions is guaranteed
[14:51:57 CDT(-0500)] <cindyli> yes
[14:52:05 CDT(-0500)] <cindyli> by looking at the onReady code: https://github.com/cindyli/infusion/blob/FLUID-4317/src/webapp/components/uiOptions/js/UIOptions.js#L255-280
[14:52:46 CDT(-0500)] <cindyli> loader event "onUIOptionsReadyBridge" is linked with "onUIOptionsComponentReady"
[14:52:50 CDT(-0500)] <Bosmon> Yes
[14:53:04 CDT(-0500)]
<cindyli> while uiOptions "onUIOptionsComponentReady" is "
.events.onUIOptionsComponentReady"
[14:53:32 CDT(-0500)] <Bosmon> Yes.... doesn't this seem to guarantee that the component is actually ready?
[14:53:56 CDT(-0500)] <cindyli> that's what i thought it should be guaranteed
[14:54:13 CDT(-0500)] <Bosmon> So - in what sense do you see that the component is not ready?
[14:55:14 CDT(-0500)] <cindyli> when i run uioptions tests at chrome, i got uiOptionsLoader.uiOptions is undefined
[14:55:21 CDT(-0500)] <Bosmon> cindyli - that's correct
[14:55:24 CDT(-0500)] <Bosmon> The component is "ready"
[14:55:28 CDT(-0500)] <Bosmon> But it has not yet been added to the tree
[14:55:35 CDT(-0500)] <cindyli> aha
[14:55:35 CDT(-0500)] <Bosmon> That happens after the return of the finalInit function
[14:55:42 CDT(-0500)] <cindyli> yes
[14:55:44 CDT(-0500)] <Bosmon> So you should again use the argument of the event
[14:55:48 CDT(-0500)] <Bosmon> If you want to get access to the component
[14:55:53 CDT(-0500)] <cindyli> now argument is in place
[14:56:36 CDT(-0500)] <Bosmon> I guess in the next framework version we will have an "onCreate" event which is fired by the framework once the component is COMPLETELY ready and added to the tree
[14:56:52 CDT(-0500)] <cindyli> haha, good idea
[14:57:01 CDT(-0500)] <cindyli> i tried to acess it at https://github.com/cindyli/infusion/blob/FLUID-4317/src/webapp/components/uiOptions/js/UIOptions.js#L268
[14:57:12 CDT(-0500)]
<cindyli> via args: ["
", "
.0"]
[14:57:34 CDT(-0500)]
<cindyli> however, "
.0" is still undefined
[14:57:53 CDT(-0500)] <cindyli> Bosmon: did i do something wrong?
[14:59:49 CDT(-0500)] <Bosmon> cindyli - did you add the argument in at line 463?
[15:00:00 CDT(-0500)] <cindyli> yes, i did
[15:00:03 CDT(-0500)] <Bosmon> ok
[15:00:54 CDT(-0500)] <Bosmon> Is the argument not passed through if you just put nothing at line 268?
[15:04:42 CDT(-0500)] <cindyli> Bosmon: by removing the whole line 268?
[15:05:03 CDT(-0500)] <cindyli> line 256 would fail with undefined "uiOptionsLoader"
[15:05:30 CDT(-0500)] <cindyli> ah, i see where i did wrongly. trying more
[15:05:30 CDT(-0500)] <Bosmon> ah dear
[15:05:56 CDT(-0500)] <Bosmon> There may be another framework bug
[15:06:17 CDT(-0500)]
<Bosmon> There may not be a test covering the specific case of the
entry of a boilder event :|
[15:07:08 CDT(-0500)] <Bosmon> boiled
[15:08:02 CDT(-0500)] <Bosmon> Well
[15:08:11 CDT(-0500)] <Bosmon> It would be a pretty blatant bug, if it were a bug
[15:08:24 CDT(-0500)]
<Bosmon> Since that is the only place you would expect to be able to use the
list 
[15:09:16 CDT(-0500)] <cindyli> relief, Bosmon, seems it was my silly mistake. didn't passes new uiOptions argument into "fluid.uiOptions.onReadyFirer" function
[15:09:24 CDT(-0500)] <cindyli>
[15:09:26 CDT(-0500)] <Bosmon> cindyli - that's great
[15:09:33 CDT(-0500)]
<Bosmon> So the
.0 entry works fine?
[15:09:45 CDT(-0500)] <cindyli> yes, it did
[15:09:49 CDT(-0500)] <Bosmon> cool
[15:09:59 CDT(-0500)] <cindyli> at least at the first test case i just tried. thanks again, Bosmon
[15:33:49 CDT(-0500)] <colinclark> Hey heidi_ and huslage, do you guys have a quick sec to chat?
[15:34:02 CDT(-0500)] <heidi_> yep
[15:34:03 CDT(-0500)] <huslage> yeah but i'm on the phone
[15:34:05 CDT(-0500)] <colinclark> I've got plenty of ideas about the IDI site
[15:34:21 CDT(-0500)] <heidi_> colinclark great - what are you thinkin?
[15:34:34 CDT(-0500)] <colinclark> So, I'm thinking we should probably take advantage of some of the nice techniques we've been using to build stuff recently
[15:34:47 CDT(-0500)] <colinclark> heidi_: How about we set up a Github repository for our themes?
[15:34:53 CDT(-0500)] <colinclark> Starting with the WordPress theme
[15:34:59 CDT(-0500)] <colinclark> Couple of reasons, I was thinking...
[15:35:02 CDT(-0500)] <heidi_> i think that's a great idea
[15:35:08 CDT(-0500)] <colinclark> It's in line with the open, collaborative nature of the IDI
[15:35:14 CDT(-0500)] <colinclark> also would make it easier for us all to work on it
[15:35:18 CDT(-0500)] <colinclark> and Johnny to get involved, too
[15:35:26 CDT(-0500)] <heidi_> yeah, and versioning nice to keep track of
[15:35:31 CDT(-0500)] <colinclark> I was thinking we could ask Justin_o if he'd be willing to set up an IDI organization on Github for us
[15:35:51 CDT(-0500)] <colinclark> We could use the Fluid Project org, but it might be nice to have something specific to the IDI
[15:35:57 CDT(-0500)] <colinclark> I can imagine in the future there might be other stuff in there
[15:36:11 CDT(-0500)] <heidi_> yeah i'm sure there will be lots of sharey stuff to come just under IDI
[15:36:21 CDT(-0500)] <colinclark> huslage: On the other end, I was thinking we might also want to host all our customization and configuration of these sites in Git as well
[15:36:34 CDT(-0500)] <colinclark> makes it easier, for example, for heidi_ and smriti and others to see how it's configured
[15:36:40 CDT(-0500)] <colinclark> and potentially make tweaks on their own
[15:36:43 CDT(-0500)] <huslage> good idea!
[15:36:51 CDT(-0500)] <colinclark> I can also imagine that this'll all make upgrading much easier
[15:37:04 CDT(-0500)] <colinclark> Justin_o: I know you're super busy with the release
[15:37:17 CDT(-0500)] <colinclark> but do you feel like setting us up an org at some point?
[15:37:36 CDT(-0500)] <colinclark> I was also thinking that we should probably tackle single sign-on sooner rather than later
[15:37:52 CDT(-0500)] <colinclark> not today, since I know you've got other things on your plate, huslage
[15:38:01 CDT(-0500)] <huslage> i have many plates
[15:38:03 CDT(-0500)] <colinclark>
[15:38:11 CDT(-0500)] <Bosmon> All spinning
[15:38:17 CDT(-0500)] <huslage> it's fine
[15:38:18 CDT(-0500)] <colinclark> It strikes me as the kind of thing that is simpler to do earlier, rather than later in the process
[15:38:23 CDT(-0500)] <huslage> SSO yes
[15:38:31 CDT(-0500)] <colinclark> and then we can have a single account for WP, for the media wiki instance, etc.
[15:38:40 CDT(-0500)] <colinclark> I'm thinking CAS is a pretty good option for us
[15:38:45 CDT(-0500)] <colinclark> but I'm open to other suggestions
[15:38:52 CDT(-0500)] <colinclark> I assume it is typically LDAP-backed
[15:39:24 CDT(-0500)] <colinclark> In the long run we can keep half an eye on Mozilla's BrowserID initiative, as a secure alternative to OpenID
[15:39:31 CDT(-0500)] <colinclark> someone has already made a WordPress plugin
[15:39:31 CDT(-0500)] <colinclark> b
[15:39:42 CDT(-0500)] <colinclark> but I think it's probably way too soon to actually use
[15:42:24 CDT(-0500)] <heidi_> huslage does wp or the server have any caching going on? just checking for my own sanity
[15:42:37 CDT(-0500)] <huslage> no. it's off heidi_
[15:42:43 CDT(-0500)] <heidi_> okee doke
[15:42:56 CDT(-0500)] <huslage> LDAP of some sort is what i'm thinking
[15:43:00 CDT(-0500)] <huslage> colinclark
[15:43:09 CDT(-0500)] <colinclark> huslage: yep
[15:43:17 CDT(-0500)] <colinclark> LDAP + CAS seem reasonable, huslage?
[15:43:26 CDT(-0500)] <colinclark> So accounts are in LDAp
[15:43:28 CDT(-0500)] <huslage> i still need to look at CAS really
[15:43:32 CDT(-0500)] <colinclark> and CAS provides the "one place you go to login" part
[15:43:34 CDT(-0500)] <huslage> but sounds good on the face of it
[15:43:36 CDT(-0500)] <colinclark> ok
[15:43:44 CDT(-0500)] <colinclark> Take a look at it when you get a chance and tell me what you think
[15:43:48 CDT(-0500)] <huslage> openAR too
[15:43:51 CDT(-0500)] <huslage> or whatever it's called
[15:43:51 CDT(-0500)] <colinclark> ok
[15:43:54 CDT(-0500)] <huslage> the old sun thing
[15:44:29 CDT(-0500)] <colinclark> heidi_: So in terms of themeing
[15:44:35 CDT(-0500)] <colinclark> I wanted to bounce some ideas around with you
[15:44:44 CDT(-0500)] <heidi_> sure
[15:44:59 CDT(-0500)] <colinclark> Over time, as we introduce new apps into our infrastructure, I guess we'll have lots of different themes
[15:45:11 CDT(-0500)] <colinclark> all of which give an impression of seamlessness across the sites
[15:45:11 CDT(-0500)] <heidi_> we can yep
[15:45:30 CDT(-0500)] <colinclark> So, I was thinking, in many ways we might think of our themes for a given app as a kind of "reset theme"
[15:45:46 CDT(-0500)] <colinclark> Which then allows us to use as much of the FSS (along with our own custom extensions) as possible
[15:46:01 CDT(-0500)] <colinclark> Hopefully it should lead us towards a kind of "meta theme," implemented in the FSS
[15:46:07 CDT(-0500)] <colinclark> which we can across apps
[15:46:12 CDT(-0500)] <colinclark> Does that seem insane?
[15:46:14 CDT(-0500)] <colinclark>
[15:46:27 CDT(-0500)] <heidi_> no like a main theme, and then the child themes would build off that
[15:46:30 CDT(-0500)] <heidi_> makes sense!
[15:46:45 CDT(-0500)] <colinclark> Yeah, and there will be stuff that's common across all apps
[15:46:50 CDT(-0500)] <colinclark> certain types of navigation, etc.
[15:46:59 CDT(-0500)] <heidi_> yeah
[15:47:02 CDT(-0500)] <colinclark> cool
[15:47:10 CDT(-0500)] <colinclark> Part of my inspiration for this is Johnny's WP theme
[15:47:14 CDT(-0500)] <colinclark> which is super bare-bones
[15:47:18 CDT(-0500)] <colinclark> very simple, clean look
[15:47:24 CDT(-0500)] <heidi_> he hasn't sent it to me yet!
[15:47:30 CDT(-0500)] <heidi_> he wanted to clean up first
[15:47:31 CDT(-0500)] <colinclark> with super simplified, HTML5 markup
[15:47:37 CDT(-0500)] <colinclark> yeah, he's a little shy
[15:47:42 CDT(-0500)] <colinclark> I don't want to put too much pressure on him
[15:47:46 CDT(-0500)] <colinclark> but I think he's interested in sharing
[15:47:51 CDT(-0500)] <heidi_> yeah he is
[15:48:06 CDT(-0500)] <colinclark> wicked
[15:48:21 CDT(-0500)] <colinclark> In the meantime I guess it'll be a chance for you to get to know how things are working and start to play around with your own ideas
[15:48:43 CDT(-0500)] <colinclark> but I thought, also, having that Github space might let him look in on what we're doing, even if he's still shy to actually share his theme
[15:49:19 CDT(-0500)] <heidi_> yeah i'd love to share what i'm doing w/ johnny, get him to help me out / give advice
[15:49:24 CDT(-0500)] <colinclark> wicked
[15:49:32 CDT(-0500)] <colinclark> I think this is going to be really fun
[15:49:32 CDT(-0500)] <heidi_> colinclark you've seen http://wiki.fluidproject.org/display/fluid/IDI+website+mockups right
[15:49:40 CDT(-0500)] <colinclark> a chance to start fresh with new infrastructure
[15:49:47 CDT(-0500)] <heidi_> yeah love clean installs
[15:49:56 CDT(-0500)] <colinclark> we'll see if we can design it to last for awhile, and be maximally self-maintainable
[15:50:14 CDT(-0500)] <heidi_> will be fun
[15:50:28 CDT(-0500)] <colinclark> I dream of a world where huslage can focus on awesome new stuff, rather than "can you reset my password?" and things like that
[15:50:47 CDT(-0500)] <heidi_> +1
[15:50:54 CDT(-0500)] <huslage> oh that'd be ok
[15:50:58 CDT(-0500)] <huslage> i'd be happy
[15:52:11 CDT(-0500)] <colinclark> heidi_: Want to be a tie breaker?
[15:52:19 CDT(-0500)] <colinclark> Justin_o is looking at names for our Github org
[15:52:20 CDT(-0500)] <heidi_> yesss
[15:52:23 CDT(-0500)] <colinclark> incluisve-design
[15:52:25 CDT(-0500)] <colinclark> or inclusivedesign
[15:52:39 CDT(-0500)] <heidi_> fluid is fluidwork or fluid-work ?
[15:52:50 CDT(-0500)] <colinclark> on github, we're fluid-project
[15:52:54 CDT(-0500)] <heidi_> i think i'm feeling dashy today
[15:52:58 CDT(-0500)] <colinclark> jameswy liked the idea of being consistent with our domain name
[15:53:04 CDT(-0500)] <colinclark> but I was feeling dashy today, too
[15:53:14 CDT(-0500)] <heidi_> consistent w our other githubs makes sense i think
[15:53:30 CDT(-0500)] <heidi_> inclusive-design
[15:53:42 CDT(-0500)] <huslage> +1
[15:54:53 CDT(-0500)] <colinclark> ok
[16:10:37 CDT(-0500)] <harriswong> Justin_o: i pushed the generateTree() to my github, it can be cleaned up a bit still. I will review that with you tomorrow briefly before I make a pull request.
[16:13:00 CDT(-0500)] <Justin_o> colinclark: we have both inclusive-design and inclusivedesign organizations on github
[16:15:37 CDT(-0500)] <colinclark> thanks!
[16:15:43 CDT(-0500)] <colinclark> I guess we should pick one to actually use
[16:15:52 CDT(-0500)] <colinclark> dashism wins
[23:24:27 CDT(-0500)] * Topic is 'This channel is logged – for details see: http://wiki.fluidproject.org/display/fluid/IRC+Channel' set by jessm on 07:30:00 CST(-0600)