fluid-work IRC Logs-2011-03-30

[03:02:34 CDT(-0500)] <pulkit> Hi
[03:03:57 CDT(-0500)] <pulkit> What are the high priority image processing algorithms expected other than cropping, resizing and tagging?
[08:24:20 CDT(-0500)] <kasper> yura_:
[08:24:24 CDT(-0500)] <yura_> kasper:
[08:24:32 CDT(-0500)] <kasper> do you have a sec to look at my code
[08:24:43 CDT(-0500)] <kasper> or answer a question anyways
[08:24:52 CDT(-0500)] <kasper> so.. the recordeditor tests are failing for me
[08:25:16 CDT(-0500)] <kasper> complaining about pageBuilderIO
[08:25:31 CDT(-0500)] <kasper> (ooops, just realizing we're in fluid-channel)
[08:26:44 CDT(-0500)] <Justin_o> kasper: you're welcome to complain in here
[08:26:58 CDT(-0500)] <Justin_o> harriswong: how did the jquery ui upgrade go?
[08:28:04 CDT(-0500)] <heidi> Justin_o added linearizing notes to wiki as 1.4 subpage http://wiki.fluidproject.org/display/fluid/Linearizing+issues
[08:28:17 CDT(-0500)] <harriswong> Justin_o: i replaced the files with 1.8.11 and they are sitting on the branch, i haven't went into testing them yet.
[08:28:29 CDT(-0500)] <Justin_o> harriswong: ah okay
[08:28:50 CDT(-0500)] <harriswong> Justin_o: Is there a particular test plan for doing jquery ui upgrade?
[08:29:16 CDT(-0500)] <Justin_o> harriswong: not really.. i guess just make sure everything that was using it still works
[08:29:22 CDT(-0500)] <kasper> Justin_o: haha, I dont know if you'll still say that after 4 days of me constantly whining to yura
[08:29:47 CDT(-0500)] <Justin_o> kasper: if it's to yura_ i have no problem
[08:29:54 CDT(-0500)] <harriswong> Justin_o: ok.
[08:29:57 CDT(-0500)] <kasper> haha
[08:30:09 CDT(-0500)] <harriswong> Justin_o: i have also created a jira and have pushed it to my github yesterday.
[08:31:38 CDT(-0500)] <Justin_o> harriswong: thanks.. that's good.. i guess for testing you should start with the unit tests... particularly the tooltip one... since that is a wrapper around their tooltip.. from there you can look at the test plans and just do the state tests
[08:32:03 CDT(-0500)] <Justin_o> harriswong: also try running the tests in IE 9 if you can, since things like our reorderer weren't working there before
[08:52:25 CDT(-0500)] <harriswong> Justin_o: ok
[09:10:46 CDT(-0500)] <michelled> cindyli: did you start looking at ui options?
[09:12:13 CDT(-0500)] <cindyli> michelled: cloned branch, haven't looked into yet. spending most time this morning chatting with gsoc students and reviewing their proposals
[09:12:41 CDT(-0500)] <michelled> ok, let me know when you're ready to get started and I'll come over there so we can pair
[09:22:19 CDT(-0500)] <harriswong> mlam: can you try running the unit tests for uploader and see if it is working?
[09:23:40 CDT(-0500)] <mlam> in your branch ? or from the master?
[09:24:04 CDT(-0500)] <harriswong> mlam: mm master please.
[09:25:13 CDT(-0500)] <mlam> sure
[09:27:53 CDT(-0500)] <jhung> anastasiac: something to keep in mind when doing platform research for tech docs...
[09:28:18 CDT(-0500)] * anastasiac leans in expectantly
[09:28:28 CDT(-0500)] <jhung> we'll probably want some sort of ability to handle code snippts well. So fixing width of code snippit boxes, proper indentation, wrapping, maybe numbering.
[09:29:24 CDT(-0500)] <mlam> harriswong: weird, 2 of the files aren't even executing any tests and the filequeueview tests are all broken
[09:30:35 CDT(-0500)] <mlam> i'm going to try them out in FF3.6
[09:32:45 CDT(-0500)] <mlam> harriswong: so there's a broken test in HTML5, looks like the fluid.makeChangeApplier isn't found, and then a few tests in the fileQueueView. are you getting the same?
[09:34:09 CDT(-0500)] <harriswong> mlam: Yep i have the makeChangeApplier not found, and i had a fluid.alias error before but now it's gone.
[09:35:02 CDT(-0500)] <mlam> are you free to help get them fixed?
[09:38:28 CDT(-0500)] <harriswong> mlam: sure. the test case i wrote is now failing on flash as well, fixing.
[09:38:45 CDT(-0500)] <mlam> cool, thanks
[09:41:53 CDT(-0500)] <cindyli> michelled: anytime when you are ready
[10:00:23 CDT(-0500)] <pulkit> What are the high priority algorithms to be implemented for image editor?
[10:12:50 CDT(-0500)] <jessm> pulkit: i'm guessing you're talking about the GSoC project?
[10:13:44 CDT(-0500)] <michelled> yura_: are there debugging supports for IoC now?
[10:13:44 CDT(-0500)] <pulkit> yyesyyes
[10:13:53 CDT(-0500)] <pulkit> yes
[10:14:04 CDT(-0500)] <yura_> michelled: there is much better logging now
[10:14:14 CDT(-0500)] <yura_> and i think mentioned that he added something recently
[10:14:21 CDT(-0500)] <yura_> but i didnt update to new infusion just yet
[10:14:39 CDT(-0500)] <michelled> yura_: ya, I remember a commit log mentioning it but somehow can't find it right now
[10:14:51 CDT(-0500)] <michelled> I think I need to include the debugging file
[10:15:14 CDT(-0500)] <yura_> michelled: oh
[10:15:18 CDT(-0500)] <yura_> i didnt know about that
[10:15:47 CDT(-0500)] <jessm> pulkit: and did you look here? http://wiki.atutor.ca/display/atutorwiki/Google+Summer+of+Code+2011#GoogleSummerofCode2011-FluidProjects
[10:16:23 CDT(-0500)] <michelled> pulkit: the Image Editor project comes out of the Decapod project. Some of the features we want to support are cropping, resizing and marking regions on an image
[10:16:58 CDT(-0500)] <pulkit> Yes. I looked there. Apart from those, are there any other features that have a high priority?
[10:17:36 CDT(-0500)] <michelled> from talking to jameswy it sounds like we want some images tagging for the Floe project
[10:17:59 CDT(-0500)] <michelled> pulkit: one of the most important features is that everything should be accessible.
[10:18:00 CDT(-0500)] <jessm> pulkit: as michelled mentioned – that project is part of this http://sites.google.com/site/decapodproject/ take a look at the work in the wiki to date too: http://wiki.fluidproject.org/display/fluid/Decapod and get to know michelled as she'll be the mentor
[10:19:24 CDT(-0500)] <michelled> pulkit: meaning that it should be doable using either a keyboard or a mouse and should provide enough information to an adaptive technology to communicate how to use the feature and the results of using it
[10:20:42 CDT(-0500)] <pulkit> Okay. Thanks
[10:26:12 CDT(-0500)] <michelled> yura_: From the commit log "New powerful improvement in IoC diagnostics - file and line number tracking for fluid.demands! Include file "FluidDebugging.js" to get access to this facility on Firefox. "
[10:26:42 CDT(-0500)] <colinclark> Those diagnostics are going to be awesome, I think
[10:26:56 CDT(-0500)] <yura_> michelled: I should check it out
[10:46:46 CDT(-0500)] <colinclark> mlam, harriswong: So, can you guys elaborate on the test failures you mentioned at standup?
[10:47:03 CDT(-0500)] <colinclark> And can I reproduce them against the latest version of the project repo, just by running all of Uploader's unit tests?
[10:47:21 CDT(-0500)] <mlam> colinclark: The test that's failing in the FileQueueView are related to null events in the progress component
[10:47:35 CDT(-0500)] <mlam> Yes, I downloaded a fresh copy from the master and ran the tests
[10:47:38 CDT(-0500)] <colinclark> When did it start failing?
[10:48:02 CDT(-0500)] <mlam> Either yesterday or today. The last update I did was Monday
[10:48:19 CDT(-0500)] <colinclark> Ok
[10:48:26 CDT(-0500)] <colinclark> How does it relate to the ChangeApplier?
[10:48:47 CDT(-0500)] <mlam> With the HTML5 tests failing, one was broke on a call to the ChangeApplier. It was just before stand up, so I didn't look much further
[10:48:53 CDT(-0500)] <colinclark> ok
[10:49:20 CDT(-0500)] <colinclark> michelled: Do you have five minutes to help me with a Git question, or are you in the midst of coding?
[10:49:36 CDT(-0500)] <michelled> I can help
[10:50:07 CDT(-0500)] <michelled> colinclark: want me to come there?
[10:50:14 CDT(-0500)] <colinclark> that'd be great
[10:55:51 CDT(-0500)] <colinclark> mlam: Revision 9ab11c05ad2813f8baefff6abcd2c27b41e4ed92 worked
[10:56:16 CDT(-0500)] <colinclark> For both sets of tests--the FileQueueView and the BrowseButtonView tests
[10:56:40 CDT(-0500)] <colinclark> So the first set of Bosmon2's commits yesterday, db474aab142b1a91032a72bb06f4909315127af9, seemed to cause the regression
[10:57:06 CDT(-0500)] <colinclark> With michelled's help, I checked that by following key commits backwards with "git log"
[10:58:30 CDT(-0500)] <colinclark> and, one by one, used "git reset --hard <revision hash>"
[10:58:37 CDT(-0500)] <colinclark> And then ran the tests
[10:58:45 CDT(-0500)] <colinclark> the key issue is the point michelled raised at a dev meeting a few weeks ago
[10:59:04 CDT(-0500)] <colinclark> You have to watch for merge points as key milestones when the project repo actually changes
[10:59:16 CDT(-0500)] <colinclark> other commits will be there, but will have happened at some other point
[10:59:40 CDT(-0500)] <colinclark> the good news is that the master branch hasn't been merged into in over a week--Justin_o and Bosmon2 have been working directly in master
[10:59:50 CDT(-0500)] <colinclark> so each commit actually represents a real point in the history of the proejct repo
[11:01:16 CDT(-0500)] <colinclark> mlam, harriswong: My first guess for the failing browseButtonView test is that Bosmon2 accidentally introduced a dependency on DataBinding.js, but our test file doesn't include it.
[11:01:22 CDT(-0500)] <colinclark> We'll need to see if that is by design or by error
[11:01:33 CDT(-0500)] <mlam> that's a pretty cool feature...i like that
[11:03:42 CDT(-0500)] <mlam> colinclark: adding the DataBinding dependency worked
[11:05:01 CDT(-0500)] <colinclark> Do you know why that fixed it, mlam?
[11:05:32 CDT(-0500)] <mlam> No, where did the DataBinding dependency happen?
[11:05:58 CDT(-0500)] <colinclark> I poked around in the debugger for a bit.
[11:06:21 CDT(-0500)] <colinclark> I think it's probably an error in the test-we should have been including DataBinding.js-we do in the Uploader's own HTML file, as well as in the demo
[11:06:41 CDT(-0500)] <colinclark> but the reason it suddenly broke is a change in the framework, which was apparent from using my debugger
[11:07:22 CDT(-0500)] <colinclark> So, if you look at the stack trace of the error, it's clear that it's failing to find fluid.makeChangeApplier() while in the midst of doing fluid.initView()
[11:07:39 CDT(-0500)] <colinclark> If you remember, the browseButtonHandler is, like any component that uses the DOM, a View component
[11:07:53 CDT(-0500)] <colinclark> So we have recently introduced the concept of "grades" into the framework
[11:08:09 CDT(-0500)] <colinclark> Coming from a Java background, it's tempting to think of them as types
[11:08:24 CDT(-0500)] <colinclark> there are handful of grades, and they are compositions--one grade may be composed of several other grades
[11:08:43 CDT(-0500)] <colinclark> so browseButtonView has a View grade
[11:08:57 CDT(-0500)] <colinclark> The View grade is composed of several other grades
[11:09:18 CDT(-0500)] <colinclark> You can see our grades defined started at line 835 of Fluid.js
[11:09:34 CDT(-0500)] <colinclark> At line 866, you'll see the grade of "fluid.viewComponent"
[11:10:08 CDT(-0500)] <colinclark> and so you'll notice that a View component is composed of three important grades: Little Component, Model Component, and Evented Component
[11:10:29 CDT(-0500)] <michelled> yura_: are you using the createOnEvent feature of IoC?
[11:10:39 CDT(-0500)] <yura_> yes
[11:10:42 CDT(-0500)] <colinclark> at the risk of misleading you with Java analogies, you can think of the View Grade implementing the Little, Model, and Evented interfaces, mlam
[11:10:43 CDT(-0500)] <yura_> michelled: ^
[11:10:57 CDT(-0500)] <michelled> yura_: do you know if it can be used without autoinit?
[11:11:03 CDT(-0500)] <yura_> michelled: yes
[11:11:23 CDT(-0500)] <yura_> it shouldnt matter whether you have autoinit or not
[11:11:24 CDT(-0500)] <michelled> yura_: does it matter where I call init dependents in that case?
[11:11:26 CDT(-0500)] <mlam> colinclark: making sense ^^
[11:11:32 CDT(-0500)] <colinclark> Now, looking at each of those grades, it's the fluid.modelComponent grade that is most important for this error
[11:11:39 CDT(-0500)] <yura_> michelled: no you can call them any time just like before
[11:11:46 CDT(-0500)] <yura_> the whole point is that it doesnt matter anymore
[11:11:51 CDT(-0500)] <michelled> ok thanks
[11:11:53 CDT(-0500)] <colinclark> A model component is a component that 1) has a model, and 2) has a ChangeApplier
[11:12:10 CDT(-0500)] <yura_> michelled: as long i guess as the event doesnt fire before initDependents
[11:12:22 CDT(-0500)] <michelled> ah, makes sense
[11:12:33 CDT(-0500)] <yura_> michelled: my personal collectionspace ui branch record_list has it in use
[11:12:36 CDT(-0500)] <yura_> listEditor.js
[11:12:49 CDT(-0500)] <colinclark> The change that broke our code was when Antranig fully introduced support for model components two revision ago
[11:13:00 CDT(-0500)] <colinclark> Which means that, by nature of being a View, we're also a Model component
[11:13:06 CDT(-0500)] <colinclark> And so we'll get a ChangeApplier for free
[11:13:16 CDT(-0500)] <colinclark> if our code was factored better, we'd be delighted by getting it for free
[11:13:22 CDT(-0500)] <colinclark> but in our case we weren't linking the correct file
[11:13:26 CDT(-0500)] <colinclark> and it was causing the error
[11:13:49 CDT(-0500)] <colinclark> make some sense/
[11:13:50 CDT(-0500)] <colinclark> ?
[11:13:54 CDT(-0500)] <mlam> ahhh cool, thanks for going through that with me. it was actually really really helpful
[11:14:07 CDT(-0500)] <colinclark> no problem
[11:14:12 CDT(-0500)] <colinclark> this stuff is, as you can tell, hot off the press
[11:14:23 CDT(-0500)] <colinclark> so it helps me to read the source code and try to ensure I understand it, too
[11:14:24 CDT(-0500)] <colinclark>
[11:14:37 CDT(-0500)] <colinclark> Let me commit your fix, and then let's go through the other issue in the same way
[11:14:42 CDT(-0500)] <colinclark> it may be more difficult
[11:16:46 CDT(-0500)] <colinclark> I guess one of the key differences between grades and interfaces is that they involve actual implementation
[11:17:06 CDT(-0500)] <colinclark> so it's not inheritance--we're not inheriting from some abstract grade base class, since these are being composed
[11:17:17 CDT(-0500)] <colinclark> but an interface would involve us having to implement code to conform to it
[11:17:32 CDT(-0500)] <colinclark> this is more like a mixin if you're familiar with the concept from other programming languages
[11:17:55 CDT(-0500)] <colinclark> in that some functionality is being added into our object for us, but outside of any inheritance relationship (which is a good thing)
[11:18:06 CDT(-0500)] <colinclark> any of these analogies aren't quite right, so don't take them too far
[11:18:07 CDT(-0500)] <mlam> right
[11:18:14 CDT(-0500)] <colinclark> but it at least helps to compare them to concepts we're all familiar with
[11:18:22 CDT(-0500)] <mlam> yes, definitely
[11:21:51 CDT(-0500)] <colinclark> mlam: So I'm starting to trace back the FileQueueView test failure
[11:21:58 CDT(-0500)] <colinclark> and you're right, it's failing inside Progress.js
[11:22:11 CDT(-0500)] <colinclark> So the first thing is to trace it back up to a point near the top
[11:22:48 CDT(-0500)] <colinclark> And I can see from the stack trace that the error is occurring inside the fileQueueView when we're instantiating the progress bar for a file
[11:22:57 CDT(-0500)] <colinclark> Line 195 on FileQueueView.js
[11:23:14 CDT(-0500)] <colinclark> So, the question is, why?
[11:23:40 CDT(-0500)] <colinclark> I'm going to stick a breakpoint there and explore a bit of the instantiation process for a Progress bar
[11:24:45 CDT(-0500)] <colinclark> The other thing that's interesting is that Progress' tests are all failing, too
[11:24:50 CDT(-0500)] <colinclark> Which actually simplifies things a lot for us
[11:25:03 CDT(-0500)] <colinclark> We know now that this error is not Uploader's fault
[11:25:13 CDT(-0500)] <colinclark> In other words, it occurs in isolation, too
[11:28:13 CDT(-0500)] <colinclark> So, mostly, my process is in debugging is pretty ad-hoc
[11:28:29 CDT(-0500)] <colinclark> I'm sticking a breakpoint at the point where we instantiate a Progress component, and then diving in
[11:28:38 CDT(-0500)] <colinclark> into fluid.initView()
[11:28:49 CDT(-0500)] <colinclark> into fluid.initLittleComponent
[11:29:08 CDT(-0500)] <colinclark> but I know to go deeper by simply stepping through code and watching the state of things and waiting for the error to actually occur
[11:29:21 CDT(-0500)] <colinclark> So I was able to see right away that inside fluid.Progress(), the error was happening inside fluid.initView()
[11:29:38 CDT(-0500)] <colinclark> and then, next, realizing that the error was happening somewhere inside fluid.initLittleComponent()
[11:29:52 CDT(-0500)] <colinclark> now I'm to the point where I can see the error is occurring sometime during options merging
[11:30:33 CDT(-0500)] <colinclark> In other words, the call to fluid.mergeComponentOptions() inside fluid.initLittleComponent() is failing
[11:30:50 CDT(-0500)] <mlam> yes
[11:33:24 CDT(-0500)] <colinclark> ...now into fluid.expandComponentOptions()
[11:33:34 CDT(-0500)] <colinclark> We're getting right into the guts of the options merging process
[11:39:32 CDT(-0500)] <colinclark> Okay, so I accidentally uncovered half the problem
[11:39:57 CDT(-0500)] <colinclark> The Progress tests suffer from the same problem as HTML5 tests did
[11:40:06 CDT(-0500)] <colinclark> they don't include DataBinding.js, despite being a View
[11:40:20 CDT(-0500)] <colinclark> If I had to guess, the Progress demo has the same problem
[11:40:47 CDT(-0500)] <colinclark> yep
[11:41:27 CDT(-0500)] <mlam> pretty juicy stuff. it was good to follow the process
[11:41:44 CDT(-0500)] <colinclark> Interestingly, we still have a problem
[11:41:55 CDT(-0500)] <colinclark> There's something about the fact that Progress has this viewComponent grade
[11:42:10 CDT(-0500)] <colinclark> Check Progress' options at line 251 of Progress.js
[11:42:23 CDT(-0500)] <colinclark> you'll see that, at some point, Progress was given a grade of View Component
[11:42:27 CDT(-0500)] <colinclark> which makes sense, since it is
[11:42:51 CDT(-0500)] <colinclark> but, it looks to me like, when Progress is instantiated via IoC (as we do for the total progress bar in Uploader), it succeeds
[11:43:01 CDT(-0500)] <colinclark> but when calling fluid.Progress() directly, things are exploding
[11:43:04 CDT(-0500)] <colinclark> I'm not quite clear why yet
[11:45:59 CDT(-0500)] <colinclark> I guess I'm starting to see how yura_ feels, with the earth constantly moving below his feet
[11:46:11 CDT(-0500)] <colinclark> Although, I guess, it's yura_ who asks for the earth to move in the first place
[11:47:36 CDT(-0500)] <yura_> colinclark: i guess so
[11:48:13 CDT(-0500)] <colinclark> Any guesses on what would make a perfectly ordinary component suddenly refuse to merge its options properly when not being invoked via IoC, yura_?
[11:48:22 CDT(-0500)] <mlam> hahaha
[11:49:12 CDT(-0500)] <yura_> colinclark: maybe something to do with grades?
[11:49:22 CDT(-0500)] <yura_> as a wild guess
[11:49:22 CDT(-0500)] <colinclark> yes, definitely that
[11:49:33 CDT(-0500)] <colinclark> yura_: The component has a grade of fluid.viewComponent
[11:49:40 CDT(-0500)] <colinclark> when I remove this grade, happiness
[11:49:57 CDT(-0500)] <colinclark> but of course, removing the grade will presumably cause unhappiness in cases where we were instantiating it via IoC
[11:50:59 CDT(-0500)] <yura_> do the options correspond to the argument map of view component?
[11:51:03 CDT(-0500)] <yura_> colinclark: ^
[11:51:11 CDT(-0500)] <colinclark> good question
[11:51:19 CDT(-0500)] <colinclark> yes, they do
[12:40:18 CDT(-0500)] <Bosmon2> mlam, colinclark: Sorry to break the tests
[12:40:25 CDT(-0500)] <colinclark> Ah, you've arrived
[12:40:34 CDT(-0500)] <colinclark> I was seconds away from going for lunch
[12:40:36 CDT(-0500)] <Bosmon2> Somehow it didn't occur to me that the FLUID-4165 fix could break anything elsewhere, since it was a fix primarily to rendererComponent
[12:40:38 CDT(-0500)] <colinclark> but I'll stay and we can chat
[12:40:41 CDT(-0500)] <Bosmon2> I will fix it up now
[12:40:45 CDT(-0500)] <colinclark> So, I guess there are two things
[12:41:07 CDT(-0500)] <colinclark> We introduced the requirement for all View components to link to DataBinding.js
[12:41:08 CDT(-0500)] <colinclark> which seems fine
[12:41:30 CDT(-0500)] <colinclark> Do you know what the problem with Progress is? It's clearly happening deep within the options expansion machinery
[12:42:00 CDT(-0500)] <Bosmon2> I can't imagine what it is, but I will know very soon...
[12:42:02 CDT(-0500)] <colinclark> And, I guess my last question-or comment-is that this sort of dovetails in an intriguing way with mlam's mission to write comprehensive integration tests for Uploader
[12:42:06 CDT(-0500)] <colinclark> I was mulling it over this morning
[12:42:12 CDT(-0500)] <colinclark> But this seems to be a category of problems
[12:42:23 CDT(-0500)] <colinclark> a component instantiated on its own vs. via IoC
[12:42:38 CDT(-0500)] <colinclark> And I guess it raises the question "should a component's own tests cover that?"
[12:42:55 CDT(-0500)] <colinclark> I've looked over your test code in the Uploader demo
[12:43:10 CDT(-0500)] <colinclark> and there's a part of me that wonders why Uploader itself should be testing these variations at all
[12:43:24 CDT(-0500)] <colinclark> I mean, I get the pragmatic reason, specific to the Uploader
[12:43:38 CDT(-0500)] <Bosmon2> Well, "in theory" this could be covered by yet more tests covering the framework itself
[12:43:47 CDT(-0500)] <colinclark> yeah
[12:43:58 CDT(-0500)] <colinclark> in the big picture, this is something all components are subject to
[12:44:11 CDT(-0500)] <Bosmon2> But it would be hard to tell "what particularly" about the Uploader, a particularly complex piece of IoC-driven machinery, is being exercised by any test case failing to cover all of it
[12:45:06 CDT(-0500)] <colinclark> But I guess the point we're seeing here is that, in absence of "theoretical tests," every component now needs to, for itself, be tested in various IoC and non-IoC configurations
[12:45:43 CDT(-0500)] <Bosmon2> Well, I guess we just need "even more theoretical tests"
[12:45:44 CDT(-0500)] <colinclark> Which I find slightly unsettling, if clearly useful
[12:45:53 CDT(-0500)] <colinclark> ok
[12:46:02 CDT(-0500)] <Bosmon2> I will add some now to prevent this particular regression
[12:46:08 CDT(-0500)] <colinclark> So Uploader, due to its complexity and status, should implement these sorts of tests itself
[12:46:23 CDT(-0500)] <colinclark> and in the long run we will hope for greater framework-level coverage to benefit other components
[12:46:57 CDT(-0500)] <colinclark> After the dev meeting, I'll walk mlam through recreating your demo tests as unit tests for Uploader
[12:47:06 CDT(-0500)] <colinclark> I really had to struggle through that code
[12:47:28 CDT(-0500)] <colinclark> it's the sort of stuff we'll never expect newcomers to be able to handle
[12:47:52 CDT(-0500)] <colinclark> if anything, it's an active repellent to IoC
[12:48:05 CDT(-0500)] <colinclark> "That stuff's great in theory, but it's so complex, why would I bother?"
[12:48:07 CDT(-0500)] <colinclark> that sort of thing
[12:48:13 CDT(-0500)] <Bosmon2> Yes
[12:48:15 CDT(-0500)] <Bosmon2> That sort of thing
[12:48:35 CDT(-0500)] <Bosmon2> But perhaps, test cases are, and should be, some of the MORE complex code we have to write
[12:49:28 CDT(-0500)] <colinclark> I'm okay with that
[12:52:21 CDT(-0500)] <colinclark> But I guess the thing you and I need to remember...
[12:52:37 CDT(-0500)] <colinclark> is that there are currently three people in the universe who could actually write such unit tests in short order
[12:52:42 CDT(-0500)] <colinclark>
[12:52:53 CDT(-0500)] <colinclark> Maybe only two, I just like to flatter myself
[12:56:24 CDT(-0500)] <Bosmon2> "And one of them has just forgotten"
[12:57:03 CDT(-0500)] <Bosmon2> You remember the story about the student at his final interview, where his examiners put him the final question.... "What is electricity?"
[12:57:17 CDT(-0500)] <Bosmon2> He replies... "I'm sorry... I used to know, but I seem to have forgotten"
[12:57:39 CDT(-0500)] <colinclark> lol
[12:57:46 CDT(-0500)] <colinclark> I must have forgotten that one
[12:58:14 CDT(-0500)] <colinclark> okay, i'm going to grab a samwich and will be back shortly
[12:58:24 CDT(-0500)] * colinclark 's sandwich
[12:58:31 CDT(-0500)] <Bosmon2> The examiner turns round to his colleagues and says... "Gentlemen! This is an extremely sad day! Since... as of yesterday, there were just three men in the world who understood what electricity is.... and now, it seems, that one of them, has FORGOTTEN!"
[12:58:39 CDT(-0500)] <colinclark>
[13:00:50 CDT(-0500)] <Bosmon2> I guess it feels like there are a lot of IoC tests, but I guess, numerically, really there aren't
[13:01:03 CDT(-0500)] <Bosmon2> The test file is only 100 lines longer than the implementation file
[13:01:12 CDT(-0500)] <Bosmon2> Whereas I guess, as a ballpark guide, it should really be about 3x as long
[13:40:13 CDT(-0500)] <michelled> fluid-everyone: is there anyone how wants to join the dev meeting through skype?
[13:41:03 CDT(-0500)] <michelled> Avipar, pulkit: everyone is invited to the dev meeting if you are interested in joinging
[13:41:08 CDT(-0500)] <michelled> joining
[13:41:41 CDT(-0500)] <Avipar> aah sure
[13:41:42 CDT(-0500)] <Avipar>
[13:41:50 CDT(-0500)] <Avipar> dev meeting
[13:42:09 CDT(-0500)] <michelled> you can send me your skype name privately and I'll add you
[15:09:25 CDT(-0500)] <Bosmon2> colinclark, Justin_o, all
[15:09:33 CDT(-0500)] <colinclark> yes?
[15:09:34 CDT(-0500)] <Bosmon2> So I committed a small change to qunit just now
[15:09:44 CDT(-0500)] <Bosmon2> Along with my fix for the breakage of most of Uploader
[15:10:06 CDT(-0500)] <Bosmon2> Which gets around an issue I have frequently found extremely annoying... that a call to "expect" is not cumulative
[15:10:19 CDT(-0500)] <Bosmon2> Somehow you have to apprehend up front the total number of test cases a function is going to issue
[15:10:25 CDT(-0500)] <Bosmon2> Which makes it very hard to write them in composable units
[15:12:57 CDT(-0500)] <Justin_o> Bosmon2: i think this should have gone into jqunit
[15:14:16 CDT(-0500)] <Bosmon2> Justin_o: in what way?
[15:14:54 CDT(-0500)] <Justin_o> well.. when we update qunit again you'll lose your new feature
[15:14:57 CDT(-0500)] <Bosmon2> It could have gone into jqunit, if we decided to "deprecate" the use of the unnamespaced functions that qunit makes
[15:15:15 CDT(-0500)] <Bosmon2> I actually made a namespaced pass-through for expect()
[15:15:19 CDT(-0500)] <Justin_o> Bosmon2: we could start using jqunit.expect
[15:15:22 CDT(-0500)] <colinclark> Can we put it into a jqUnit.expect()?
[15:15:24 CDT(-0500)] <Bosmon2> But thought it would be too much to patch everything
[15:15:32 CDT(-0500)] <Bosmon2> Yes, I made a jQunit.expect()
[15:15:37 CDT(-0500)] <colinclark> ah, great
[15:15:42 CDT(-0500)] <Bosmon2> If we agree to deprecate the use of the unnamed functions, we can move the implementation
[15:15:46 CDT(-0500)] <colinclark> I think we should just deprecate use of expect()
[15:15:47 CDT(-0500)] <colinclark> yes
[15:15:49 CDT(-0500)] <colinclark> +1
[15:15:52 CDT(-0500)] <Bosmon2> cool
[15:15:58 CDT(-0500)] <colinclark> For the record, I was thinking this weekend just how useless expect() is for exactly the reason you state
[15:16:00 CDT(-0500)] <Justin_o> i'm +1 for not using expect anymore
[15:16:14 CDT(-0500)] <colinclark> I mean, I'm probably writing a whack of tests. How could I possibly know up front how many there will be?
[15:16:20 CDT(-0500)] <colinclark> Or, alternatively, I'm adding new tests
[15:16:23 CDT(-0500)] <colinclark> Same question
[15:16:41 CDT(-0500)] <Justin_o> colinclark: i think it's really useful for testing if a an event occurs or something like that
[15:16:49 CDT(-0500)] <Justin_o> where the test just may not happen if there is a problem
[15:16:53 CDT(-0500)] <colinclark> right
[15:17:00 CDT(-0500)] <colinclark> i agree with that
[15:17:22 CDT(-0500)] <Justin_o> i don't really think its that useful when you know all the tests will run
[15:17:40 CDT(-0500)] <Justin_o> I don't think we need to use it then, sometimes it just becomes a burden to keep up to date
[15:18:09 CDT(-0500)] <Bosmon2> Justin_o: I think we are all agreeing that it continues to be useful
[15:18:15 CDT(-0500)] <Bosmon2> it is made more useful by being cumulative
[15:20:59 CDT(-0500)] <colinclark> yes
[15:21:06 CDT(-0500)] <Bosmon2> So, yura_ is just discussing with me an issue which sheds some interesting light on the issue of... "should we code with giant renderer trees, or with IoC trees"
[15:21:18 CDT(-0500)] <colinclark> The latter!
[15:21:41 CDT(-0500)] <colinclark> Bosmon2, mlam: Do you have a few minutes to chat about Uploader testing here in the channel?
[15:21:45 CDT(-0500)] <Bosmon2> That's a most unsocratic remark
[15:21:49 CDT(-0500)] <colinclark> lol
[15:21:54 CDT(-0500)] <Bosmon2> Sure, yes
[15:21:55 CDT(-0500)] <mlam> sure
[15:21:59 CDT(-0500)] <colinclark> Once you're done with yura, maybe, Bosmon2?
[15:23:11 CDT(-0500)] <Bosmon2> Well, let's talk Uploader first
[15:23:15 CDT(-0500)] <colinclark> ok
[15:23:23 CDT(-0500)] <colinclark> mlam: Bosmon2 and I were chatting earlier about it
[15:23:35 CDT(-0500)] <mlam> ok
[15:23:42 CDT(-0500)] <colinclark> and I pointed out that there are probably two people on this planet who could reasonably decipher the Uploader demo
[15:23:51 CDT(-0500)] <Bosmon2> "demo"
[15:23:53 CDT(-0500)] <colinclark>
[15:24:11 CDT(-0500)] <colinclark> So, let's maybe walk through it and see if we can figure out how we'd turn that stuff into your unit tests
[15:24:21 CDT(-0500)] <colinclark> and how much coverage we'll want
[15:24:44 CDT(-0500)] <colinclark> I was also arguing that In The Future, we hopefully won't have to write these kinds of tests on a per component basis
[15:24:58 CDT(-0500)] <colinclark> lemme just dig up a link
[15:25:15 CDT(-0500)] <Bosmon2> Hopefully not, no
[15:25:24 CDT(-0500)] <colinclark> Okay, so this is the file: https://github.com/fluid-project/infusion/blob/master/src/webapp/demos/uploader/js/uploader.js
[15:25:27 CDT(-0500)] <Bosmon2> Once we have 5000 lines of test cases for FluidIoC, it should no longer be necessary
[15:25:40 CDT(-0500)] <colinclark> So, we can probably just start by skimming it to see what it does
[15:25:45 CDT(-0500)] <colinclark> since all the details are pretty complex
[15:25:53 CDT(-0500)] <colinclark> I see three things...
[15:25:55 CDT(-0500)] <colinclark> three buttons
[15:26:12 CDT(-0500)] <colinclark> In the HTML: https://github.com/fluid-project/infusion/blob/master/src/webapp/demos/uploader/html/uploader.html
[15:26:23 CDT(-0500)] <colinclark> 1. "Concrete Uploader"
[15:26:29 CDT(-0500)] <colinclark> 2. "IoC-driven Uploader"
[15:26:37 CDT(-0500)] <colinclark> 3. "IoC-driven Uploader with demands"
[15:26:49 CDT(-0500)] <colinclark> These represent three different ways in which someone might instantiate an Uploader
[15:27:09 CDT(-0500)] <colinclark> Case #1 being a plain old function call, like, "fluid.uploader(container, options)"
[15:27:18 CDT(-0500)] <colinclark> Case #2 being how yura_ uses the Uploader
[15:27:33 CDT(-0500)] <colinclark> In other words, the Uploader a subcomponent for one of his components
[15:27:41 CDT(-0500)] <colinclark> meaning he's got a demands block somewhere for it
[15:27:48 CDT(-0500)] <colinclark> Is that about right, Bosmon2?
[15:28:09 CDT(-0500)] <Bosmon2> Yes
[15:28:20 CDT(-0500)] <colinclark> I guess case #3 is the one with the demands block
[15:28:29 CDT(-0500)] <colinclark> Case #2 is no demands block, but configured as a subcomponent
[15:28:31 CDT(-0500)] <Bosmon2> #3 is how yura_ WANTS to use the uploader
[15:28:36 CDT(-0500)] <colinclark> ah, okay
[15:28:38 CDT(-0500)] <Bosmon2> But couldn't, becuase there was previously a framework fault
[15:28:44 CDT(-0500)] <Bosmon2> #2 is how he currently uses it in practice
[15:29:01 CDT(-0500)] <colinclark> So, the demands block for case #3 is a lines 74-79, right Bosmon2
[15:29:02 CDT(-0500)] <colinclark> ?
[15:29:35 CDT(-0500)] <colinclark> mlam: you can see that the demands block is setting up a container and some options for the component
[15:29:57 CDT(-0500)] <colinclark> So case #1 is closest to what you are doing currently, I think.
[15:29:58 CDT(-0500)] <mlam> yes
[15:30:09 CDT(-0500)] <mlam> right
[15:30:35 CDT(-0500)] <colinclark> Except it's missing a bit of coverage--testing the resolution of the uploaderImpl (i.e. either multiFileUploader or singleFileUploader), as well as the strategy
[15:30:50 CDT(-0500)] <colinclark> Thing is, the strategy part is a bit more complex...
[15:31:09 CDT(-0500)] <colinclark> since we want our unit tests to run equally in IE and FF, without having to write if statements in the unit test itself
[15:31:42 CDT(-0500)] <colinclark> So, Bosmon2, we're going to have to take the progressive checker out of the equation here, right?
[15:31:57 CDT(-0500)] <colinclark> Since it's the thing that is responsible for checking the features of the browser
[15:32:43 CDT(-0500)] <Bosmon2> I guess in a way, yes
[15:32:51 CDT(-0500)] <Bosmon2> We will actually need to write a "mock" for the progressive checker
[15:33:06 CDT(-0500)] <Bosmon2> Similar to the way we need to write a mock for the "bare metal" at the other end, HTML5 and SWF
[15:34:39 CDT(-0500)] <colinclark> Okay
[15:34:55 CDT(-0500)] <colinclark> So, mlam, do you know how the progressiveChecker works?
[15:34:58 CDT(-0500)] <colinclark> It's sort of an odd bird
[15:35:48 CDT(-0500)] <colinclark> lemme just dig up the code
[15:36:11 CDT(-0500)]

