fluid-work IRC Logs-2011-01-14

Owned by Fluid IRC Log Bot
Last updated: Jan 14, 2011Version comment
21 min read

[08:24:32 CST(-0600)] <heidi_> hey colinclark i need to rethink markup... IE doesn't let one style tbody. so i'm guessing that's why it was strange markup in the first place.
[08:25:03 CST(-0600)] <heidi_> not sure how else to group a bunch of rows and still keep the header as part of the table - might have to separate the two again
[08:26:46 CST(-0600)] <colinclark> heidi_: Okay, that's interesting
[08:26:54 CST(-0600)] <colinclark> So what do you think your next step will be?
[08:28:23 CST(-0600)] <heidi_> colinclark i think the data table might have to exist on its own without headers ? and the file/size at the top styled with css. wondering if there's a way to associate file/size with columns with aria maybe... but perhaps that's not even necessary...
[08:28:44 CST(-0600)] <colinclark> You certainly could do that with ARIA, yes
[08:28:54 CST(-0600)] <colinclark> I don't know for sure how well the ATs will handle it, but they should
[08:29:18 CST(-0600)] <heidi_> okay i'll try it. it's too bad IE forces one to compromise good html. sigh
[08:29:23 CST(-0600)] <colinclark> I think it's probably quite necessary to associate headers with each column--what is your opinion?
[08:29:39 CST(-0600)] <heidi_> i'd prefer the association to stay yeah
[08:29:53 CST(-0600)] <colinclark> When you say that IE won't allow you to style a tbody, is it the issue of making the tbody scrollable? Or more than that?
[08:30:03 CST(-0600)] <heidi_> that's the biggest thing yep
[08:30:30 CST(-0600)] <colinclark> The alternative, I guess, would be to use a div-based layout
[08:30:37 CST(-0600)] <colinclark> and we would have two choices:
[08:30:47 CST(-0600)] <colinclark> 1. Argue to ourselves that this is in fact not tabular data
[08:31:02 CST(-0600)] <colinclark> 2. Use ARIA's table roles to make it feel like a table
[08:31:11 CST(-0600)] <colinclark> Is that correct, heidi_?
[08:31:17 CST(-0600)] <heidi_> well, we can make a full table scrollable.
[08:31:33 CST(-0600)] <heidi_> it's just that we can separate out the thead / tbody to make thead fixed and tbody scroll
[08:32:19 CST(-0600)] <heidi_> know what i mean?
[08:32:38 CST(-0600)] <colinclark> yes
[08:32:47 CST(-0600)] <heidi_> so i'm thinking take the header out, and leave the data in a table that scrolls
[08:33:02 CST(-0600)] <colinclark> But another alternative is to just use a div-based layout, right?
[08:33:04 CST(-0600)] <heidi_> but still want to associate "file" with col1 and "size" with col2 somehow
[08:33:14 CST(-0600)] <colinclark> I'm trying to get a sense of the range of options we have
[08:33:19 CST(-0600)] <heidi_> sure, but i think it is tabular data
[08:34:15 CST(-0600)] <colinclark> Right, so that's why I mentioned #2 above
[08:34:50 CST(-0600)] <michelled> Justin_o: I just created a Workshops component in JIRA
[08:35:39 CST(-0600)] <Justin_o> michelled: thanks for all the cleanup help
[08:35:41 CST(-0600)] <heidi_> right... i'm not familiar with aria's table rolls
[08:35:57 CST(-0600)] <heidi_> i'll read up on it - you think it'd be good tho?
[08:36:46 CST(-0600)] <colinclark> heidi_: I'm not sure--I'm not suggesting what to do, I'm just helping outline all the options
[08:36:58 CST(-0600)] <colinclark> ARIA's table roles are like anything else with ARIA
[08:37:13 CST(-0600)] <colinclark> it takes ordinary, generic markup and makes them appear to an AT as something more specific
[08:37:25 CST(-0600)] <colinclark> It's never ideal, since HTML already has some pretty good options for that
[08:37:26 CST(-0600)] <colinclark> b
[08:37:45 CST(-0600)] <colinclark> But so far it seems that either way we're going to have to go at least partially down that road
[08:38:00 CST(-0600)] <colinclark> since a table without associated headers is pretty unworkable
[08:39:02 CST(-0600)] <heidi_> i wonder how much of it IE supports. but i think it's a great suggestion ... i'll read up on aria grid role
[08:39:36 CST(-0600)] <colinclark> heidi_: Have you seen this guy's scrollable tables? http://pics.cssbakery.com/treats/scrollingtable/tableTest6.php
[08:39:37 CST(-0600)] <heidi_> thanks colin
[08:39:55 CST(-0600)] <colinclark> Article about it is here: http://www.cssbakery.com/2010/12/css-scrolling-tables-with-fixed.html
[08:40:15 CST(-0600)] <heidi_> works in IE?
[08:40:47 CST(-0600)] <heidi_> it does
[08:41:05 CST(-0600)] <heidi_> awesome, i'll take a closer look
[08:43:06 CST(-0600)] <colinclark> A lot of people seem to use multiple tables, so I guess that says a lot
[08:45:23 CST(-0600)] <colinclark> heidi_: Here's another implementation http://www.imaputz.com/cssStuff/bulletVersion.html
[08:45:31 CST(-0600)] <colinclark> I have no idea if any of these are any good
[08:46:06 CST(-0600)] <heidi_> colinclark these look promising, i'll check them out - thanks again
[08:47:30 CST(-0600)] <heidi_> looks like he makes the whole table scrollable, but sets thead to be absolutely positioned
[08:50:17 CST(-0600)] <colinclark> I can imagine, heidi_, that a lot of these solutions are pretty brittle
[08:50:40 CST(-0600)] <colinclark> I wonder if we could have the headers duplicated twice...
[08:50:45 CST(-0600)] <colinclark> once in the area above the table, and visible
[08:50:57 CST(-0600)] <colinclark> and again, attached to the table itself, but invisible
[08:51:03 CST(-0600)] <colinclark> i imagine it would be excessively chatty
[08:51:13 CST(-0600)] <heidi_> another option to consider at least
[08:51:18 CST(-0600)] <colinclark> but it would provide an in-built association between headers and columns
[08:53:51 CST(-0600)] <michelled> Justin_o: Quick Start Examples JIRA component is deleted
[08:54:52 CST(-0600)] <Justin_o> michelled: thanks..
[08:55:40 CST(-0600)] <michelled> jessm, jameswy: we have a JIRA component called 'Design Framework'. I think we no longer use this framework. What do you think we should do with the JIRA issues and the component?
[08:56:29 CST(-0600)] <jessm> michelled: do we have to do something with it?
[08:57:02 CST(-0600)] <michelled> we can leave it as it is if you want but I would like to assign a component lead to it
[08:57:17 CST(-0600)] <jessm> michelled: a component lead is a person?
[08:57:23 CST(-0600)] <michelled> yes
[08:57:36 CST(-0600)] <jessm> i nominate myself since/if no one else wants it
[08:57:44 CST(-0600)] <michelled> ok (smile)
[08:57:45 CST(-0600)] <jessm> and i'll be happy to weed through it next week
[10:17:44 CST(-0600)] <colinclark> So mlam, can you explain to me again, from the start, what you think the problem with enabling/disabling the browse button is in Uploader?
[10:17:50 CST(-0600)] <colinclark> You said you thought it had something to do with options merging
[10:17:55 CST(-0600)] <colinclark> but I wasn't clear why
[10:18:33 CST(-0600)] <mlam> colinclark: yura_ has been working through with me last night and this morning. we thought we had a clear understanding of why it's not working, but now we don't.
[10:18:50 CST(-0600)] <colinclark> Can you actually explain what is happening?
[10:18:58 CST(-0600)] <mlam> the fix we had for disabling the browse button while uploading is working in the demo, but it's not working on the server
[10:19:00 CST(-0600)] <mlam> for sure
[10:19:20 CST(-0600)] <mlam> We use options merging for the browse button twice in the html5 uploader
[10:19:50 CST(-0600)] <colinclark> Where?
[10:20:10 CST(-0600)] <mlam> the first being, we pass in the browse button that is already existing in our markup so that we can manipulate it by appending the multi file input elements to it
[10:20:27 CST(-0600)] <mlam> and that works fine.
[10:21:17 CST(-0600)] <mlam> the second being we pass in the browse button AFTER an input element has been appended to the browse button. so the browse button selector has now changed
[10:22:33 CST(-0600)] <colinclark> Can you point me to some line numbers?
[10:22:40 CST(-0600)] <colinclark> When you say "pass in," it's a bit ambiguous
[10:22:58 CST(-0600)] <mlam> sorry, pass in = merge the option
[10:23:40 CST(-0600)] <mlam> i'm just checking out a fresh copy so I can get you appropriate line numbers
[10:24:51 CST(-0600)] <mlam> colinclark: line 36, and line 317 is where we do the options merging for the browse button
[10:25:06 CST(-0600)] <colinclark> so, why do you think options merging has anything to do with it?
[10:25:16 CST(-0600)] <colinclark> Is the button somehow corrupted?
[10:26:33 CST(-0600)] <mlam> I'm not fully sure if options merging is the culprit because I still dont' have a full understanding of the IoC framework.
[10:27:03 CST(-0600)] <mlam> The button isn't corrupted, but the button has changed in that it now has input elements as its children
[10:27:26 CST(-0600)] <colinclark> how should it look?
[10:29:22 CST(-0600)] <colinclark> I seem to have it working
[10:29:37 CST(-0600)] <mlam> The button definitely needs to consist of a list of input elements as its children
[10:29:48 CST(-0600)] <colinclark> let me just revert to make sure this is a real fix
[10:46:04 CST(-0600)] <colinclark> mlam: What's the JIRA ticket for this one?
[10:46:33 CST(-0600)] <heidi_> not sure why my audio didn't work - i'm revising uploader markup to work around IE's inability to style tbody
[10:47:14 CST(-0600)] <mlam> colinclark: FLUID-3999
[10:48:01 CST(-0600)] <colinclark> mlam: I'll slap up a patch and you can give it a try
[10:48:12 CST(-0600)] <colinclark> This was, I think, my own misunderstanding
[10:48:52 CST(-0600)] <colinclark> The documentation is pretty meagre for options merging
[10:48:58 CST(-0600)] <colinclark> Have you read this yet, mlam? http://wiki.fluidproject.org/display/fluid/Options+Merging+for+Fluid+Components
[10:49:12 CST(-0600)] <mlam> cool, thanks colin
[10:49:16 CST(-0600)] <mlam> i'll give it a shot
[10:49:20 CST(-0600)] <colinclark> The key point is here: "The merge policy object is a hash of keys, which represent EL paths into the target object, onto values which represent a policy."
[10:49:34 CST(-0600)] <colinclark> Which implies, but I didn't clearly understand, that these need to be absolute EL paths into the object structure
[10:50:10 CST(-0600)] <mlam> yah, i read over it yesterday, but it wasn't very clear to me
[10:50:21 CST(-0600)] <colinclark> so you can see at lines 55 and 326, we're specifying a "preserve" merge policy for the browseButton, among other things
[10:50:30 CST(-0600)] <colinclark> but we've specified it incorrectly
[10:50:38 CST(-0600)] <colinclark> the path used to be just "browseButton"
[10:50:54 CST(-0600)] <colinclark> Instead, it should look like this:
[10:50:55 CST(-0600)] <colinclark> "components.local.options.events": "preserve"
[10:51:15 CST(-0600)] <colinclark> But this point to what I think is a somewhat larger architectural issue
[10:51:21 CST(-0600)] <colinclark> and not a terrifyingly difficult one to solve
[10:52:03 CST(-0600)] <colinclark> There are TODOs related to the "browse handler" stuff suggesting that it wasn't quite factored right
[10:52:18 CST(-0600)] <colinclark> It strikes me that if we have a thing that needs the browse button, it should probably be a View
[10:52:45 CST(-0600)] <colinclark> and if we need to pass around this "addFilesFn" (which is silly), it suggests that we should actually have a thing that fires an event
[10:53:01 CST(-0600)] <mlam> I see
[10:54:41 CST(-0600)] <colinclark> mlam: Patch posted here: http://issues.fluidproject.org/browse/FLUID-3999
[10:54:46 CST(-0600)] <colinclark> Hopefully I got it right
[10:54:58 CST(-0600)] <mlam> i'll give it a go, thanks!
[11:06:20 CST(-0600)] <mlam> colinclark: did your patch work with the image gallery?
[11:06:28 CST(-0600)] <colinclark> i didn't try it
[11:06:37 CST(-0600)] <colinclark> but i can't imagine that would effect the behaviour--who knows?
[11:07:08 CST(-0600)] <mlam> yeah, it's definitely affecting the image gallery. it's the same as my other solutions. it would work with the demo, but not with the image gallery.
[11:07:19 CST(-0600)] <colinclark> okay, so the question is, why?
[11:07:22 CST(-0600)] <colinclark> what's different between the two?
[11:07:49 CST(-0600)] <mlam> i'm trying to get an error message to pop up, but nothing. visually, no files are added to the file queue
[11:15:29 CST(-0600)] <harris> colinclark: I am working FLUID-3878 with the exception handlers. Should I go ahead to implement jameswy's new markup? Or should I wait for the renderer to get implemented into the uploader?
[11:16:41 CST(-0600)] <mlam> colinclark: there's a small typo in the paths of the merge policy for the browse handler....so it's working again. however, the browse button isn't disabled on the image gallery
[11:16:52 CST(-0600)] <colinclark> ah, interesting
[11:16:57 CST(-0600)] <colinclark> what was the typo?
[11:17:30 CST(-0600)] <mlam> instead of components.browsehandler.options., it was components.local.options.
[11:17:37 CST(-0600)] <colinclark> on which line?
[11:17:46 CST(-0600)] <mlam> 326, 327
[11:18:10 CST(-0600)] <colinclark> Are you sure that is the case, mlam?
[11:18:36 CST(-0600)] <mlam> Changing those paths allowed the uploader to add files to the file queue again
[11:19:05 CST(-0600)] <colinclark> That doesn't quite make sense, mlam
[11:19:16 CST(-0600)] <colinclark> You're saying that you couldn't add files to the queue?
[11:19:25 CST(-0600)] <colinclark> I can't reproduce that
[11:19:34 CST(-0600)] <mlam> yes, for the image gallery
[11:19:34 CST(-0600)] <colinclark> So, can you explain your change to me?
[11:19:41 CST(-0600)] <colinclark> In other words, what does it actually mean?
[11:20:53 CST(-0600)] <mlam> hmm..my understanding is that the merge policy paths should reflect the hierarchy of the options block defined in the defaults function
[11:21:04 CST(-0600)] <colinclark> okay
[11:21:11 CST(-0600)] <mlam> is my understanding wrong?
[11:21:21 CST(-0600)] <colinclark> so, at line 327, what's the path we are trying to preserve?
[11:21:57 CST(-0600)] <colinclark> Is it not the option just above us on line 319?
[11:22:27 CST(-0600)] <mlam> we are trying to preserve the browsebutton within the browseHandler component, not local ?
[11:22:31 CST(-0600)] <colinclark> yes
[11:22:38 CST(-0600)] <colinclark> so, did I give you the wrong patch?
[11:22:41 CST(-0600)] <colinclark> i'm totally confused
[11:22:45 CST(-0600)] <colinclark> I must have
[11:22:57 CST(-0600)] <colinclark> you're entirely correct
[11:23:35 CST(-0600)] <mlam> sigh..... colinclark, you're right...you gave me the correct patch.
[11:23:48 CST(-0600)] <colinclark> what happened?
[11:24:13 CST(-0600)] <mlam> i'm looking at some path changes i made in a different project
[11:24:21 CST(-0600)] <mlam> sorry, my mistake.
[11:24:26 CST(-0600)] <colinclark> ahhhh
[11:24:27 CST(-0600)] <colinclark> (smile)
[11:24:37 CST(-0600)] <colinclark> cool, so now we're on the same page
[11:24:37 CST(-0600)] <colinclark> the
[11:24:38 CST(-0600)] <mlam> ack.
[11:24:41 CST(-0600)] <mlam> yes
[11:24:48 CST(-0600)] <colinclark> question remains, why is the Gallery different from standalone
[11:24:55 CST(-0600)] <colinclark> let me think about it for a minute
[11:25:14 CST(-0600)] <colinclark> and maybe quit some apps so I can stop beachballing
[11:28:50 CST(-0600)] <colinclark> So the local object is shared between both the demo version of Uploader and the one running in the Image Gallery
[11:28:56 CST(-0600)] <Bosmon> colinclark, mlam: I find this all very seriously wierd
[11:29:06 CST(-0600)] <Bosmon> I guess colinclark just observed that the mergePolicy written there is ineffective anyway
[11:29:17 CST(-0600)] <Bosmon> Since it uses relative rather than absolute paths
[11:29:24 CST(-0600)] <Bosmon> But I am wondering why it was written there at all
[11:29:33 CST(-0600)] <colinclark> Bosmon: Let's leave that for later
[11:29:37 CST(-0600)] <colinclark> We've already covered that before you arrived
[11:36:02 CST(-0600)] <colinclark> mlam: I'm not sure it's even worth debugging it
[11:36:09 CST(-0600)] <colinclark> It's easier to just fix the structural problems
[11:36:31 CST(-0600)] <colinclark> Go ahead and move on to something else, I'll just refactor it
[11:39:33 CST(-0600)] <mlam> ok
[11:46:39 CST(-0600)] <heidi_> colinclark that first ex you sent me is working - just trying to make it look pretty ..yay
[11:46:46 CST(-0600)] <colinclark> cool
[12:16:58 CST(-0600)] <mlam> Bosmon, colinclark: is there a function in the framework that is the complete opposite of fluid.activatable? ie. deactivate keyboard handlers. if not, should we?
[12:17:11 CST(-0600)] <colinclark> mlam: Not that I know of
[12:17:32 CST(-0600)] <colinclark> The "should we?" question is an interesting one
[12:19:14 CST(-0600)] <colinclark> So, I double-checked and there is no way to deactivate keyboard handlers
[12:19:25 CST(-0600)] <colinclark> What problem are you trying to solve?
[12:19:26 CST(-0600)] <mlam> It makes sense that we don't have one because if we wanted to add a keyboard handler, we'd want it to stick around. However, in cases where we currently use the fluid.activatable function, and we actually do want to unbind the keyboard events, then we'd have a decision to make. i guess to either include a deactivate function, or refactor the code to not use the activatable?
[12:19:55 CST(-0600)] <colinclark> I guess we've never really encountered a compelling case where deactivation was actually necessary
[12:20:04 CST(-0600)] <mlam> colinclark: deactivating the keyboard handler for the delete button for the file queue
[12:20:15 CST(-0600)] <colinclark> In cases where the DOM element is removed (like say, when a file row is deleted from the queue), there's no need to deactivate it
[12:20:25 CST(-0600)] <colinclark> it's gone, we'll trust that GC will do the rest
[12:20:53 CST(-0600)] <mlam> what if we didn't want the file row to be deleted at all?
[12:21:10 CST(-0600)] <colinclark> So, just so I'm clear, when you say "deactivating the keyboard handler for the delete button for the file row," you're talking about temporarily disabling that button, right?
[12:21:16 CST(-0600)] <mlam> yes
[12:21:28 CST(-0600)] <colinclark> I think we chatted about this after basketball, maybe
[12:21:39 CST(-0600)] <mlam> haha yah, we did
[12:21:47 CST(-0600)] <colinclark> It strikes me that "deactivating," if we think of it as "unbinding all the listeners" is a pretty expensive operation
[12:21:56 CST(-0600)] <colinclark> since we know we'll just go and rebind them all again a bit later
[12:22:10 CST(-0600)] <colinclark> So, there are two solutions, which are really just one solution in two different forms, I think
[12:22:50 CST(-0600)] <colinclark> 1. We could think about adding a method that is the reverse of calling activatable()
[12:23:00 CST(-0600)] <colinclark> I'm not quite sure what we'd call it, but that's another story
[12:23:15 CST(-0600)] <colinclark> And I guess it would just set a flag and not fire the activation handler if it's been set
[12:23:32 CST(-0600)] <colinclark> 2. We could simply extend our current activation handler to handle this case for us
[12:23:48 CST(-0600)] <colinclark> So, what's the case where we don't want these delete buttons to be activatable?
[12:24:39 CST(-0600)] <mlam> we just want the delete buttons disabled while we're uploading
[12:25:24 CST(-0600)] <colinclark> ok, so we've got model state for this, right?
[12:25:27 CST(-0600)] <colinclark> I forget exactly where
[12:25:37 CST(-0600)] <mlam> Yah, we have a state in the file queue
[12:26:43 CST(-0600)] <mlam> hopefully!
[12:26:45 CST(-0600)] <colinclark> So, the easiest solution is this:
[12:27:12 CST(-0600)] <colinclark> In the our activatable handler, check the file queue's state before invoking the remove behaviour
[12:27:43 CST(-0600)] <colinclark> Line 135 of FileQueueView has the handler we register to activatable()
[12:27:53 CST(-0600)] <colinclark> And you can see that all it does is call removeFileForRow()
[12:28:01 CST(-0600)] <colinclark> Which is a good thing to do if we want to support deletion
[12:28:07 CST(-0600)] <colinclark> not so hot if we're in the midst of uploading
[12:28:48 CST(-0600)] <mlam> ahhh i c
[12:28:49 CST(-0600)] <mlam> right
[12:29:58 CST(-0600)] <colinclark> Bosmon: Do you have any thoughts on mlam's idea of adding a method that explicitly makes something no longer activatable?
[12:30:15 CST(-0600)] <colinclark> I guess, to do it sensibly, we'd have to unbind all relevant event handlers
[12:30:20 CST(-0600)] <colinclark> which really isn't even necessary in this case
[12:33:29 CST(-0600)] <colinclark> mlam: I think I have a patch for you for FLUID-3999
[12:33:37 CST(-0600)] <colinclark> it's much, much tidier
[12:33:48 CST(-0600)] <colinclark> but I do one sort of insane thing, which I could use some advice on at some point
[12:33:56 CST(-0600)] <colinclark> harris: I realized I never answered your earlier question
[12:34:10 CST(-0600)] <Bosmon> "no longer activatable" - is that different to "disabled"?
[12:34:24 CST(-0600)] <colinclark> I guess there's two potential use cases
[12:34:27 CST(-0600)] <colinclark> 1. Disabled
[12:34:36 CST(-0600)] <colinclark> 2. Just not activatable anymore at all
[12:34:42 CST(-0600)] <colinclark> #2, I think, is not worth considering
[12:34:58 CST(-0600)] <mlam> colinclark: cool, i'll test the patch out
[12:35:09 CST(-0600)] <colinclark> But yes, what mlam was looking for was some way to "disable" an element from the perspective of the keyboard plugin
[12:37:16 CST(-0600)] <Bosmon> Yes, we have such a feature
[12:37:20 CST(-0600)] <colinclark> we do?
[12:37:23 CST(-0600)] <Bosmon> Yes
[12:37:33 CST(-0600)] <colinclark> What is it?
[12:37:40 CST(-0600)] <Bosmon> fluid.enabled
[12:37:46 CST(-0600)] <colinclark> hmm
[12:37:51 CST(-0600)] <Bosmon> I believe it might have been invented even for this specific purpose (tongue)
[12:37:55 CST(-0600)] <Bosmon> That is, the Uploader...
[12:38:01 CST(-0600)] <Bosmon> It was implemented back in the Eli days
[12:38:07 CST(-0600)] <colinclark> ah, i see this
[12:38:09 CST(-0600)] <Bosmon> It is somewhat raw, but it should still work
[12:38:48 CST(-0600)] <colinclark> mlam: Even easier!
[12:38:54 CST(-0600)] <colinclark> We do indeed have exactly what you want
[12:39:24 CST(-0600)] <colinclark> should be able to call fluid.enabled(row, false) on each of the file rows
[12:39:58 CST(-0600)] <colinclark> If you look at line 549 of the keyboard-a11y.js file, you'll see that we already check for this before responding to an activation handler
[12:40:16 CST(-0600)] <colinclark> Does that seem like about what you were looking for, mlam?
[12:41:17 CST(-0600)] <mlam> interesting. so if i pass a false boolean value into the fluid.enabled function for a specific row, then the keyboard handler shouldn't work
[12:41:27 CST(-0600)] <colinclark> that's the idea, I believe
[12:41:34 CST(-0600)] <colinclark> I wonder if the keyboard-a11y documentation describes this
[12:41:40 CST(-0600)] <colinclark> anastasiac: Do you know, by chance?
[12:41:46 CST(-0600)] <colinclark> it's clearly a useful feature (smile)
[12:42:16 CST(-0600)] <colinclark> harris: I never did answer your question
[12:42:26 CST(-0600)] <colinclark> How far along in rendering error messages are you now?
[12:42:41 CST(-0600)] <colinclark> I think the Renderizing is a dependency, in that if it was already done, it would make your work much easier
[12:42:43 CST(-0600)] <colinclark> and I do plan to do it
[12:42:50 CST(-0600)] <colinclark> but I don't think it's worth holding things up
[12:42:53 CST(-0600)] <anastasiac> colinclark, mlam, I don't believe the keyboard-a11y docs mention this. I'll double-check, but it's now on my list of things to add
[12:43:14 CST(-0600)] <colinclark> so if you're willing to have to rewrite your code, you could probably go ahead and get things running as a "prototype", harris
[12:43:20 CST(-0600)] <colinclark> cool, anastasiac
[12:43:58 CST(-0600)] <mlam> i'm glad there's a feature to counter the activatable. thanks colinclark! thanks Bosmon!
[12:44:18 CST(-0600)] <colinclark> mlam: On another subject...
[12:44:28 CST(-0600)] <colinclark> I'm now suspecting Evil as the culprit for the Image Gallery
[12:44:35 CST(-0600)] <mlam> (sad)
[12:44:56 CST(-0600)] <mlam> what is the image gallery doing? or should i say, not doing?
[12:45:05 CST(-0600)] <colinclark> (smile)
[12:45:09 CST(-0600)] <colinclark> It's not disabling that button
[12:45:23 CST(-0600)] <colinclark> even though the code is just so much simpler that it's pretty clearly working
[12:45:33 CST(-0600)] <colinclark> I'm beginning to suspect, say, more Maven evilness
[12:45:37 CST(-0600)] <colinclark> But I'll take a look
[12:45:53 CST(-0600)] <harris> colinclark: okay. thanks.
[12:46:24 CST(-0600)] <Bosmon> Maven?!
[12:47:15 CST(-0600)] <colinclark> Well, it's certainly serving up to date code
[12:47:56 CST(-0600)] <harris> colinclark: i am working on the array and function calls in the UPloader.js. I figured i shouldn't work on any markups yet. So far, i am storing the client error messages in 2 arrays/hashmaps, and trying to get them to show up in a temp box beneath the upload button.
[12:48:00 CST(-0600)] <Bosmon> Wow... how impressive to have a man visiting us from the continent of Eye Pee Vee Six (tongue)
[12:48:12 CST(-0600)] <harris> colinclark: then when that's done, i will work on the markup which reflect jameswy's suggestions
[12:48:39 CST(-0600)] <colinclark> Can you elaborate a bit, harris?
[12:48:44 CST(-0600)] <colinclark> or pastebin some code?
[12:53:08 CST(-0600)] <colinclark> Hey mlam, I think I see a bug in how we're filtering based on file type
[12:53:16 CST(-0600)] <harris> colinclark: http://pastebin.com/JgP0hJEf
[12:53:46 CST(-0600)] <harris> colinclark: i didn't copy and paste the entire files, some small flags and variables are left out; but this has the 3 functions that i added/modified
[12:54:02 CST(-0600)] <colinclark> mlam: I'm inspecting one of the multifile input elements
[12:54:03 CST(-0600)] <mlam> in the html5 version?
[12:54:06 CST(-0600)] <colinclark> yep
[12:54:18 CST(-0600)] <colinclark> and they all have an "accept" attribute that looks like this:
[12:54:21 CST(-0600)] <colinclark> ".gif,.jpeg,.jpg,.png,.tiff,.tif"
[12:54:21 CST(-0600)] <mlam> is the syntax for the accept attribute incorrect?
[12:54:33 CST(-0600)] <colinclark> But if I remember correctly, the spec expects a set of MIME types
[12:55:11 CST(-0600)] <harris> colinclark: in the Uploader.js file. What i did is I added a listener to handle Errors fired back from the HTML5 js. If there is any errors, store it in an array, and the updateStateAfterFileDialog event will update the summary.
[12:55:21 CST(-0600)] <colinclark> yes, the spec says it expects "A set of comma-separated strings, each of which is a valid MIME type, with no parameters."
[12:55:30 CST(-0600)] <colinclark> harris: I'll take a look in a sec
[12:55:32 CST(-0600)] <colinclark> thanks, dude
[12:59:09 CST(-0600)] <mlam> i did some work to change the format of the file types for the html5, since the format is different than the swf. I'll file it and make the fix
[13:01:27 CST(-0600)] <colinclark> So, harris, a couple of things strike me
[13:03:59 CST(-0600)] <harris> colinclark: i am going to go grab some lunch.
[13:04:06 CST(-0600)] <colinclark> ok
[13:04:07 CST(-0600)] <colinclark> I s
[13:04:07 CST(-0600)] <colinclark> hould
[13:04:08 CST(-0600)] <colinclark> do
[13:04:09 CST(-0600)] <colinclark> the same
[13:04:15 CST(-0600)] <colinclark> we can chat afterwards
[14:34:06 CST(-0600)] <colinclark> anastasiac: Where'd we ever get to with the uPortal build?
[14:38:20 CST(-0600)] <anastasiac> ah, shoot. not very far. I had some back and forth with jen, sharing logs, stack traces, etc, and we couldn't figure out what was wrong. She pinged eric for help - no response yet
[14:38:52 CST(-0600)] <athena> yeah, i'm not sure what's going on
[14:39:01 CST(-0600)] <athena> EricDalquist: you ever get a chance to look at that stack trace?
[14:39:06 CST(-0600)] <athena> i can't reproduce it
[14:39:32 CST(-0600)] <colinclark> One wonders if we shouldn't just toss this build and start again from more modern infrastructure on our new build server
[14:39:51 CST(-0600)] <anastasiac> that might be a good idea
[14:40:24 CST(-0600)] <anastasiac> colinclark, what's the eta on the new build server?
[14:40:30 CST(-0600)] <athena> have you guys updated your build environment?
[14:40:35 CST(-0600)] <colinclark> There is no ETA. It's up and running, anastasiac
[14:40:39 CST(-0600)] <anastasiac> ah
[14:41:36 CST(-0600)] <anastasiac> athena, can you expand on your question a bit? not sure what you mean
[14:42:07 CST(-0600)] <athena> oh, was just curious as to what the new build server was
[14:42:11 CST(-0600)] <athena> not actually important (smile)
[14:42:22 CST(-0600)] <anastasiac> ah, right
[14:44:19 CST(-0600)] <colinclark> athena: We have two build servers at the moment
[14:44:24 CST(-0600)] <colinclark> An old, crusty one
[14:44:38 CST(-0600)] <colinclark> filled with the sort of cut and pasted shell scripts that would make anyone shudder
[14:44:45 CST(-0600)] <colinclark> running an old version of continuum
[14:44:59 CST(-0600)] <colinclark> We have a separate, dedicated VM set aside for a new build server
[14:45:17 CST(-0600)] <colinclark> It currently only builds the Builder daily
[14:45:30 CST(-0600)] <athena> anastasiac: might be worth taking a look at the build script for uportal if you're able to share it
[14:46:07 CST(-0600)] <anastasiac> athena, sure. It's actually a collection of scripts, but I can pass them along via email
[14:46:38 CST(-0600)] <athena> that'd be great
[14:51:13 CST(-0600)] <colinclark> anastasiac: Shouldn't they be in SVN?
[14:51:26 CST(-0600)] <anastasiac> yes, they should
[14:51:30 CST(-0600)] <anastasiac> I'm just checking where
[14:51:57 CST(-0600)] <anastasiac> and whether or not svn is up-to-date
[14:56:09 CST(-0600)] <anastasiac> and indeed they were not. there were local changes uncommitted. I've committed them
[14:56:25 CST(-0600)] <anastasiac> athena, our uportal build scripts can be found at http://source.fluidproject.org/svn/fluid/infrastructure/build-scripts/uportal/
[14:56:33 CST(-0600)] <athena> makes sense (smile)
[14:56:37 CST(-0600)] <anastasiac> the main one is stop_deploy_resetdb_start.sh - it uses the others
[15:05:41 CST(-0600)] <mlam> heidi_: did you post your patch for using the jquery scroller?
[15:05:50 CST(-0600)] <harris> colinclark, mlam: I have just sent an update (with a patch) regarding to the uploader error handling progress
[15:05:52 CST(-0600)] <athena> anastasiac: what's the build.properties file look like?
[15:06:01 CST(-0600)] <colinclark> can you attach your patch to the JIRA, harris?
[15:06:06 CST(-0600)] <colinclark> if you haven't already
[15:06:10 CST(-0600)] <colinclark> thanks for sending it along
[15:06:13 CST(-0600)] <heidi_> mlam yep but i'll put the most recent one up at the end of the day - i had to change the markup for IE so now going over scroller
[15:06:13 CST(-0600)] <harris> colinclark: will do. It is not completed yet though.
[15:06:19 CST(-0600)] <colinclark> that's okay
[15:06:23 CST(-0600)] <colinclark> just give it a prefix
[15:06:30 CST(-0600)] <colinclark> like JIRA-xyz-a.patch
[15:06:31 CST(-0600)] <colinclark> or whatever
[15:06:38 CST(-0600)] <mlam> heidi_: it's working well ?
[15:06:46 CST(-0600)] <heidi_> the markup is now
[15:06:51 CST(-0600)] <harris> ok
[15:06:57 CST(-0600)] <mlam> the scrollTo plugin is working well too?
[15:07:12 CST(-0600)] <heidi_> just testing it now
[15:07:30 CST(-0600)] <heidi_> but yeah it was working well, so i think it'll be fine
[15:08:01 CST(-0600)] <mlam> ok, cool. i'm getting a weird scroller issue for a JIRA that i'm working on. hopefully what you're working on will take care of that for me (smile)
[15:08:15 CST(-0600)] <heidi_> mlam ah what's the jira?
[15:08:53 CST(-0600)] <mlam> FLUID-3699. it's not related at all, but if we remove the use of the scroller component, then i don't have to worry about it
[15:08:56 CST(-0600)] <harris> colinclark: added to FLUID#3878.
[15:11:18 CST(-0600)] <harris> I am going to head off early today. Will be checking some emails tonight. Have a great weekend everyone!!
[15:14:17 CST(-0600)] <colinclark> someone is ghost committing as me (tongue)
[15:14:24 CST(-0600)] <colinclark> creepy
[15:21:24 CST(-0600)] <anastasiac> athena, your suggestion to turn on 'removeExisting' doesn't seem to have helped (sad)
[15:21:36 CST(-0600)] <athena> (sad)
[15:21:43 CST(-0600)] <athena> same errors?
[15:22:17 CST(-0600)] <athena> looks like
[15:22:19 CST(-0600)] <athena> hmm.
[15:22:58 CST(-0600)] <anastasiac> yes
[15:24:09 CST(-0600)] <athena> build really looks ok, too
[15:25:19 CST(-0600)] <athena> the errors really sort of look like some kind of database inconsistency
[15:25:42 CST(-0600)] <anastasiac> ywah
[15:25:47 CST(-0600)] <anastasiac> yeah
[15:26:32 CST(-0600)] <athena> AH
[15:26:38 CST(-0600)] <athena> ok, i think i finally found something
[15:26:52 CST(-0600)] <athena> [java] create table STATS_SESSION_GROUPS (SESSION_ID bigint not null, GROUPID varchar(255) not null, primary key (SESSION_ID, GROUPID))
[15:26:53 CST(-0600)] <athena> [java] alter table STATS_CHANNEL add constraint FKC6868D231DEA859F foreign key (EVENT_ID) references STATS_EVENT
[15:26:53 CST(-0600)] <athena> [java] alter table STATS_CHANNEL add constraint FKC6868D23BB288331 foreign key (EVENT_ID) references STATS_EVENT
[15:26:53 CST(-0600)] <athena> [java] ERROR Unsuccessful: alter table STATS_CHANNEL add constraint FKC6868D23BB288331 foreign key (EVENT_ID) references STATS_EVENT
[15:27:01 CST(-0600)] <athena> bunch of errors around altering a few of those tables
[15:28:15 CST(-0600)] <athena> though those tables don't seem terribly related to the errors
[15:29:16 CST(-0600)] <anastasiac> so is it possibly some corruption in the STATS_CHANNEL table?
[15:29:23 CST(-0600)] <athena> maybe - seems unrelated
[15:29:34 CST(-0600)] <athena> but wonder if a new from-scratch database would help
[15:29:50 CST(-0600)] <athena> i'm assuming there probably isn't anything important in the current db?
[15:30:57 CST(-0600)] <anastasiac> I was wondering the same thing. I don't think there's anything important in the current db... I'll double-check that, but I'm pretty sure that a clean slate should be fine
[15:33:58 CST(-0600)] <anastasiac> there's an ant target to drop the database and build a new one, right athena? is that 'initdb'?
[15:34:24 CST(-0600)] <athena> well, initdb drops the tables and recreates them
[15:34:32 CST(-0600)] <athena> we don't actually have a command to drop the database itself
[15:34:46 CST(-0600)] <anastasiac> but dropping the table should be enough,no?
[15:36:23 CST(-0600)] <athena> it should be, although it looks from the logs that there are some constraints that aren't being dropped
[15:36:40 CST(-0600)] <athena> you wouldn't think that would be much of an issue since the rest of all the table creation stuff is running correctly
[15:36:51 CST(-0600)] <anastasiac> ugh. that means dropping the table manually... hm...
[15:36:52 CST(-0600)] <athena> but i'm at a loss to explain why it's not working right now
[15:37:13 CST(-0600)] <anastasiac> s/table/database/
[15:37:25 CST(-0600)] <athena> if it's file-based, you might be able to just delete it
[15:37:51 CST(-0600)] <athena> when i use HSQL i usually just use uportal's "ant hsql" task, which starts up a database, creating it if necessary
[15:38:41 CST(-0600)] <anastasiac> my hsql is weak - how can you tell if it's file-base? what would I delete?
[15:39:22 CST(-0600)] <athena> from your scripts it looks like it is - is there a directory in the root of uportal's source directory called "data"?
[15:39:29 CST(-0600)] <anastasiac> yes
[15:39:31 CST(-0600)] <anastasiac> indeed
[15:39:45 CST(-0600)] <athena> actually from the scripts, maybe "hsql-data"
[15:39:59 CST(-0600)] <athena> ah ok, perfect
[15:40:08 CST(-0600)] <athena> so when i want to blow away the hsql db, i just delete that
[15:40:44 CST(-0600)] <athena> interesting - looks like the hsql task is being run w/ ant 1.6 - sorta surprised that works
[15:41:16 CST(-0600)] <athena> anyway, yeah, i'd just delete that
[15:41:51 CST(-0600)] <anastasiac> oh, that's a bug, it should use the environment variable...