fluid-work IRC Logs-2011-01-12

[09:30:31 CST(-0600)] <Justin_o> jessm, colinclark, fluid-everyone: i'm going to look into creating a github account wondering what people think i should name it... "fluid" is taken... the person who has it doesn't have any public repos though so i'm not sure if we can see if we can get it or not
[09:31:21 CST(-0600)] <jessm> Justin_o: what about Fluid Project
[09:31:24 CST(-0600)] <jessm> or fluidproject
[09:31:27 CST(-0600)] <jessm> or fluid_project
[09:31:32 CST(-0600)] <jessm> not sure of the naming convention
[09:32:40 CST(-0600)] <jhung> justin_o why not follow our naming convention? fl-project-git?
[09:33:06 CST(-0600)] <Justin_o> the naming convention is alphanumeric characters or a dash, but not starting with a dash
[09:33:38 CST(-0600)] <jhung> heads-down camel case?
[09:33:53 CST(-0600)] <Justin_o> fluidProject?
[09:34:14 CST(-0600)] <jhung> yeah. I think many of us are used to naming things that way. Easier to remember perhaps?
[09:34:25 CST(-0600)] <anastasiac> +1 for fluidProject or fluid-project
[09:35:21 CST(-0600)] <Justin_o> fluidProject and fluid-project are both available
[09:36:24 CST(-0600)] <colinclark> fluidproject or fluid-project are my preferences, randomly
[09:36:51 CST(-0600)] <jessm> fluidproject or fluid-project +1
[09:38:29 CST(-0600)] <Justin_o> okay.. i guess i would lean towards fluid-project for readability
[09:38:41 CST(-0600)] <Justin_o> any last comments?
[09:39:51 CST(-0600)] <colinclark> fluidproject is one character shorter
[09:40:27 CST(-0600)] <colinclark> jQuery UI uses a dash
[09:41:15 CST(-0600)] <colinclark> those are my last comments
[09:41:20 CST(-0600)] <Justin_o> colinclark: thanks
[09:41:20 CST(-0600)] <Justin_o> {color}
[09:41:38 CST(-0600)] <Justin_o> anyone want to have a final vote for either fluidproject or fluid-project
[09:41:45 CST(-0600)] <Justin_o> I'm +1 for fluid-project
[09:42:19 CST(-0600)] <Justin_o> fluid-everyone: ^
[09:42:31 CST(-0600)] <colinclark> Are there any limits no the number of repositories for organizations, Justin_o?
[09:42:57 CST(-0600)] <Justin_o> colinclark: no limit to the number of repos but the size is limited to 0.30GB we'll have to contact them about increasing that limit
[09:43:09 CST(-0600)] <Justin_o> colinclark: were thinking of doing a IDRC git account?
[09:43:29 CST(-0600)] <colinclark> I don't see any immediate reason to do so
[09:44:04 CST(-0600)] <colinclark> I was just trying to think about this from the perspective of our new, more "project-oriented" branding
[09:44:23 CST(-0600)] <colinclark> if you look at the new Fluid site, for example, we've started to highlight the projects we participate in and lead
[09:44:28 CST(-0600)] <Justin_o> colinclark: okay... meaning a different account for each project?
[09:44:37 CST(-0600)] <colinclark> Thinking aloud about it, yes
[09:44:43 CST(-0600)] <colinclark> So, we'd have an Infusion account
[09:44:52 CST(-0600)] <colinclark> allowing us to better use the size limits
[09:45:36 CST(-0600)] <Justin_o> would it be confusing about the overlap.. so a bunch of infusion i guess is also part of floe
[09:45:41 CST(-0600)] <Justin_o> for example
[09:45:50 CST(-0600)] <colinclark> yes, you're right
[09:46:22 CST(-0600)] <colinclark> But I guess the overlap isn't terribly confusion
[09:46:24 CST(-0600)] <colinclark> confusing
[09:46:41 CST(-0600)] <colinclark> in that, "things that should go into Infusion go into Infusion"
[09:46:44 CST(-0600)] <colinclark> if you know what I mean
[09:46:44 CST(-0600)] <colinclark>
[09:47:07 CST(-0600)] <Justin_o> i think so..
[09:47:18 CST(-0600)] <Justin_o> if you look at github.com/jquery
[09:47:30 CST(-0600)] <colinclark> This approach would start to draw a slightly awkward (or advantageous, depending on how you look at it) 1:1 relationship between projects and repositories
[09:47:37 CST(-0600)] <Justin_o> you can see that jquery keeps all it's sub-projects under the single jquery account
[09:47:44 CST(-0600)] <colinclark> right
[09:47:49 CST(-0600)] <colinclark> although jquery-ui is a separate one, no?
[09:48:00 CST(-0600)] <Justin_o> i don't think so
[09:48:12 CST(-0600)] <colinclark> ah, no
[09:48:13 CST(-0600)] <Justin_o> it's at github.com/jquery/jquery-ui
[09:48:14 CST(-0600)] <colinclark> you're right
[09:48:37 CST(-0600)] <colinclark> I wonder if jQuery ends up paying for a larger organizational account
[09:49:03 CST(-0600)] <Justin_o> i'm not sure.. jamon cloned jquery-ui it was only 25 mb
[09:49:19 CST(-0600)] <Justin_o> so they may actually be under the limit
[09:49:38 CST(-0600)] <colinclark> if we do some pruning to remove our unfortunate binary history, we should be fine
[09:49:48 CST(-0600)] <colinclark> okay, let's go ahead with fluid-project for now, then
[09:49:52 CST(-0600)] <Justin_o> colinclark: jamon also found a page the other day that said we could contact them about getting more space...
[09:49:59 CST(-0600)] <colinclark> cool
[09:51:36 CST(-0600)] <Justin_o> colinclark: okay... i'll do that... i guess i'll try to contact git-hub about getting more space too... in case our pruning doesn't get us down far enough in all our repos.. although i figure we only need to migrate infusion and engage.. we should think about what we want to do with the scratchpad and inucbator as they seem unecessary with git
[09:52:07 CST(-0600)] <colinclark> hmm
[09:52:12 CST(-0600)] <colinclark> How are they unnecessary?
[09:52:23 CST(-0600)] <colinclark> I can imagine their role might change
[09:52:58 CST(-0600)] <Justin_o> colinclark: people could just setup their own repo for those things
[09:53:05 CST(-0600)] <colinclark> they could, yes
[09:53:28 CST(-0600)] <colinclark> I can imagine that we might still want a master repository for some incubated things, arguably even scratchapd-y code
[09:53:41 CST(-0600)] <colinclark> otherwise it's hard to relate things back to the project as a community
[09:53:57 CST(-0600)] <colinclark> whereas if you've got a master repo and people fork away and so on, you can see all the connections
[09:54:07 CST(-0600)] <Justin_o> could be, but would those just be branches
[09:54:23 CST(-0600)] <colinclark> hmm
[09:54:25 CST(-0600)] <colinclark> In many cases
[09:54:31 CST(-0600)] <colinclark> what if we imagined a whole new feature?
[09:54:43 CST(-0600)] <colinclark> Perhaps, for example, a preferences server or FF extension for FLOE?
[09:55:09 CST(-0600)] <colinclark> Perhaps the argument is that the incubator really will get split up into more atomic chunks
[09:55:23 CST(-0600)] <colinclark> so, we'd have a new master repo specifically for that preferences server or whatever
[09:55:24 CST(-0600)] <Justin_o> yes... that's what i was thinking.. they would be completely new repos
[09:55:32 CST(-0600)] <colinclark> rather than a big thing called the "incubator"
[09:55:35 CST(-0600)] <Justin_o> yes
[09:55:43 CST(-0600)] <colinclark> ok, i can dig that
[09:55:56 CST(-0600)] <colinclark> I guess this is going to stretch our typical code review processes a bit
[09:56:12 CST(-0600)] <Justin_o> maybe, i'm not sure about that
[09:56:17 CST(-0600)] <colinclark> ensuring that even though contributors can fork and maintain their own repositories, that they check back in early and often for review
[09:56:25 CST(-0600)] <colinclark> patches tend to be awkward enough to encourage that
[09:56:33 CST(-0600)] <colinclark> but it's fully analogous to a branch
[09:56:42 CST(-0600)] <colinclark> you can do as little or as much as you want
[09:56:55 CST(-0600)] <Justin_o> colinclark: yep... and people could still do patches if they prefer
[09:57:34 CST(-0600)] <Justin_o> i guess what you're saying is that someone might come back for review with a giant sum of code changes... instead of more incrementally
[09:57:39 CST(-0600)] <colinclark> yep
[09:57:46 CST(-0600)] <colinclark> No Giant Lumps Of Code
[09:57:56 CST(-0600)] <Justin_o>
[09:58:15 CST(-0600)] <Justin_o> i think github has a built in code review feature, but not sure how it works
[09:58:21 CST(-0600)] <colinclark> yes, we'll have to leran
[09:58:24 CST(-0600)] <colinclark> learn
[09:58:50 CST(-0600)] <Justin_o> yep... all part of the process
[09:59:34 CST(-0600)] <Justin_o> fluid-everyone: our currently empty github account is up at https://github.com/fluid-project
[10:01:22 CST(-0600)] <colinclark> thanks, Justin_o
[10:01:49 CST(-0600)] <Justin_o> colinclark: no problem
[10:02:10 CST(-0600)] <colinclark> In case people are interested, I'm https://github.com/colinbdclark on Github
[10:02:19 CST(-0600)] <anastasiac> Justin_o, I'm wondering if once git is all set up, it might be a good idea to run a little git workshop - walk us through the basics of how distributed version control works: how to do the most common things we'll likely be doing, etc.
[10:02:27 CST(-0600)] <colinclark> anastasiac: That's the plan, yes
[10:02:32 CST(-0600)] <anastasiac> excellent!
[10:04:27 CST(-0600)] <colinclark> Do you have your own account on Github yet, Justin_o?
[10:04:46 CST(-0600)] <Justin_o> https://github.com/jobara
[10:05:11 CST(-0600)] <Justin_o> i have to figure out how that gravatar thing works still though.. don't have nice picture up like you do
[10:06:03 CST(-0600)] <colinclark> It's pretty easy to get set up
[10:11:30 CST(-0600)] <anastasiac> athena, good morning. I just sent you an email with some information about the problems we're having with our uPortal deployment
[10:12:47 CST(-0600)] <athena> yes! in the process of writing back to you
[10:12:54 CST(-0600)] <anastasiac> great, thanks
[10:12:55 CST(-0600)] <athena> the error you're getting is actually innocuous, i think
[10:13:10 CST(-0600)] <anastasiac> hm
[10:13:16 CST(-0600)] <athena> i've rewritten the import stuff to expect portlets rather than channels, and i'm still not sure what the role of that old error should be
[10:13:49 CST(-0600)] <athena> my thought is that there might be an issue with the shared libraries?
[10:14:07 CST(-0600)] <athena> if you have access to that machine, can you tell if more than one version of any of the jars is in tomcat/shared/lib?
[10:28:38 CST(-0600)] <colinclark> Justin_o: In case you're setting up a gravatar for the fluid-project account, there are some logos on here: http://wiki.fluidproject.org/display/fluid/Fluid+Brand
[10:28:53 CST(-0600)] <colinclark> That badge might be just fine
[10:29:03 CST(-0600)] <Justin_o> colinclark: thanks i was wondering what to use for that
[10:29:20 CST(-0600)] <colinclark> Though there are plenty more logos on http://wiki.fluidproject.org/display/fluid/Fluid+and+Fluid+Product+Logos
[10:29:42 CST(-0600)] <colinclark> Undoubtedly there will be a new logo before too too long
[10:30:18 CST(-0600)] <Justin_o> colinclark: thanks.. i'll try to pick one of those..
[10:30:25 CST(-0600)] <colinclark> Gist is a curious thing, Justin_o: https://gist.github.com/
[10:31:39 CST(-0600)] <jessm> Justin_o: jameswy has the new fluid logo – or pieces of it
[10:38:52 CST(-0600)] <colinclark> jessm: Oh, cool
[10:38:52 CST(-0600)] <colinclark> a
[10:38:57 CST(-0600)] <colinclark> are they on the wiki somewhere?
[10:39:00 CST(-0600)] <colinclark> Or still in development?
[10:39:11 CST(-0600)] <colinclark> Hey heidi_, did you end up selecting a scroller plugin?
[10:40:01 CST(-0600)] <heidi_> hey colinclark, still comparing both - i think functionality wise either would work but was one of the pluses to scrollTo the fact that it's been continually updated?
[10:40:12 CST(-0600)] <heidi_> *being
[10:40:20 CST(-0600)] <colinclark> Support is always one criteria for choosing
[10:40:31 CST(-0600)] <colinclark> Code quality is always going to be the most important one
[10:40:39 CST(-0600)] <jessm> colinclark: i think still in development
[10:40:43 CST(-0600)] <colinclark> so fire me your list of options and I'll take a closer look at the implementation today
[10:40:55 CST(-0600)] <heidi_> colinclark were there bugs with the current plugin?
[10:40:59 CST(-0600)] <Justin_o> jessm: thanks i'll bug james about it when he gets back
[10:41:11 CST(-0600)] <colinclark> heidi_: Current plugin?
[10:41:21 CST(-0600)] <heidi_> sorry, with the current scroller.js
[10:42:24 CST(-0600)] <colinclark> Ah, the Scroller component
[10:42:31 CST(-0600)] <colinclark> You can check JIRA for specific bugs
[10:42:47 CST(-0600)] <colinclark> I think its primary issues revolved around the requirement for somewhat contrived markup
[10:42:48 CST(-0600)] <heidi_> i don't see any there
[10:42:56 CST(-0600)] <heidi_> yah, the inner div thing
[10:44:04 CST(-0600)] <colinclark> So that's another key thing to look at with the scrollTo plugin
[10:44:08 CST(-0600)] <colinclark> Will it be flexible in terms of markup
[10:44:18 CST(-0600)] <colinclark> and will it require less in the way of additional wrapping
[10:44:25 CST(-0600)] <heidi_> the other scroller plugins i see are very specific in terms of functionality
[10:44:34 CST(-0600)] <colinclark> How so?
[10:44:51 CST(-0600)] <athena> can the fluid uploader be configured to only allow one file at a time?
[10:45:00 CST(-0600)] <colinclark> athena: yep
[10:45:05 CST(-0600)] <athena> hurray!
[10:45:08 CST(-0600)] <athena> i'll try it out
[10:45:08 CST(-0600)] <colinclark> let me just look up the options you need
[10:45:12 CST(-0600)] <colinclark> but I think it's fileLimit
[10:45:18 CST(-0600)] <athena> oh terrific
[10:45:24 CST(-0600)] <athena> figure it's less compelling in that mode
[10:45:25 CST(-0600)] <colinclark> If you're using 1.3, that'll be in the queueSettings option
[10:45:29 CST(-0600)] <athena> but gets us closer to where we want to be
[10:45:29 CST(-0600)] <heidi_> just do specific things like scroll columns, or mobile-related, or load html when scrolling etc
[10:45:33 CST(-0600)] <athena> no 1.3 yet
[10:45:34 CST(-0600)] <colinclark> in 1.2, it'll be somewhere else
[10:45:37 CST(-0600)] <athena> that'd be a good change though, hmm
[10:45:47 CST(-0600)] <athena> maybe i should just do that
[10:45:48 CST(-0600)] <heidi_> there is one called tbody scroll which is what we're after
[10:46:24 CST(-0600)] <heidi_> but we also want to jump to files in the list as well so, not enough
[10:48:44 CST(-0600)] <heidi_> there is also a "scrolltome" plugin which does the later - but yeah, i'll email you a list
[10:49:38 CST(-0600)] <mlam> athena: the queueSettings option you're looking at to limit the upload to 1 file at a time is fileUploadLimit
[10:49:46 CST(-0600)] <athena> thanks!
[10:49:50 CST(-0600)] <mlam> np!
[10:56:27 CST(-0600)] <heidi_> actually colin, it's pretty clear that scrollTo is superior code-quality-wise... most of these plugins aren't amazing
[11:07:18 CST(-0600)] <anastasiac> athena, sorry for the delay in responding. I checked tomcat/shared/lib, and I don't see multiple versions of anything there. I tried "ant clean-shared" and got an error: "build.xml:61: The <tempfile> type doesn't support the "deleteonexit" attribute." I'm working from the latest trunk.
[11:07:39 CST(-0600)] <athena> aieee
[11:07:47 CST(-0600)] <athena> let me try it on mine
[11:07:55 CST(-0600)] <athena> huh.
[11:08:20 CST(-0600)] <athena> what version fo ant are you running?
[11:08:46 CST(-0600)] <anastasiac> 1.6.5
[11:08:47 CST(-0600)] <athena> and what version of maven?
[11:08:54 CST(-0600)] <athena> ah, ok, that'd be it then
[11:09:02 CST(-0600)] <anastasiac> mvn 20.6
[11:09:16 CST(-0600)] <anastasiac> what version of ant should we use?
[11:09:17 CST(-0600)] <athena> i think you'll have to upgrade both of those
[11:09:30 CST(-0600)] <athena> i believe this is all still true of the trunk: https://wiki.jasig.org/display/UPM32/Requirements
[11:09:33 CST(-0600)] <athena> so maven 2.2+
[11:09:40 CST(-0600)] <athena> ant 1.7.1 (specifically, not ant 1.8)
[11:09:45 CST(-0600)] <athena> er, 1.8
[11:09:49 CST(-0600)] <athena> and java 1.6
[11:09:49 CST(-0600)] <anastasiac> ok, thanks - I'll look into upgrading those
[11:10:03 CST(-0600)] <athena> also tomcat 6
[11:10:08 CST(-0600)] <athena> least we found something
[11:10:20 CST(-0600)] <anastasiac> yes - hopefully, that's the problem
[11:10:48 CST(-0600)] <athena> yeah, i'm sure it's at least part of it
[11:10:51 CST(-0600)] <anastasiac> though once we get it up and running again, it would be good to figure out a way to detect problems like these and notify...
[11:11:02 CST(-0600)] <athena> yeah
[11:11:17 CST(-0600)] <athena> and make a note to poke you guys when something like that changes
[11:35:27 CST(-0600)] <jameswy> Justin_o, jessm, colinclark: Yep, the logo's in the wiki here: http://wiki.fluidproject.org/display/fluid/Fluid+Engage+logo+kit
[11:35:57 CST(-0600)] <jameswy> I guess we should probably separate the Engage and Fluid stuff from each other
[11:36:01 CST(-0600)] <jessm> jameswy: we should probably move that page under the logo section
[11:36:19 CST(-0600)] <jameswy> That too.
[11:38:24 CST(-0600)] <athena> anyone have any insight into what this error might mean w/ the uploader?
[11:38:32 CST(-0600)] <athena> uncaught exception: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIXMLHttpRequest.open]" nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)" location: "JS frame :: http://localhost:8080/ResourceServingWebapp/rs/fluid/1.3/js/fluid-all-1.3.min.js :: anonymous :: line 22" data: no]
[11:38:57 CST(-0600)] <colinclark> athena: yes
[11:39:12 CST(-0600)] <colinclark> Are you testing the Uploader locally?
[11:39:19 CST(-0600)] <colinclark> and using the Flash version, by chance?
[11:39:24 CST(-0600)] <athena> yes and yes
[11:39:40 CST(-0600)] <athena> er, using whatever the default is, anyway
[11:39:48 CST(-0600)] <colinclark> Read the Uploader read me file in the components/uploader/ directory
[11:39:57 CST(-0600)] <colinclark> about setting up Flash for use on the local file system
[11:40:00 CST(-0600)] <colinclark> though it seems trange
[11:40:02 CST(-0600)] <colinclark> strange
[11:40:06 CST(-0600)] <colinclark> if you're using the default setup
[11:40:06 CST(-0600)] <colinclark> a
[11:40:06 CST(-0600)] <athena> oh, ok!
[11:40:09 CST(-0600)] <colinclark> and a sane modern browser
[11:40:14 CST(-0600)] <colinclark> you should be getting the HTML 5 version
[11:40:23 CST(-0600)] <athena> yeah, using FF on OS X
[11:40:27 CST(-0600)] <colinclark> ah, and you are running off a server
[11:40:31 CST(-0600)] <colinclark> this is a bit bizarre
[11:40:37 CST(-0600)] <colinclark> what do you see?
[11:41:22 CST(-0600)] <athena> happy little table of file queueness that looks like it's missing a bunch of CSS
[11:41:39 CST(-0600)] <athena> upload indicator gets to 76% and then that error appears
[11:41:48 CST(-0600)] <colinclark> wowza
[11:41:49 CST(-0600)] <athena> not sure whether it's an error on my end or what
[11:42:10 CST(-0600)] <colinclark> this is bizarre, a bit
[11:42:19 CST(-0600)] <athena> woo i broke it
[11:42:33 CST(-0600)] <colinclark> mlam: This touches on the bug you are currently fixing
[11:42:47 CST(-0600)] <athena> on first glance it doens't look like it's reaching our upload servlet
[11:43:00 CST(-0600)] <colinclark> How many files at a time, athena?
[11:43:01 CST(-0600)] <colinclark> 1?
[11:43:06 CST(-0600)] <athena> yep
[11:43:08 CST(-0600)] <colinclark> which version of FF?
[11:43:26 CST(-0600)] <athena> 3.6.13
[11:43:35 CST(-0600)] <colinclark> ok
[11:43:37 CST(-0600)] <athena> let me try w/ the unminified version of fluid and see if that sheds any light
[11:43:46 CST(-0600)] <colinclark> thanks athena
[11:43:53 CST(-0600)] <colinclark> i wonder if you've maybe stumbled across something here
[11:43:55 CST(-0600)] <athena> i did just upgrade uportal 5 min ago, so possible something's just not set up correctly
[11:44:16 CST(-0600)] <athena> wonder if i should try copying just your demo version or something like that
[11:44:35 CST(-0600)] <anastasiac> athena, bad news: I just double-checked and realized that our build script specifies particular version for the tools, and we do use ant 1.7.1, maven 2.2.1 and java 1.6. I did the clean-shared (though I noticed that it's done as part of our regular deployment) and re-deployed, and no joy: still not working
[11:44:53 CST(-0600)] <athena> hmmm
[11:45:19 CST(-0600)] <athena> i think it might be worth looking at the log files to see why the channels aren't working
[11:45:38 CST(-0600)] <anastasiac> which log files in particular should I look at?
[11:45:39 CST(-0600)] <athena> most of the relevant log messages are likely in uPortal.log, though sometimes relevant stuff crops up in catalina.out as well
[11:45:43 CST(-0600)] <mlam> colinclark: athena: that's a really strange bug. I think that's a bit different than anything that's posted in the JIRAs. But the error happening at 76% leads me to believe that the connection to the server was suddenly dropped.
[11:45:55 CST(-0600)] <athena> interesting
[11:46:09 CST(-0600)] <athena> since i'm talking to localhost i guess i can't blame comcast for once
[11:46:38 CST(-0600)] <athena> could it be the result of not finding the upload URL or something like that?
[11:47:31 CST(-0600)] <colinclark> athena: Seems unlikely
[11:47:36 CST(-0600)] <mlam> I don't think so, considering 76% of the file was uploaded
[11:47:43 CST(-0600)] <colinclark> I imagine XHR would fail to open if the URL was wrong
[11:47:52 CST(-0600)] <colinclark> though the error does suggest a failure in a call to XHR.open()
[11:48:12 CST(-0600)] <athena> yeah
[11:48:50 CST(-0600)] <athena> and this is a brand new servlet that it's posting to, so it could conceivably be broken
[11:48:59 CST(-0600)] <athena> the connection does use the POST method though, right?
[11:49:09 CST(-0600)] <colinclark> it does indeed, yes
[11:49:21 CST(-0600)] <colinclark> you might want to try firing up a debugging proxy
[11:49:28 CST(-0600)] <colinclark> and see if anything's getting sent down the line
[11:49:42 CST(-0600)] <colinclark> i hate to subject you to such low-level debugging
[11:50:00 CST(-0600)] <colinclark> i could do it if you can fire me a publicly-visible URL
[11:50:42 CST(-0600)] <athena> no it makes sense
[11:50:56 CST(-0600)] <athena> going to do a more vanilla test too just to make sure this thing works at all
[11:52:03 CST(-0600)] <colinclark> ok
[11:52:10 CST(-0600)] <colinclark> how big is the file you're uploading?
[11:52:21 CST(-0600)] <colinclark> any other interesting characteristics about it?
[11:53:21 CST(-0600)] <athena> ok, the vanilla test did work
[11:53:27 CST(-0600)] <athena> very small text file
[11:53:29 CST(-0600)] <athena> has a .user extension
[11:54:00 CST(-0600)] <athena> looks like one of these: https://source.jasig.org/uPortal/trunk/uportal-war/src/main/data/default_entities/user/admin.user
[11:54:17 CST(-0600)] <athena> though without the license header
[11:55:05 CST(-0600)] <athena> ok, what would you suggest for a debugging proxy these days?
[11:55:09 CST(-0600)] <athena> not sure i have one for os x anymore
[11:56:30 CST(-0600)] <colinclark> charles
[11:56:34 CST(-0600)] <colinclark> it has a firefox plugin
[11:56:37 CST(-0600)] <colinclark> it'll bug you to register it
[11:56:40 CST(-0600)] <colinclark> but it works
[11:56:51 CST(-0600)] <colinclark> you know, the net panel will probably show you HTML 5 XHR requests, too
[11:57:10 CST(-0600)] <colinclark> so you can check there, too
[11:58:10 CST(-0600)] <athena> net panel didn't show anything
[11:58:19 CST(-0600)] <colinclark> that's pretty interesting
[11:58:23 CST(-0600)] <colinclark> progress gets to 76%
[11:58:30 CST(-0600)] <athena> hm, you know, i think i had charles installed before the whole computerpocalypse
[11:58:30 CST(-0600)] <colinclark> but Net panel doesn't show the XHR opening
[11:58:39 CST(-0600)] <colinclark> I hate Computerpocalypses
[11:58:49 CST(-0600)] <colinclark> I had one not too long ago, too
[11:59:31 CST(-0600)] <athena> i recommend not dropping your backup drive on the same day that your computer's built-in hard drive dies
[12:01:16 CST(-0600)] <colinclark> eek
[12:01:17 CST(-0600)] <colinclark> so sad
[12:01:59 CST(-0600)] <athena> yes
[12:02:35 CST(-0600)] <athena> huh.
[12:02:39 CST(-0600)] <athena> nothing from charles proxy either
[12:02:46 CST(-0600)] <colinclark> okay
[12:02:52 CST(-0600)] <colinclark> so we've got a failure in XHR.open
[12:02:55 CST(-0600)] <colinclark> as the stack trace suggests
[12:02:56 CST(-0600)] <colinclark> so
[12:03:04 CST(-0600)] <colinclark> is there any cross-domain scariness happening?
[12:03:37 CST(-0600)] <athena> no don't think so
[12:03:38 CST(-0600)] <colinclark> Your uploadURL is at the same domain and port number as the HTML is being served from?
[12:03:48 CST(-0600)] <athena> yep
[12:03:52 CST(-0600)] <colinclark> ok
[12:03:53 CST(-0600)] <athena> same context, even
[12:04:03 CST(-0600)] <colinclark> okay, let's try something fun, then
[12:04:20 CST(-0600)] <colinclark> override the configuration of your uploader to use a particular strategy, rather than the "progressiveStrategy"
[12:04:30 CST(-0600)] <colinclark> In this case, the fluid.uploader.swfUploadStrategy
[12:04:40 CST(-0600)] <athena> ok
[12:04:40 CST(-0600)] <colinclark> let's see what Flash does, given the same settings
[12:04:41 CST(-0600)] <athena> sounds good
[12:04:44 CST(-0600)] <colinclark> just a bit of a sanity check
[12:05:00 CST(-0600)] <colinclark> you'll have to pass an extra option to your fluid.uploader.swfUploadStrategy
[12:05:01 CST(-0600)] <colinclark> the flashURL
[12:05:21 CST(-0600)] <athena> looks like i did set that
[12:05:23 CST(-0600)] <colinclark> which needs to be a URL pointing to the swfupload.swf file, relative to your HTML page
[12:05:25 CST(-0600)] <colinclark> ok, cool
[12:05:31 CST(-0600)] <colinclark> tell me what happens there
[12:06:01 CST(-0600)] <colinclark> athena: I'm sorry for this being trouble...
[12:06:18 CST(-0600)] <colinclark> on a positive note, this is awesome timing because we have several Uploader fixes scheduled for a quick 1.3.1 release in Feb
[12:06:22 CST(-0600)] <athena> oh! it's really no problem
[12:06:24 CST(-0600)] <athena> i appreciate the help
[12:06:29 CST(-0600)] <athena> and none of this is urgent
[12:06:34 CST(-0600)] <athena> just playing around w/ the uploader in the up trunk
[12:06:41 CST(-0600)] <colinclark> so if there's something here, we can fix it
[12:06:59 CST(-0600)] <athena> ok, sorry - where does the strategy get set?
[12:07:13 CST(-0600)] <athena> oh i see
[12:07:36 CST(-0600)] <colinclark> Uploader is now IoC-ified
[12:07:44 CST(-0600)] <colinclark> so all subcomponents live in a "components" block in the options
[12:07:51 CST(-0600)] <colinclark> a little tidier
[12:09:30 CST(-0600)] <athena> hmm, not sure i have this quite right
[12:09:35 CST(-0600)] <athena> mind taking a look? http://uportal.pastebin.com/VyHb4ixt
[12:10:23 CST(-0600)] <colinclark> yep
[12:10:50 CST(-0600)] <colinclark> this looks right to me
[12:11:02 CST(-0600)] <colinclark> ah, you know what
[12:11:13 CST(-0600)] <colinclark> toss that second argument in your call to fluid.uploader()
[12:11:22 CST(-0600)] <colinclark> the second selector
[12:11:49 CST(-0600)] <colinclark> it shouldn't make any difference
[12:11:55 CST(-0600)] <colinclark> but just in case i did something stupid
[12:12:08 CST(-0600)] <athena> ok, now when i select a file i get an error
[12:12:19 CST(-0600)] <athena> breaks on that.queue.currentBatch is undefined
[12:12:38 CST(-0600)] <athena> for that.queue.currentBatch.numFilesCompleted < fileUploadLimit
[12:13:07 CST(-0600)] <athena> but! when i remove that option it works
[12:13:21 CST(-0600)] <athena> hurray!
[12:14:11 CST(-0600)] <athena> is there a way to tell the uploader to post the file with a different parameter name?
[12:15:12 CST(-0600)] <colinclark> erererere
[12:15:40 CST(-0600)] <colinclark> okay, so you remove the fileUploadLimit, and things work?
[12:16:15 CST(-0600)] <colinclark> at the moment, I think it might post the file with a name of fileData or something like that?
[12:16:24 CST(-0600)] <colinclark> If so, the answer is no, but if you want it, we can fix it for 1.3.1
[12:16:31 CST(-0600)] <colinclark> I believe with Flash, SWFUpload decides
[12:16:36 CST(-0600)] <colinclark> but I could be wrong
[12:16:42 CST(-0600)] <colinclark> certainly in HTML 5, it's easy
[12:17:01 CST(-0600)] <athena> yep, it uses "fileData" even if i change the name of the input element - we'd love to use something custom, but that's not a blocker at the moment
[12:17:07 CST(-0600)] <colinclark> ok, we can do that
[12:17:18 CST(-0600)] <colinclark> so you said "when i remove that option, it works"
[12:17:23 CST(-0600)] <athena> i guess it does need to be the same for both HTML5 and flash though
[12:17:29 CST(-0600)] <colinclark> which options, specifically? Is it fileUploadLimit?
[12:17:34 CST(-0600)] <colinclark> Yes, it should be the same for both
[12:17:39 CST(-0600)] <athena> correct - if i comment out the fileUploadLimit line it works
[12:17:42 CST(-0600)] <colinclark> I'll check SWFUpload to see what we can do on that end
[12:17:44 CST(-0600)] <colinclark> athena: ack
[12:17:47 CST(-0600)] <colinclark> ugly bug
[12:17:50 CST(-0600)] <colinclark> horrifying
[12:17:51 CST(-0600)] <athena> s'ok
[12:17:52 CST(-0600)] <colinclark> I'll file it
[12:17:53 CST(-0600)] <colinclark>
[12:17:59 CST(-0600)] <athena> we're happy to contribute some testing
[12:18:03 CST(-0600)] <colinclark> So, if you switch back to the progressiveStrategy
[12:18:07 CST(-0600)] <colinclark> does it work, too?
[12:18:17 CST(-0600)] <colinclark> so much for passing QA
[12:18:26 CST(-0600)] <colinclark> We need a much better testing server for QA testing to catch these things
[12:18:40 CST(-0600)] <colinclark> Something on my list
[12:18:56 CST(-0600)] <athena> hmm, yep, actually looks like progressiveStrategy works now
[12:19:05 CST(-0600)] <athena> so odd that it got that error before when it was the file upload issue
[12:19:34 CST(-0600)] <athena> lets change the expected param name and see if it really works
[12:21:04 CST(-0600)] <athena> looks like this has pretty nice i18n support
[12:21:15 CST(-0600)] <colinclark> we've tried our best
[12:21:18 CST(-0600)] <athena> that's one thing we're really trying to address for the next release
[12:21:38 CST(-0600)] <athena> hoping we can make life easier for adopters
[12:21:43 CST(-0600)] <colinclark> I'd hope that all the components should now be nicely localizable
[12:22:05 CST(-0600)] <colinclark> The challenge is just adapting that to whatever properties files you'll have underneath it all
[12:22:09 CST(-0600)] <athena> oh this is so cool!
[12:22:11 CST(-0600)] <athena> totally works now
[12:22:21 CST(-0600)] <colinclark> Except for the file limit, right?
[12:22:29 CST(-0600)] <athena> yes, but i can live with that for now
[12:22:39 CST(-0600)] <colinclark> I'll file the bug, as soon as I go eat a sandwich
[12:22:59 CST(-0600)] <colinclark> For the HTML 5 version, were you able to change the name of the POST parameter?
[12:23:00 CST(-0600)] <athena> right now we're just injecting the messages into the js using either the spring:messages code or a custom XSLT extension thing
[12:23:07 CST(-0600)] <colinclark> I seem tor recall that it's hardcoded
[12:23:10 CST(-0600)] <colinclark> athena: Ah, perfect
[12:23:20 CST(-0600)] <athena> no, haven't changed the param name, but that's ok too
[12:23:20 CST(-0600)] <colinclark> so you can just dynamically override the strings block for each component as needed
[12:23:23 CST(-0600)] <colinclark> ok
[12:23:28 CST(-0600)] <colinclark> two post-sandwich JIRAs to file
[12:23:34 CST(-0600)] <athena> enjoy the sandwich
[12:23:39 CST(-0600)] <athena> sounds like a brilliant idea
[12:23:48 CST(-0600)] * athena was just told by her spouse to put down the laptop and eat something
[12:23:52 CST(-0600)] <colinclark>
[12:24:06 CST(-0600)] <colinclark> The uploadLimit issue seems undoubtedly a blocker for 1.3.1
[12:24:18 CST(-0600)] <colinclark> The POST param, I'm curious to hear your opinion about how important
[12:24:29 CST(-0600)] <colinclark> does it "suck" or is just "slightly lame" or "nice to have"
[12:24:34 CST(-0600)] <colinclark> in surfer-dude terms, that is
[12:24:38 CST(-0600)] <athena> i think "kinda lame"
[12:24:41 CST(-0600)] <athena> but not the end of the world
[12:24:54 CST(-0600)] <colinclark> assuming SWFUpload is amenable, it's probably a two-line fix
[12:24:57 CST(-0600)] <athena> it'd be nice to have our servlet take an "entityFile" instead just to make really clear what we're uploading
[12:25:04 CST(-0600)] <colinclark> makes sense to me
[12:25:31 CST(-0600)] <athena> also we're starting to create REST services, so eventually we might have a servlet that's used by other things or is trying to use shared conventions
[12:25:40 CST(-0600)] <athena> but it's not actually a technical blocker by any means
[12:25:44 CST(-0600)] <colinclark> k
[12:25:52 CST(-0600)] <athena> and nothing else uses this servlet right now
[12:25:55 CST(-0600)] <colinclark> I'll see what mlam says when everyone gets back from soccer
[12:25:59 CST(-0600)] <athena> so jsut a nitpicky thing
[12:26:00 CST(-0600)] <colinclark> He's the boss now on Uploader
[12:26:01 CST(-0600)] <athena> soccer! fun
[12:26:05 CST(-0600)] <colinclark> I just fix what he tells me to
[12:26:18 CST(-0600)] <athena> lol nice
[12:26:23 CST(-0600)] <colinclark> The King has been organizing afternoon sports on Tuesdays and Wednesdays
[12:26:29 CST(-0600)] <colinclark> it's been a lot of fun
[12:26:29 CST(-0600)] <athena> oh fun!
[12:26:33 CST(-0600)] <colinclark> nice side-effect of the move to OCAD
[12:26:56 CST(-0600)] <athena> i had to take a season off from soccer to focus on other things and let a sprained foot heal
[12:27:02 CST(-0600)] <athena> not really digging all the artificial turf here
[12:27:10 CST(-0600)] <colinclark> eek
[12:27:18 CST(-0600)] <colinclark> I didn't know you played
[12:27:24 CST(-0600)] <colinclark> next time you're in Toronto, you'll have to join us
[12:27:29 CST(-0600)] <athena> i'm terrible
[12:27:35 CST(-0600)] <athena> but i like soccer, so it's ok
[12:27:37 CST(-0600)] <colinclark> kasper, from CollectionSpace, came to play with us a few times
[12:27:39 CST(-0600)] <colinclark> he's really good
[12:27:47 CST(-0600)] <athena> i don't actually play - i played when i was 5, 12, and now
[12:27:59 CST(-0600)] <colinclark> I'm not terribly good myself
[12:28:03 CST(-0600)] <athena> but luckily found a pretty relaxed co-ed rec team that's ok with cluelessness
[12:28:06 CST(-0600)] <colinclark> We play basketball on Tuesdays, which I prefer
[12:28:21 CST(-0600)] <colinclark> But everyone plays soccer, which is cool
[12:28:33 CST(-0600)] <athena> sounds like good fun glad the move has resulted in some fun activities
[12:28:40 CST(-0600)] <colinclark>
[12:39:16 CST(-0600)] <heidi_> hey colinclark .. can you help me understand why not including scroller.js would cause a fluid.js error "Error invoking global function: fluid.scroller could not be located" ? i've commented out the scroller calls in filequeueview . if yr busy i can ping mike when he returns
[12:41:01 CST(-0600)] <heidi_> colinclark n/m, found it
[12:41:02 CST(-0600)] <heidi_>
[12:57:39 CST(-0600)] <colinclark> sorry, i was away eating a sandwich, heidi_
[12:57:42 CST(-0600)] <colinclark> glad you figured it out
[13:08:42 CST(-0600)] <colinclark> heidi_: I took some time to read through the source code of the scrollTo plugin
[13:08:47 CST(-0600)] <colinclark> I feel pretty good about it
[13:09:06 CST(-0600)] <heidi_> colinclark same
[13:09:07 CST(-0600)] <heidi_> thanks
[13:09:08 CST(-0600)] <heidi_> !
[13:29:41 CST(-0600)] <colinclark> Justin_o: How do you think we should do the dev meeting today?
[13:29:48 CST(-0600)] <colinclark> I don't have anything particular on the agenda
[13:29:58 CST(-0600)] <colinclark> Probably just checkins on the Uploader, git, that sort of thing
[13:30:10 CST(-0600)] <colinclark> You probably want updates on the JIRA gardening, too?
[13:30:20 CST(-0600)] <Justin_o> colinclark: yes that sounds good
[13:30:34 CST(-0600)] <mlam> athena: colinclark, sorry! just got back from soccer...catching up with the logs now
[13:30:37 CST(-0600)] <Justin_o> do we have anyone remote?
[13:30:44 CST(-0600)] <colinclark> i don't think so, Justin_o
[13:30:46 CST(-0600)] <colinclark> so we can just chat
[13:31:17 CST(-0600)] <Justin_o> colinclark: okay
[13:37:23 CST(-0600)] <Bosmon> Am I not remote?
[14:03:09 CST(-0600)] <jamon> anyone mind if i work on the new builder's continuum instance? looks to need more memory
[14:34:35 CST(-0600)] <heidi_> mlam there's one little css thing i can't figure out - the progress bar gets set to 420px wide, inline, but i can't find where that's happening
[14:37:40 CST(-0600)] <mlam> i think that value is set in the progress component itself
[14:37:44 CST(-0600)] <mlam> but let me double check for you
[14:49:35 CST(-0600)] <colinclark> Seems likely that it's in the progress component
[14:52:26 CST(-0600)] <colinclark> Bosmon and heidi_, sorry I totally forgot that you were coming in remotely today
[14:52:27 CST(-0600)] <colinclark> my bad
[14:52:31 CST(-0600)] <colinclark> hopefully the audio was workable
[14:52:49 CST(-0600)] <heidi_> colinclark np - i could hear totally fine
[15:08:38 CST(-0600)] <heidi_> mlam, in filequeueview.js - is there a way to access the selector fileQueue in uploader.js ?
[15:09:37 CST(-0600)] <heidi_> i want that to be my scrollable thing vis that.scroller
[15:09:42 CST(-0600)] <heidi_> vs.
[15:10:34 CST(-0600)] <heidi_> or colinclark ^
[15:10:37 CST(-0600)] <mlam> heidi_: yah, there is
[15:10:54 CST(-0600)] <mlam> it all depends where you need it though
[15:11:04 CST(-0600)] <heidi_> a bunch of places
[15:11:05 CST(-0600)] <mlam> you currently have access to it in the fileQueueView function
[15:11:31 CST(-0600)] <mlam> access is currently given through IoC.
[15:11:52 CST(-0600)] <mlam> maybe we can pair tomorrow, and you can show me all the places you need it?
[15:11:55 CST(-0600)] <heidi_> i need it on like, line 52, 250
[15:12:20 CST(-0600)] <heidi_> 204
[15:13:03 CST(-0600)] <heidi_> basically replacing that.scroller with it
[15:13:26 CST(-0600)] <heidi_> i want to scroll the fileQueue, which is inherently scrollable with overflow:auto
[15:13:40 CST(-0600)] <mlam> ok, doesn't look like it'll be a problem at all
[15:13:56 CST(-0600)] <heidi_> good
[15:14:00 CST(-0600)] <mlam> what time are you working until today?
[15:14:04 CST(-0600)] <heidi_> 5
[15:14:09 CST(-0600)] <mlam> maybe i can write up a quick patch for you now?
[15:14:27 CST(-0600)] <heidi_> sure! or you can tell me how - it is involved?
[15:14:39 CST(-0600)] <heidi_> tomorrow is fine too
[15:14:45 CST(-0600)] <mlam> it's not too bad.
[15:15:03 CST(-0600)] <Bosmon> colinclark, yura_ - perhaps on reflection, it isn't necessary to do something terribly insane....
[15:15:05 CST(-0600)] <heidi_> let's do it tomorrow so you can show me how
[15:15:14 CST(-0600)] <Bosmon> A simple IoC-resolved function should be sufficient....
[15:15:15 CST(-0600)] <mlam> ok, tomorrow then, since we're already pairing for a bit with the scroller. ok
[15:15:20 CST(-0600)] <heidi_> thanks mlam!
[15:15:23 CST(-0600)] <mlam> np
[15:15:56 CST(-0600)] <Bosmon> It takes two things as arguments, i) current record type, ii) list of all record types in the category, iii) a primary "permissions resolver"
[15:16:55 CST(-0600)] <colinclark> heidi_: There's a short answer to your question, if you want to hack around with it on your own...
[15:17:13 CST(-0600)] <yura_> Bosmon: so you would resolve both i and ii separately?
[15:17:31 CST(-0600)] <colinclark> The element matching Uploader's "fileQueue" selector is the container for the FileQueueView
[15:17:45 CST(-0600)] <Bosmon> yura_: Actually I'm changing my mind already.....
[15:17:51 CST(-0600)] <Bosmon> Just looking at the code in Permissions.js
[15:17:53 CST(-0600)] <colinclark> So it's an instance member of the fileQueueView
[15:18:01 CST(-0600)] <colinclark> which you can access by referring to that.container
[15:18:37 CST(-0600)] <colinclark> All Views in Infusion are assigned a container variable, which is a jQuery instance of the thing passed in as the first argument to its creator function
[15:19:03 CST(-0600)] <Bosmon> My new suggestion is to reimplement the "resolve" method in cspace.permissions.resolver so that it can operate on recursive structures
[15:19:30 CST(-0600)]