[15:37:01 CDT(-0500)] <colinclark> in a way, that's really the key thing
[15:37:46 CDT(-0500)] <colinclark> So the ProgressiveEnhancement file, as you say, dumps context names into the staticEnvironment based on the features it detects in the browser
[15:38:18 CDT(-0500)] <colinclark> The ProgressiveChecker's job, funnily enough, is to read those context names and put out some other ones
[15:38:34 CDT(-0500)] <colinclark> So the options at line 58 of ProgressiveEnhancement.js show a bit about how it's configured
[15:39:11 CDT(-0500)] <colinclark> it takes a series of feature names (in order), and will output another, single name as a result
[15:39:11 CDT(-0500)] <mlam> Yes, I see them now. I see how the progressive checks work, but I'm not sure how these values are passed around with IoC
[15:40:12 CDT(-0500)] <colinclark> I'm just reminding myself of all this
[15:40:15 CDT(-0500)] <colinclark> you're miles ahead of me
[15:40:28 CDT(-0500)] <colinclark> So I see at line 338 of Uploader.js https://github.com/fluid-project/infusion/blob/master/src/webapp/components/uploader/js/Uploader.js
[15:41:00 CDT(-0500)] <colinclark> in order, I guess the Uploader is saying "if you find that the browser supports binary XHR, then output the context name 'fluid.uploader.html5'"
[15:41:15 CDT(-0500)] <colinclark> "otherwise, output 'fluid.uploader.swfUpload'"
[15:41:22 CDT(-0500)] <colinclark> Despite having written this, it's pretty fuzzy for me
[15:41:29 CDT(-0500)] <colinclark> Bosmon2, mlam: I'm right so far?
[15:41:34 CDT(-0500)] <mlam> Yes
[15:41:50 CDT(-0500)] <Bosmon2> Yes, that's right
[15:42:04 CDT(-0500)] <colinclark> Okay, so
[15:42:13 CDT(-0500)] <colinclark> Let's say we're running this test on IE
[15:42:39 CDT(-0500)] <colinclark> The ProgressiveEnhancement.js file will never put the supportsBinaryXHR context name into the static environment
[15:43:06 CDT(-0500)] <colinclark> So would we want, in our test, to just stick that context name in ourselves, and then see if everything runs correctly?
[15:43:30 CDT(-0500)] <colinclark> That seems like the easiest path to getting a stable test for that whole resolution path
[15:43:35 CDT(-0500)] <colinclark> Bosmon2: Thoughts?
[15:44:31 CDT(-0500)] <Bosmon2> Yes, that's right
[15:44:34 CDT(-0500)] <colinclark> cool
[15:44:35 CDT(-0500)] <colinclark> that's easy
[15:44:39 CDT(-0500)] <colinclark> so, mlam
[15:44:40 CDT(-0500)] <Bosmon2> Really, we need to loop through all possible context names
[15:44:40 CDT(-0500)] <colinclark> I think
[15:44:48 CDT(-0500)] <colinclark> how come?
[15:44:50 CDT(-0500)] <Bosmon2> Or rather, all possible outputs of the genuine progressiveEnhancer
[15:45:02 CDT(-0500)] <colinclark> wouldn't those be separate tests?
[15:45:04 CDT(-0500)] <Bosmon2> Yes
[15:45:07 CDT(-0500)] <Bosmon2> Those would be separate tests
[15:45:09 CDT(-0500)] <colinclark> ok
[15:45:23 CDT(-0500)] <colinclark> So I imagine, mlam, that you should be able to take your current test...
[15:45:31 CDT(-0500)] <colinclark> and make it test the whole thing by just doing that.
[15:45:48 CDT(-0500)] <colinclark> Fake the browser's features by putting that binaryXHR tag into the static environment
[15:45:54 CDT(-0500)] <colinclark> then call fluid.uploader()
[15:45:56 CDT(-0500)] <colinclark> and see if it worked
[15:46:26 CDT(-0500)] <colinclark> The second variation on that test would be to ensure that the supportsBinaryXHR tag isn't in the static environment
[15:46:33 CDT(-0500)] <colinclark> and check that we get a working version of the Flash Uploader
[15:46:36 CDT(-0500)] <colinclark> and so on
[15:46:46 CDT(-0500)] <colinclark> So that would get you coverage on the first of the three buttons in the demo, I think.
[15:47:40 CDT(-0500)] <mlam> I see. So referring to this specific example of IE, this test would reside in the SWF upload test file?
[15:48:01 CDT(-0500)] <colinclark> Nope, these tests probably all belong in the Uploader tests file
[15:48:07 CDT(-0500)] <colinclark> In other words, they're general Uploader tests
[15:48:13 CDT(-0500)] <mlam> Ah ok
[15:48:19 CDT(-0500)] <colinclark> You could split the tests up, but they're probably better off in one place
[15:48:27 CDT(-0500)] <colinclark> Just to make it easy to understand what's going on
[15:48:29 CDT(-0500)] <mlam> Ok, makes sense
[15:48:53 CDT(-0500)] <colinclark> So, the second case is a bit more complex
[15:49:31 CDT(-0500)] <colinclark> Take a look at lines 52-63 of uploader.js (the demo file)
[15:49:41 CDT(-0500)] <colinclark> Notice the defaults block
[15:49:59 CDT(-0500)] <colinclark> and, based on the dev meeting today, you'll remember that in order to create a simple component, you don't even need to write code for it anymore
[15:50:09 CDT(-0500)] <colinclark> My first instinct would have been to write a component in code
[15:50:20 CDT(-0500)] <colinclark> something like "fluid.uploader.tests.uploaderParent" or something like that
[15:50:35 CDT(-0500)] <colinclark> Which would have a creator function and then specify fluid.uploader as its child
[15:50:57 CDT(-0500)] <colinclark> Bosmon2's done the same thing at lines 52-63, except he didn't need to make a creator function because he defined it as "autoInit"
[15:51:14 CDT(-0500)] <colinclark> So, his IoCLoader thing is yura_'s component, if you want to think about it that way
[15:51:30 CDT(-0500)] <colinclark> In the case of this demo or your unit test, it's just some object we define as a parent for Uploader
[15:52:40 CDT(-0500)] <colinclark> So, for your second set of tests, you can define some parent component that lists Uploader a subcomponent
[15:52:51 CDT(-0500)] <colinclark> and, once again, test that the Uploader resolves nicely in both contexts
[15:53:05 CDT(-0500)] <colinclark> So, I can imagine these tests will all be built out of smaller testing functions
[15:53:40 CDT(-0500)] <colinclark> You've got essentially three different configurations of Uploader: single file, HTML5, and SWFUpload to test for
[15:53:55 CDT(-0500)] <colinclark> and then another dimension: how Uploader is instantiated
[15:54:12 CDT(-0500)] <colinclark> three choices there, too: plain function call, plain subcomponent, subcomponent with demands block
[15:54:17 CDT(-0500)] <colinclark> mlam: Making any sense?
[15:54:26 CDT(-0500)] <Justin_o> colinclark, Bosmon2: the tooltip unit tests are broken
[15:54:36 CDT(-0500)] <Justin_o> it looks like the same thing as the uploader ones
[15:54:42 CDT(-0500)] <colinclark> Justin_o: Okay
[15:54:47 CDT(-0500)] <colinclark> Can you do me a favour?
[15:54:57 CDT(-0500)] <colinclark> File a quick JIRA about "All Views must now link to DataBinding.js"
[15:55:03 CDT(-0500)] <colinclark> and then I have a couple of changes I'll make under it
[15:55:06 CDT(-0500)] <colinclark> including tooltip
[15:55:24 CDT(-0500)] <Bosmon2> Ok... I'm surprised we didn't actually have this dependency already
[15:55:42 CDT(-0500)] <mlam> Yes, it's making sense. So to be sure, the 2nd round of tests of the uploader as a subcomponent is to essential test what yura_ is doing with the uploader in cspace, right?
[15:55:42 CDT(-0500)] <colinclark> It was only necessary in the case of a View component that used the Renderer
[15:56:01 CDT(-0500)] <colinclark> plain View components never needed anything in DataBinding.js until late last night
[15:56:03 CDT(-0500)] <Justin_o> colinclark: will do.. i'll let you know when it's up
[15:56:10 CDT(-0500)] <colinclark> mlam: Yep, you've got it
[15:56:19 CDT(-0500)] <colinclark> Those are the tests I was arguing we shouldn't have to write
[15:56:24 CDT(-0500)] <colinclark> but for now, Uploader is a trail blazer
[15:56:32 CDT(-0500)] <Justin_o> colinclark, Bosmon2: so now DataBinding.js is a dependency for all components?
[15:56:39 CDT(-0500)] <Justin_o> Infusion components that is
[15:56:42 CDT(-0500)] <colinclark> Justin_o: All Model components, to be precise
[15:56:57 CDT(-0500)] <colinclark> And View components are Model components
[15:57:08 CDT(-0500)] <Bosmon2> Ok yes, I see how this happened now
[15:57:18 CDT(-0500)] <Bosmon2> And it was actually a "temporary inconsistency"
[15:57:28 CDT(-0500)] <Bosmon2> This SHOULD have been a dependence for all view component, as a result of being model-bearing components
[15:57:32 CDT(-0500)] <colinclark> mlam: So, go for it and do hesitate to ping me or Bosmon2 if you have any questions or need clarification
[15:57:42 CDT(-0500)] <colinclark> you're right in the thick of learning how IoC works in practice
[15:57:44 CDT(-0500)] <Bosmon2> Actually I should reverse this
[15:57:53 CDT(-0500)] <Bosmon2> Well, it is pretty awkward....
[15:57:55 CDT(-0500)] <colinclark> Bosmon2: ?
[15:58:00 CDT(-0500)] <Bosmon2> EITHER view components have a contract, or they don't
[15:58:12 CDT(-0500)] <mlam> colinclark: for the first set of tests, could I not just set the defaultTypeTag to be any one of the strategies? line 349 of Uploader.js
[15:58:15 CDT(-0500)] <Bosmon2> If they have a contract... you would expect it should comprise having a changeApplier
[15:58:38 CDT(-0500)] <Bosmon2> But before now, this was not something that was "done for them" UNLESS they declared autoInit
[15:58:55 CDT(-0500)] <Bosmon2> So what we actually had was an inconsistency in the contract of view components, depending on whether they declared autoInit or not
[15:59:20 CDT(-0500)] <colinclark> mlam: You could, but then you're not getting full coverage. You're short-circuiting part of the resolution process
[15:59:30 CDT(-0500)] <colinclark> so you really need to work right at the topmost layer of IoC resolution here
[15:59:36 CDT(-0500)] <colinclark> which is those feature type tags
[15:59:55 CDT(-0500)] <colinclark> supportsBinaryXHR for HTML5, supportsFlash for SWFUpload, and neither of them for the single file uploader
[16:00:09 CDT(-0500)] <colinclark> This is, to be clear, not a unit test
[16:00:22 CDT(-0500)] <colinclark> It's an integration test--it shows that the whole Uploader, in the real world, actually works
[16:00:36 CDT(-0500)] <colinclark> Meaning, the next time Bosmon2 makes seismic changes to the frameworks, he'll see a red bar
[16:00:43 CDT(-0500)] <Bosmon2>
[16:01:01 CDT(-0500)] <colinclark> Or, equally, the next time I commit a half-baked feature to Uploader, I'll see them, too
[16:01:44 CDT(-0500)] <mlam> right
[16:02:33 CDT(-0500)] <Justin_o> colinclark: here's a not great jira http://issues.fluidproject.org/browse/FLUID-4169
[16:02:39 CDT(-0500)] <Justin_o> feel free to modify it
[16:02:45 CDT(-0500)] <colinclark> Thanks Justin_o
[16:02:49 CDT(-0500)] <colinclark> Let me make those changes now
[16:04:45 CDT(-0500)] <Bosmon2> Thanks guys - sorry for the unanticipated extra dependency
[16:05:23 CDT(-0500)] <Justin_o> Bosmon2: no problem... it's good that we have all this new framework stuff and that it's in so early
[16:06:03 CDT(-0500)] <colinclark> Thank goodness for the Builder
[16:18:33 CDT(-0500)] <Justin_o> colinclark: i wonder if we'll be able to use the builder to one day assemble the pieces for FLOE
[16:18:52 CDT(-0500)] <colinclark> interesting
[16:18:57 CDT(-0500)] <colinclark> how so, Justin_o?
[16:20:47 CDT(-0500)] <colinclark> I really liked your answer about "What is Infusion for?" today in the dev meeting, Justin_o
[16:20:54 CDT(-0500)] <colinclark> especially on the spot
[16:20:58 CDT(-0500)] <Justin_o> colinclark: so if we think of floe as a collection of infrastructural resources, infusion + kettle + other things.. it might be nice to come to one place to get all the pieces you need.. and maybe some of those pieces are optional or replacable so you may not want a single package
[16:21:06 CDT(-0500)] <colinclark> ahh
[16:21:09 CDT(-0500)] <Justin_o> colinclark: thanks.. i wasn't sure if i was doing a good job
[16:21:10 CDT(-0500)] <mlam> colinclark: so by fooling the static environment of a browser's features, am i overriding the progressiveChecker demands block?
[16:21:26 CDT(-0500)] <colinclark> mlam: You don't need to, no
[16:21:29 CDT(-0500)] <colinclark> They should stay the same
[16:21:50 CDT(-0500)] <colinclark> In practice, you're just faking the browser environment
[16:22:17 CDT(-0500)] <colinclark> causing IoC to match "abstract types" like fluid.uploader.remote to a particular concrete implementation
[16:22:31 CDT(-0500)] <colinclark> such as fluid.uploader.html5Strategy.remote or whatever
[16:23:10 CDT(-0500)] <colinclark> So, really, all your test needs to do is mess with the static environment, and everything else will just happen for you
[16:23:24 CDT(-0500)] <colinclark> Take that, if statement!
[16:25:51 CDT(-0500)] <colinclark> You know, Justin_o, I was thinking about the channel just now
[16:26:06 CDT(-0500)] <colinclark> It seems to me that if mlam and I hadn't been chatting in the channel--despite being practically in the same room
[16:26:17 CDT(-0500)] <colinclark> you probably would have had no idea why the Tooltip tests were failing
[16:26:24 CDT(-0500)] <colinclark> It's a bizarre world we live in
[16:26:47 CDT(-0500)] <Justin_o> colinclark:
[16:27:01 CDT(-0500)] <Justin_o> it's a handy tool
[16:27:34 CDT(-0500)] <mlam> ack, so colinclark, the static environment is set in the uploaderContext in line 327 of Uploader.js, right?
[16:27:54 CDT(-0500)] <colinclark> mlam: It's actually not
[16:28:00 CDT(-0500)] <colinclark> The static environment is just there
[16:28:07 CDT(-0500)] <colinclark> It's just an object defined in Fluid.js
[16:28:11 CDT(-0500)] <colinclark> and it's global
[16:28:15 CDT(-0500)] <colinclark> So you can write to it freely
[16:28:20 CDT(-0500)] <colinclark> Meaning, all you have to do is something like this:
[16:30:07 CDT(-0500)] <colinclark> fluid.staticEnvironment.supportsBinaryXHR = fluid.typeTag("fluid.browser.supportsBinaryXHR");
[16:31:16 CDT(-0500)] <Bosmon2> In the future, it should not be like that... but this is unfortunately the tasteless thing we do right now
[16:31:28 CDT(-0500)] <colinclark> Yes, in the future, our code will break for doing this
[16:31:37 CDT(-0500)] <colinclark> and then we'll have to change it in sheepishly
[16:31:39 CDT(-0500)] <Bosmon2> Although it is good to emphasise the fact that the static environment is just an "object"
[16:31:53 CDT(-0500)] <Bosmon2> I mean, it is just a "thing full of stuff"
[16:31:59 CDT(-0500)] <colinclark> mlam: In terms of seeing where this is done elsewhere, take a look at ProgressiveEnhancement.js
[16:32:16 CDT(-0500)] <Bosmon2> It seems silly to give it an API, but I guess in time it should have one
[16:32:26 CDT(-0500)] <colinclark>
[16:32:35 CDT(-0500)] <colinclark> I guess it's like the lesson you taught me, way back in the day
[16:32:39 CDT(-0500)] <colinclark> what was that with?
[16:32:42 CDT(-0500)] <colinclark> log or something?
[16:32:42 CDT(-0500)] <Bosmon2> logging?
[16:32:44 CDT(-0500)] <Bosmon2> Yes
[16:32:45 CDT(-0500)] <colinclark> yes
[16:33:07 CDT(-0500)] <Bosmon2> For some things, disagreeable though it is, it's hard to avoid the need for an "API"
[16:33:30 CDT(-0500)] <mlam> colinclark: so what's fluid.environment?
[16:33:33 CDT(-0500)] <Bosmon2> Even though we try to restrict their use as much as possible
[16:34:11 CDT(-0500)] <Bosmon2> "environment" is a special object we use in order to coordinate uses of multiple versions of the "fluid" namespace
[16:34:16 CDT(-0500)] <Bosmon2> It's unrelated to IoC
[16:34:59 CDT(-0500)] <Bosmon2> Well, at least, it's unrelated to IoC resolution
[16:35:22 CDT(-0500)] <Bosmon2> It is what makes sure that when you mention a global name like "fluid.inlineEdit".... you have some idea what "fluid" means
[16:35:32 CDT(-0500)] <mlam> ah ok, thanks Bosmon2
[16:36:02 CDT(-0500)] <Bosmon2> It you think about it, you realise this is not a terribly easy question - there is one answer which relates to "What does "fluid" refer to in as a current value in the global namespace"
[16:36:02 CDT(-0500)] <colinclark> IoC has three different "scopes" or environments for resolution, right Bosmon2?
[16:36:06 CDT(-0500)] <Bosmon2> But that is not always the right answer
[16:36:18 CDT(-0500)] <colinclark> The static environment, the dynamic environment, and the "tree of instantiating components"
[16:36:22 CDT(-0500)] <Bosmon2> That's right
[16:36:33 CDT(-0500)] <Bosmon2> Although the first 2 can be seen as just special kinds of "component" which are always there
[16:36:33 CDT(-0500)] <colinclark> Do you have a less awkward name for the third?
[16:36:42 CDT(-0500)] <Bosmon2> In fact, we will probably discourage the use of the 2nd one now
[16:36:56 CDT(-0500)] <colinclark> I've never felt the need to use the second one
[16:37:03 CDT(-0500)] <colinclark> What was it designed for?
[16:37:05 CDT(-0500)] <Bosmon2> Leaving just the "static environment" and the currently instantiating tree
[16:37:12 CDT(-0500)] <mlam> so the static environment is IoC specific and it's just a global placeholder of values?
[16:37:27 CDT(-0500)] <colinclark> pretty much, mlam
[16:37:29 CDT(-0500)] <Bosmon2> Well, in the old days, before we had an "instantiator", the dynamic environment was the only way to "dynamically contextualise things"
[16:37:38 CDT(-0500)] <colinclark> You can think of it as a component containing a bunch of other components
[16:37:45 CDT(-0500)] <colinclark> all which of are just really names, in practice
[16:37:48 CDT(-0500)] <Bosmon2> That is, to provide IoC material that you wanted JUST to be in the context of one instantiation, or one piece of code
[16:37:51 CDT(-0500)] <colinclark> which is how Bosmon2 first described it to me
[16:37:55 CDT(-0500)] <colinclark> and i found it immensely unhelpful
[16:38:04 CDT(-0500)] <Bosmon2> But now we DO have the instantiator, the "dynamic environment" is not only largely unnecessary, but also positively dangerous
[16:38:27 CDT(-0500)] <colinclark> I still am trying to fully get my head around what the statement "a type tag is a component" means
[16:38:40 CDT(-0500)] <mlam> I feel like these were questions I should've asked 2-3 months ago
[16:38:41 CDT(-0500)] <Bosmon2> JURA has had to strip out all the uses of the dynamic environment in CSpace, as well as in his test cases
[16:39:08 CDT(-0500)] <colinclark> It requires a sort of Cageian generosity around the definition of the word "component," I think
[16:39:15 CDT(-0500)] <Bosmon2>
[16:39:25 CDT(-0500)] <colinclark> Okay, so the dynamic environment is dead to us
[16:39:33 CDT(-0500)] <Bosmon2> "A component is a unit of computation work with a name"
[16:39:47 CDT(-0500)] <Bosmon2> Well, two names
[16:39:48 CDT(-0500)] <colinclark> Hmm
[16:39:53 CDT(-0500)] <Bosmon2> A "type name", and a "global path"
[16:39:56 CDT(-0500)] <colinclark> It's the "unit of computation" part that gets me
[16:39:59 CDT(-0500)] <Bosmon2> It also has an "id"
[16:40:05 CDT(-0500)] <Bosmon2> Which is a number
[16:40:07 CDT(-0500)] <colinclark> I was going to say, "A component anything with a name"
[16:40:24 CDT(-0500)] <Bosmon2> These are the things which every component has.... a "typeName", and an "id" written on it
[16:40:32 CDT(-0500)] <colinclark> Or, as you say, "A component is anything with a type name and an id"
[16:40:40 CDT(-0500)] <colinclark> I guess the "global path" thing is sort of a separate point
[16:40:51 CDT(-0500)] <Bosmon2> And a component also has a particular path location in the current tree... or, now, several locations
[16:40:53 CDT(-0500)] <Bosmon2> Yes
[16:40:55 CDT(-0500)] <colinclark> Meaning, it is addressable at a global path, Bosmon2?
[16:41:02 CDT(-0500)] <Bosmon2> In itself, it just has those two fields
[16:41:09 CDT(-0500)] <Bosmon2> And anything which has those fields is a "component"
[16:41:27 CDT(-0500)] <Bosmon2> Meaning, the most Cageian kind of component is what is spat out by "fluid.typeTag"
[16:41:33 CDT(-0500)] <Bosmon2> That creates a "component" with JUSt those two fields
[16:41:33 CDT(-0500)] <colinclark> mlam: So, aside from all this blabbing
[16:41:46 CDT(-0500)] <colinclark> The static environment is the place where components or type names can go if they are unchanging
[16:41:59 CDT(-0500)] <colinclark> Another example of something that might live in the static environment is the UI Enhancer
[16:42:02 CDT(-0500)] <Bosmon2> This point creates a difficulty with our test cases
[16:42:05 CDT(-0500)] <colinclark> the thing that UI Options uses to transform a page
[16:42:14 CDT(-0500)] <Bosmon2> Since, in order for the cases to run, we actually need to CHANGE things in the static environment
[16:42:24 CDT(-0500)] <mlam> i c i c
[16:42:28 CDT(-0500)] <colinclark>
[16:42:39 CDT(-0500)] <Bosmon2> This is part of the reason we really need some kind of API..... but right now, it is ok to just blindly bang on the static environment object
[16:42:45 CDT(-0500)] <colinclark> I was just going to ask
[16:43:00 CDT(-0500)] <Bosmon2> but make sure you clean up what you do to it in a "finally" block
[16:43:13 CDT(-0500)] <Bosmon2> It's very important for test cases to be able to run in an isolated way
[16:43:26 CDT(-0500)] <Bosmon2> And not to interfere with the state that each successive test inherits
[16:43:52 CDT(-0500)] <colinclark> ahhhh
[16:43:59 CDT(-0500)] <colinclark> That's actually a good point, mlam
[16:44:09 CDT(-0500)] <colinclark> And the kind of diligence I am typically without
[16:44:20 CDT(-0500)] <colinclark> So, Bosmon2
[16:44:21 CDT(-0500)] <colinclark> To be very clear
[16:44:34 CDT(-0500)] <colinclark> You're saying that the entire test should be wrapped in a try/finally pair?
[16:44:37 CDT(-0500)] <Bosmon2> The static environment is actually the wrong place for this material... it should, with all carefulness, go into a separate "IoC root" just used for the test
[16:44:47 CDT(-0500)] <Bosmon2> I typically do this, when I do bad stuff like that, yes
[16:44:50 CDT(-0500)] <colinclark> and the finally statement would reset the static env?
[16:44:51 CDT(-0500)] <colinclark> ok
[16:44:53 CDT(-0500)] <colinclark> crazy
[16:44:56 CDT(-0500)] <colinclark> I never would have done that
[16:44:59 CDT(-0500)] <colinclark> yet it makes perfect sense
[16:45:12 CDT(-0500)] <colinclark> I guess, alternatively, you could do it in a setup function?
[16:45:17 CDT(-0500)] <colinclark> Wouldn't that be cleaner?
[16:45:19 CDT(-0500)] <Bosmon2> Yes, but I don't trust those
[16:45:22 CDT(-0500)] <colinclark> lol
[16:45:25 CDT(-0500)] <colinclark> Why not?
[16:45:29 CDT(-0500)] <Bosmon2> I REALLY want the static environment to be cleaned up
[16:45:37 CDT(-0500)] <Bosmon2> And visibly cleaned up, for a reason I can have faith in
[16:45:40 CDT(-0500)] <colinclark> You're like me and command line SVN
[16:45:46 CDT(-0500)] <Bosmon2> This is the kind of thing that JSF bought us
[16:45:55 CDT(-0500)] <Bosmon2> "Cleanup" functions that may or may not execute correctly
[16:46:06 CDT(-0500)] <Bosmon2> Depending on the essentially unknowable level of discipline of the framework writer
[16:46:11 CDT(-0500)] <colinclark> Bosmon2: I swear the cleanup function will run reliably
[16:46:16 CDT(-0500)] <Bosmon2> You swear it!
[16:46:25 CDT(-0500)] <colinclark> though, having written the code for them, you shouldn't believe me
[16:46:31 CDT(-0500)] <colinclark> especially since there is no such unit test to verify it
[16:46:37 CDT(-0500)] <colinclark>
[16:46:37 CDT(-0500)] <Bosmon2> You wrote the code for cleanup functions in jqUnit?
[16:46:41 CDT(-0500)] <colinclark> I think so, yes
[16:46:45 CDT(-0500)] <colinclark> QUnit didn't have such things back then
[16:46:49 CDT(-0500)] <colinclark> They're still unsatisfying
[16:47:11 CDT(-0500)] <colinclark> Hopefully I'm not making all this up
[16:47:15 CDT(-0500)] <colinclark> I better go look at the code
[16:47:48 CDT(-0500)] <colinclark> I'm wrong-ish
[16:47:57 CDT(-0500)] <colinclark> It looks like module() had support for them, way back
[16:48:05 CDT(-0500)] <colinclark> I just wrapped it
[16:48:14 CDT(-0500)] <colinclark> Okay, so now you can be assured of its reliability!
[16:48:16 CDT(-0500)] <Bosmon2> You mean "teardown()"?
[16:49:16 CDT(-0500)] <Bosmon2> So.... looking at this code, I see no assurance that teardown() will run reliably
[16:49:21 CDT(-0500)] <colinclark>
[16:49:28 CDT(-0500)] <colinclark> At the QUnit code, you mean?
[16:49:29 CDT(-0500)] <Bosmon2> presumably the idea is that "synchronize" somehow swallows all exceptions
[16:49:30 CDT(-0500)] <Bosmon2> Yes
[16:49:45 CDT(-0500)] <colinclark> QUnit sort of terrifies me
[16:50:00 CDT(-0500)] <colinclark> I dig Jörn a lot, and can't wait to meet him
[16:50:07 CDT(-0500)] <colinclark> but it is a wild Resigian code base
[16:52:46 CDT(-0500)] <colinclark> Justin_o: Couple more DataBinding-related breakages
[16:52:48 CDT(-0500)] <colinclark> InlineEdit demos
[16:52:51 CDT(-0500)] <colinclark> I'll fix 'em
[16:52:51 CDT(-0500)] <Bosmon2> Scraggly, even
[16:53:25 CDT(-0500)] <Justin_o> colinclark: thanks
[16:54:46 CDT(-0500)] <colinclark> Most of the demos, in fact
[16:54:47 CDT(-0500)] <colinclark> fascinating
[16:57:13 CDT(-0500)] <colinclark> Bosmon2: Hate to tell you this
[16:57:19 CDT(-0500)] <colinclark> It looks like Pager's demo is borked
[16:57:27 CDT(-0500)] <colinclark> but not for the lack of DataBinding.js
[17:01:54 CDT(-0500)] <Bosmon2> ok
[17:03:04 CDT(-0500)] <Bosmon2> How so?
[17:03:15 CDT(-0500)] <Bosmon2> I am running the one in src/webapp/demos/pager/demo.html
[17:03:17 CDT(-0500)] <Bosmon2> That one seems to work
[17:04:44 CDT(-0500)] <colinclark> hmm
[17:04:44 CDT(-0500)] <Bosmon2> "Standalone" demo also seems to work
[17:04:49 CDT(-0500)] <colinclark> I wonder what's up here
[17:07:47 CDT(-0500)] <colinclark> Oh well, I'll look at it tomorrow
[17:07:50 CDT(-0500)] <colinclark> I'm going ot hit the road
[17:07:54 CDT(-0500)] <colinclark> have a good night, all