fluid-work IRC Logs-2011-01-24
[09:29:48 CST(-0600)] <michelled> Justin_o: we no longer have an escalated tests in the repository - do you think I should delete the escalated tests directory from svn?
[09:30:44 CST(-0600)] <Justin_o> michelled: yes i think so.. if we need such a thing again, i think it probably shouldn't live in the trunk
[09:30:54 CST(-0600)] <michelled> sounds good
[09:34:29 CST(-0600)] <mlam> colinclark: morning, new patch for uploader tests: FLUID-4033
[09:34:37 CST(-0600)] <colinclark> mlam: Awesome, thanks so much
[09:34:42 CST(-0600)] <colinclark> Sorry about all the back and forth
[09:34:47 CST(-0600)] <colinclark> it's shaping up nicely
[09:34:58 CST(-0600)] <mlam> no problem my fault for not covering enough ground with the test
[09:41:19 CST(-0600)] <heidi_> hey jhung when is the demo portal overhaul planned for?
[09:43:35 CST(-0600)] <colinclark> Infusion 1.5
[09:43:56 CST(-0600)] <jhung> heidi_: on a chat
[09:44:08 CST(-0600)] <heidi_> tanks
[09:44:10 CST(-0600)] <colinclark> So late May-ish
[09:45:35 CST(-0600)] <heidi_> colinclark finishing up fss to do list... will send to you and justin soon for review. then i'll start with the 1.3.1 tasks
[09:45:45 CST(-0600)] <colinclark> That sounds great
[09:46:01 CST(-0600)] <colinclark> Can you post your estimates to the appropriate JIRA tickets?
[09:46:05 CST(-0600)] <colinclark> Thanks for sending those along, I really appreciate it
[09:46:31 CST(-0600)] <heidi_> yep will do
[09:46:42 CST(-0600)] <heidi_> i'm trying to estimate all the fss jiras too
[09:50:39 CST(-0600)] <jhung> jessm: do you have time today to chat about the demo portal?
[09:50:48 CST(-0600)] <jessm> jhung: indeed i do
[09:51:10 CST(-0600)] <jhung> jessm: what time would be good? Jameswy would like to join as well.
[09:51:18 CST(-0600)] <jessm> 3p?
[09:51:39 CST(-0600)] <jhung> jessm: works for me. I'll let James know.
[09:51:53 CST(-0600)] <jessm> jhung: perhaps anastasiac would like to join too?
[09:52:11 CST(-0600)] <jessm> i'm unsure where we start to blur documentation and demos, so i'm thinking inclusion early
[09:52:13 CST(-0600)] <anastasiac> yes, I would
[09:52:19 CST(-0600)] <jessm> cool
[09:52:22 CST(-0600)] <jessm> 3p
[09:52:29 CST(-0600)] <anastasiac> I can do 3p
[09:52:34 CST(-0600)] <jhung> Great!
[09:52:44 CST(-0600)] <jhung> Let's make it 3p in Breeze?
[09:52:58 CST(-0600)] <jessm> roger Roger
[09:54:04 CST(-0600)] <anastasiac> jhung, jessm: james posted an email to the list back on Nov. 3, 2010 titled "Enhancements to/redesign of Fluid Infusion demo pages" that might make good background reading before the meeting
[09:54:21 CST(-0600)] <colinclark> mlam: Your latest FLUID-4033 patch looks good
[09:54:21 CST(-0600)] <jhung> anastasiac: thanks!
[09:54:22 CST(-0600)] <jessm> great
[09:54:23 CST(-0600)] <colinclark> I'll commit it now
[09:54:28 CST(-0600)] <mlam> thanks
[09:59:13 CST(-0600)] <heidi_> anastasiac , colinclark, jessm my notes from the uportal chat are missing details for this issue "The overflow:auto style declaration and fluid containers." - do you guys recall what the specific problem was? i think it was scroll bars in IE, but just checking
[09:59:40 CST(-0600)] * anastasiac digs up notes
[09:59:43 CST(-0600)] <colinclark> That seems about right, heidi_, but honestly I can't remember
[10:00:56 CST(-0600)] <heidi_> i'm going to email matt about fss stuff so i can double check then too
[10:01:17 CST(-0600)] <anastasiac> heidi_, here's what I have in my notes:
[10:01:21 CST(-0600)] <anastasiac> overflow: auto; causes scrollbars on containers
[10:01:21 CST(-0600)] <anastasiac> override, apply to each container
[10:01:21 CST(-0600)] <anastasiac> see positioniseverything.com
[10:01:21 CST(-0600)] <anastasiac> has a script that deals with box model, script was borrowed by jquery, their helper styles use this
[10:01:22 CST(-0600)] <anastasiac> ui-helper-clearfix
[10:01:22 CST(-0600)] <anastasiac> this style encompasses the script
[10:01:54 CST(-0600)] <heidi_> cool thanks anastasiac
[10:11:50 CST(-0600)] <Justin_o> colinclark, mlam: should the uploader be able to upload files that have file names with non-ascii characters
[10:12:21 CST(-0600)] <colinclark> Justin_o: It should be able to, yes. Whether it does or not is entirely another question
[10:12:30 CST(-0600)] <colinclark>
[10:12:39 CST(-0600)] <mlam> I think the files should at least be added to the file queue. I think the rest should depend on the server-side on how it deals with tehse files
[10:18:38 CST(-0600)] <Justin_o> colinclark, mlam: thanks
[10:18:58 CST(-0600)] <mlam> confirmed...non-ascii characters in the file name still get added to the file queue
[10:47:59 CST(-0600)] <colinclark> mlam: A couple of minor questions for you about your 4033 patch
[10:48:09 CST(-0600)] <mlam> sure
[10:48:13 CST(-0600)] <colinclark> Why not call bindEvents() as part of your getLocalUploader() function/
[10:48:14 CST(-0600)] <colinclark> ?
[10:48:31 CST(-0600)] <colinclark> Am I correct in assuming that it's something you need to do each time you instantiate an Uploader?
[10:49:01 CST(-0600)] <mlam> yes, it is. we want to bind events each and every time
[10:49:06 CST(-0600)] <colinclark> okay
[10:49:10 CST(-0600)] <colinclark> i'll tweak that before committing
[10:49:15 CST(-0600)] <mlam> ok, thanks
[11:17:17 CST(-0600)] <colinclark> mlam: The other thing I notice while reviewing your patch is that you're doing something interesting
[11:17:21 CST(-0600)] <colinclark> It's not necessarily a bad thing
[11:17:24 CST(-0600)] <colinclark> but it is interesting
[11:17:47 CST(-0600)] <colinclark> So, we've got this dependency of a local on a FileQueue
[11:17:48 CST(-0600)] <mlam> Ok, what is it?
[11:17:57 CST(-0600)] <colinclark> That'll eventually be fixed up, I think
[11:18:12 CST(-0600)] <colinclark> But interestingly, you don't actually need to be testing the FileQueue's behaviour
[11:18:37 CST(-0600)] <colinclark> So you have that little bindEvents function, where you bind an event that is no doubt erroneously in some code somewhere else, which you "need"
[11:19:11 CST(-0600)] <colinclark> You bind to afterFileQueued and call the queue's addFile() method
[11:19:22 CST(-0600)] <colinclark> But I guess, in the end, we don't really care whether the files were added to the queue
[11:19:49 CST(-0600)] <mlam> Ohh, I see what you mean.
[11:20:20 CST(-0600)] <colinclark> Actually, this points out a bug, I think
[11:20:33 CST(-0600)] <colinclark> So, anyway, you really want to test two things that might happen inside addFiles()
[11:20:46 CST(-0600)] <colinclark> 1. An onQueueError event firing
[11:20:57 CST(-0600)] <colinclark> 2. afterFileQueued firing
[11:21:14 CST(-0600)] <colinclark> The bug that just occurred to me...
[11:21:44 CST(-0600)] <colinclark> So, this code checks to see if we're over any of the various limits
[11:22:00 CST(-0600)] <colinclark> and if we are, we don't fire afterFileQueued, and instead fire onQueueError, which makes sense
[11:22:27 CST(-0600)] <colinclark> However, regardless of the outcome, we fire afterFileDialog with files.length as the only argument to the event
[11:22:40 CST(-0600)] <colinclark> However, in any case where a file was rejected, this number will be incorrect
[11:23:27 CST(-0600)] <colinclark> Since I believe the real purpose of that argument to afterFileDialog is to tell the client how many files were actually added to the queue
[11:23:30 CST(-0600)] <mlam> ah. so the value there should be the queue's length
[11:23:43 CST(-0600)] <colinclark> Well, perhaps not the queue's length
[11:23:55 CST(-0600)] <colinclark> I think perhaps the number of files that were actually added to the queue this time
[11:23:57 CST(-0600)] <colinclark> if you see what I mean
[11:24:31 CST(-0600)] <mlam> so the length of the files successfully added to the queue from the current batch?
[11:26:11 CST(-0600)] <colinclark> Not so much from the current batch as from the current "click of the add more button," if you know what I mean
[11:26:35 CST(-0600)] <colinclark> In other words, this event happens when the file dialog is dismissed and all the necessary work is done
[11:26:49 CST(-0600)] <colinclark> meaning, we want to tell our clients "this is how many files the user just added to the queue"
[11:27:17 CST(-0600)] <colinclark> You could add a few files, dismiss the dialog, then click the Add More button and add a few more, and they'd all be part of the fileQueue's current batch
[11:27:38 CST(-0600)] <mlam> right, i see now.
[11:29:23 CST(-0600)] <mlam> I can file a JIRA for that one and I'll make a patch for it. In terms of the tests themselves? Should I remove all code that tests the adding files to the queue?
[11:34:47 CST(-0600)] <colinclark> mlam: Do you want to try working on the tests together some time today?
[11:35:07 CST(-0600)] <colinclark> So, I think I'd be writing this test so that it tests the events getting fired, rather than your indirect way
[11:35:13 CST(-0600)] <colinclark> where, in many ways, you're actually testing your test
[11:35:31 CST(-0600)] <mlam> sure. Let me know when you're free
[11:36:00 CST(-0600)] <colinclark> ok, let me figure that out
[11:36:22 CST(-0600)] <colinclark> Definitely a good idea to go ahead and file the JIRA about the value we're passing back to afterFileDialog
[11:36:28 CST(-0600)] <Bosmon> Hi mlam: Did you have any luck with asyncForEach?
[11:36:51 CST(-0600)] <mlam> Bosmon: I'm kinda close
[11:36:56 CST(-0600)] <Bosmon> Awesome
[11:37:00 CST(-0600)] <Bosmon> Let me know if I can help out
[11:37:46 CST(-0600)] <mlam> I think my code is a hybrid of the CPS and some standard java recursion
[11:46:42 CST(-0600)] <colinclark> Bosmon: So you're a popular guy today
[11:46:48 CST(-0600)] <colinclark> michelled and yura want to chat with you
[11:46:51 CST(-0600)] <colinclark> I'd like to as well
[11:46:55 CST(-0600)] <colinclark> I need to grab some lunch
[11:47:00 CST(-0600)] <colinclark> Fish does as well
[11:47:08 CST(-0600)] <colinclark> I also need to do a bit of pairing with mlam
[11:47:53 CST(-0600)] <colinclark> So how about michelled and yura get you from 1:30 pm - 2:30 pm EST, and then you and I meet to chat about Node and GPII and so on after that?
[11:48:31 CST(-0600)] <colinclark> mlam: Does that work for you? We code from 1:30 pm - 2:30 pm?
[11:48:42 CST(-0600)] <mlam> ok, sounds good
[11:50:33 CST(-0600)] <Bosmon> ok
[11:50:38 CST(-0600)] <Bosmon> We should probably overlap a bit
[11:50:48 CST(-0600)] <Bosmon> That is, in those meetings
[11:50:57 CST(-0600)] <Bosmon> Since "Trundlers" probably falls a bit into both camps
[12:01:42 CST(-0600)] <jessm> are others able to get to the wiki?
[12:07:01 CST(-0600)] <mlam> nope, not me
[12:37:34 CST(-0600)] <jessm> mlam golam harriswong michelled Justin_o anastasiac ping y'all. i'm wondering if you have done your scoping and if not, can you get to that today?
[12:37:43 CST(-0600)] <jessm> i know some folks are probably scoping in JIRA
[12:38:07 CST(-0600)] <anastasiac> jessm, I added my estimates to my JIRAs
[12:38:09 CST(-0600)] <jessm> just catch me up on where your things are for 1.3.1 – this is in response to Colin's email on Friday "Infusion 1.3.1 Scoping"
[14:03:59 CST(-0600)] <anastasiac> jhung, jessm: are we meeting in breeze now?
[14:04:36 CST(-0600)] <jhung> anastasiac: yup.
[14:04:39 CST(-0600)] <jessm> y
[14:06:53 CST(-0600)] <mlam> jessm: i've updated the estimates for the criticals and blockers.
[14:07:27 CST(-0600)] <jessm> mlam: does that list overlap with Colin's email?
[14:10:03 CST(-0600)] <mlam> they're the same issues from colin's email last week, yes
[14:41:25 CST(-0600)] <Justin_o> jessm: i just put some timings in jira.. i roughly estimated 2 days each for now
[14:41:47 CST(-0600)] <jessm> golam: what about your scoping?
[14:42:30 CST(-0600)] <jessm> harriswong: ?
[14:43:19 CST(-0600)] <golam> jessm: I have finished fixing the bug for FLUID-3946 now I am working on the test case. Hoping to complete it by tomorrow. I will update the jira.
[14:43:49 CST(-0600)] <colinclark> golam: What was the cause of the bug?
[14:44:42 CST(-0600)] <harriswong> jessm: I have not update the scoping yet. I will update the est.
[14:44:51 CST(-0600)] <golam> default tabindex was set to 0 in ModuleLayout.js
[14:45:55 CST(-0600)] <colinclark> hmm
[14:46:05 CST(-0600)] <colinclark> So what did you change it to?
[14:46:08 CST(-0600)] <golam> colinclark: line 135
[14:46:18 CST(-0600)] <golam> colinclark: -1
[14:46:39 CST(-0600)] <colinclark> Okay, so one thing to make sure of...
[14:46:59 CST(-0600)] <colinclark> How will this effect layouts where there are actually tab-focusable elements inside a module?
[14:47:03 CST(-0600)] <colinclark> Like, for example, uPortal
[14:47:21 CST(-0600)] <colinclark> The correct behaviour, I believe, is that modules should only be arrow key focussable
[14:47:30 CST(-0600)] <colinclark> You tab to the container, which automatically focuses the first element
[14:47:40 CST(-0600)] <colinclark> Then if you hit tab again, you move focus back out of the container
[14:47:58 CST(-0600)] <colinclark> the one exception is when there is stuff inside the module that should be tab key focusable
[14:48:16 CST(-0600)] <golam> colinclark: that's the behaviour I get right now.
[14:48:24 CST(-0600)] <colinclark> ok, cool
[14:48:25 CST(-0600)] <harriswong> jessm: updated.
[14:48:37 CST(-0600)] <colinclark> that makes sense, golam. i just wanted to make sure
[14:48:53 CST(-0600)] <golam> colinclark: but I will some testing
[14:49:06 CST(-0600)] <colinclark> thanks
[14:49:20 CST(-0600)] <golam> colinclark: welcome
[14:49:33 CST(-0600)] <Justin_o> golam: you can test with this example http://build.fluidproject.org/infusion/integration-demos/uportal/html/portal.html
[14:49:41 CST(-0600)] <Justin_o> since there are tab focusable elements within the portlets
[14:52:14 CST(-0600)] <jessm> harriswong: thanks!
[15:06:05 CST(-0600)] <golam> jessm: I have updated the jira FLUID-3946 with my estimate.
[15:06:56 CST(-0600)] <jessm> golam: is that the only task you had from colin's email?
[15:07:27 CST(-0600)] <golam> jessm: yes
[15:07:30 CST(-0600)] <jessm> golam: oh, i think it was, yes
[15:07:33 CST(-0600)] <jessm> golam: thanks!
[15:07:44 CST(-0600)] <golam> jessm: welcome