[15:19:57 CST(-0600)] <Bosmon> In this way we will have a simple declarative structure that can encode any logical operation on combining permissions
[15:20:15 CST(-0600)] <Bosmon> It won't integrate well with anything else we are planning, but it at least is a simple extension of what we have already
[15:21:23 CST(-0600)] <Bosmon> Taking this issue "out into the wild" we are faced with the possibility of i) a kind of "expander algebra" based on lots of exercises of fluid.deferredCall which would perhaps invoke something slightly silly named "fluid.AND" and "fluid.OR", or ii) the same, only based on a "component algebra"
[15:21:56 CST(-0600)] <Bosmon> I think until we have the "condensed form" of fluid.deferredCall using the "!" notation we talked about before we should hold off on these routes since the resulting trees will look pretty silly as encodings of boolean expressions
[15:23:59 CST(-0600)] <Bosmon> Although I guess this "stopgap" system is relying on the fact that people would not want variability on permission names AND permission targets at the same time......
[15:26:32 CST(-0600)] <Bosmon> colinclark: For reference, we are looking around line 91 in https://source.collectionspace.org/collection-space/src/ui/trunk/src/main/webapp/js/Permissions.js
[15:26:42 CST(-0600)] <Bosmon> cspace.permissions.resolver
[15:27:05 CST(-0600)] <heidi_> colinclark i'm using the actual hardcoded classname right now to make it work - is there a var for this tho? vs the flc-
[15:27:17 CST(-0600)] <colinclark> heidi_: You should never use the hardcoded classname
[15:27:25 CST(-0600)] <heidi_> colinclark i know
[15:27:29 CST(-0600)] <colinclark> If you want a jQuery for the thing that is the fileQueue, it's the container
[15:27:31 CST(-0600)] <colinclark> that.container
[15:27:33 CST(-0600)] <colinclark> that's all you need
[15:27:40 CST(-0600)] <heidi_> that.container
[15:27:43 CST(-0600)] <heidi_> okay ill try it
[15:29:07 CST(-0600)] <heidi_> colinclark mlam that.container works - thanks dudes
[15:33:15 CST(-0600)] <colinclark> heidi_: I can't remember--did you say at the dev meeting that you have a patch for basic markup cleanup for Uploader?
[15:33:32 CST(-0600)] <heidi_> colinclark yep but need to test it on win browsers
[15:34:10 CST(-0600)] <heidi_> and there's one little weirdness with the width of the progress bar that i need to figure out - it's set to inline width of 420px which no longer goes all the way to the end.
[15:34:23 CST(-0600)] <heidi_> (the green progress bar behind status footer)
[15:38:38 CST(-0600)] <colinclark> ok
[15:38:47 CST(-0600)] <colinclark> i'd prefer one patch for each feature, just to keep it simple
[15:38:52 CST(-0600)] <colinclark> life will be way better with git
[15:40:58 CST(-0600)] <yura_> Bosmon: i m thinking that the cspace.permissions.resolve is the candidate for recursion. I dont think that we can constrain a nested target to just one permission against we are resolving
[15:42:02 CST(-0600)] <yura_> so target should have a target, method, permission
[15:42:34 CST(-0600)] <Bosmon> yura_: Yes, that seems like a good idea
[15:47:27 CST(-0600)] <heidi_> mlam what does refreshView do... when does it get used?
[15:49:22 CST(-0600)] <colinclark> Bosmon, yura_: I don't have anything concrete to add, but I am following your discussion
[15:49:35 CST(-0600)] <colinclark> heidi_: refreshView() for the fileQueueView, you mean?
[15:49:58 CST(-0600)] <heidi_> colinclark ya
[15:52:25 CST(-0600)] <heidi_> i think what scroller refresh did was reset the height of the queue.. but not sure why this was needed. the heigh can be set in css and remain constant there...
[15:53:11 CST(-0600)] <heidi_> maybe because he was using height for his calculations or something...
[15:54:23 CST(-0600)] <heidi_> elicochran - hi! do you recall why scroller refreshView was needed?
[15:54:56 CST(-0600)] <elicochran> hmm
[15:55:19 CST(-0600)] <elicochran> I think that it was to move the scroll to the currently displayed item
[15:55:25 CST(-0600)] <elicochran> but that was a long time ago
[15:56:03 CST(-0600)] <colinclark> heidi_: Let's look at the code for a minute here
[15:56:04 CST(-0600)] <mlam> heidi_ refresh view refreshes the file queue when a file has been added or removed
[15:56:07 CST(-0600)] <elicochran> what does it actually do
[15:56:18 CST(-0600)] <heidi_> mlam ah, thanks
[15:56:33 CST(-0600)] <colinclark> So, refreshView() is a standard method that component implement
[15:56:47 CST(-0600)] <heidi_> so i think it was req'd for scroller to figure out if the scroller still needs to be there or not, after something's deleted
[15:56:55 CST(-0600)] <colinclark> Its contract is "refresh anything that you are responsible for showing to the user based on the current state"
[15:57:04 CST(-0600)] <colinclark> So fileQueueView refreshes two things:
[15:57:15 CST(-0600)] <colinclark> the scroller, which is itself a View with its own refreshView() method
[15:57:40 CST(-0600)] <colinclark> and then it tells the keyboard accessibility plugin, "hey, go look at the DOM and refresh your list of things that can be selected with the keyboard"
[15:57:56 CST(-0600)] <colinclark> It's called, as mlam says, whenever files are added or removed from the queue
[15:58:19 CST(-0600)] <colinclark> heidi_, you can see this code at lines 56 and 86 of fileQueueView
[15:58:31 CST(-0600)] <heidi_> yep
[15:59:04 CST(-0600)] <heidi_> am looking at line 355
[15:59:04 CST(-0600)] <colinclark> And then, scroller's own refreshView method is at line 19 of Scroller.js
[15:59:11 CST(-0600)] <heidi_> yeah
[15:59:35 CST(-0600)] <heidi_> and it looks like its figuring out its height, after something was added or deleted
[16:00:00 CST(-0600)] <colinclark> right, Scroller's refreshView() method is checking the size of the scrolling element, and determining if it needs to constrain it to the maxHeight
[16:00:02 CST(-0600)] <colinclark> that's right
[16:00:22 CST(-0600)] <colinclark> So, we can assume that the scrollTo plugin is going to do this for us, I imagine
[16:00:50 CST(-0600)] <heidi_> yeah, am just wondering why to do it this way vs letting the browser figure it out with overflow:auto - do you know?
[16:01:08 CST(-0600)] <colinclark> That part, only elicochran can answer
[16:01:12 CST(-0600)] <heidi_> i think it was because those values were needed for calculations
[16:01:24 CST(-0600)] <heidi_> but now with scrollTo we dont need that
[16:01:40 CST(-0600)] <colinclark> We should be able toss any reference to the Scroller component
[16:01:49 CST(-0600)] <elicochran> agreed
[16:01:55 CST(-0600)] <elicochran> scrollTo is superior
[16:01:57 CST(-0600)] <heidi_> yep im just making sure it's functionality is properly replaced
[16:02:04 CST(-0600)] <heidi_> its
[16:02:07 CST(-0600)] <colinclark> yep
[16:02:17 CST(-0600)] <heidi_> but i think the refresh bit can be just removed
[16:02:17 CST(-0600)] <elicochran> the scroller had some serious hacks to manage cross-browser fu
[16:02:25 CST(-0600)] <colinclark> As far as I can guess, you just need to replace calls to scroller.scrollTo() with calls to the plugin instead
[16:02:32 CST(-0600)] <colinclark> and get rid of any other references to it
[16:02:45 CST(-0600)] <heidi_> yeah i've done that, just checking over the refresh bit
[16:03:07 CST(-0600)] <heidi_> which i think we can just remove. thanks all