fluid-work IRC Logs-2012-09-20

[08:11:57 CDT(-0500)] <colinclark> hey Justin_o

[08:14:11 CDT(-0500)] <Justin_o> colinclark: hello, good morning

[08:14:44 CDT(-0500)] <colinclark> I'm sorry our chat about persisting JSON in Python trickled off there yesterday

[08:14:54 CDT(-0500)] <colinclark> but I wanted to see if I could help at all with your design

[08:15:46 CDT(-0500)] <Justin_o> colinclark: yah.. the community meeting pretty much ate up all the time..

[08:16:12 CDT(-0500)] <colinclark> What do you think of the idea of rolling a super-mini ChangeApplier?

[08:16:21 CDT(-0500)] <Justin_o> colinclark: the good news is that i couldn't sleep last night so i spent an hour or so in the early morning working on it

[08:16:25 CDT(-0500)] <colinclark> lol

[08:16:28 CDT(-0500)] <colinclark> sorry to hear it

[08:16:30 CDT(-0500)] <Justin_o> but i was at home so i didn't have my setup to test it on

[08:16:45 CDT(-0500)] <Justin_o> i'll try to put something in a pastie one second

[08:17:58 CDT(-0500)] <colinclark> cool

[08:18:18 CDT(-0500)] <Justin_o> colinclark: here's the simple event system http://pastie.org/4759927

[08:19:01 CDT(-0500)] <colinclark> you don't go with the fancy operator overloading

[08:19:06 CDT(-0500)] <colinclark> fair enough

[08:19:24 CDT(-0500)] <Justin_o> colinclark: i'm not really sure it made sense to do +=

[08:19:30 CDT(-0500)] <Justin_o> and -=

[08:19:42 CDT(-0500)] <Justin_o> i figured having more specific control would be easier.

[08:19:43 CDT(-0500)] <colinclark> It might seem more idiomatic if you were a C++ programmer

[08:19:51 CDT(-0500)] <colinclark> I agree, though

[08:21:18 CDT(-0500)] <colinclark> So from the event system, will you roll a little ChangeApplier with a requestChange() method that takes a dictionary?

[08:21:30 CDT(-0500)] <Justin_o> colinclark: this is the start of the changeApplier.. although i realized as i tried to go back to sleep that it wasn't quite right

[08:21:30 CDT(-0500)] <Justin_o> http://pastie.org/4759945

[08:21:32 CDT(-0500)] <colinclark> and fire an modelChanged event from there to a listener that will take care of persistence?

[08:22:25 CDT(-0500)] <colinclark> How is it not quite right, Justin_o, do you think?

[08:23:20 CDT(-0500)] <Justin_o> colinclark: i think i finally understood what Bosmon was saying.. which has to do with ELPaths.. so i'll change this to take in an ELpath instead and method (i.e. add, delete)

[08:23:36 CDT(-0500)] <colinclark> ah, right

[08:23:41 CDT(-0500)] <Justin_o> so in the end, it may only have one actual method on it

[08:23:49 CDT(-0500)] <Justin_o> requestChange

[08:23:51 CDT(-0500)] <colinclark> right

[08:24:05 CDT(-0500)] <colinclark> I'm sorry that you end up having to roll bits of existing infrastructure

[08:24:13 CDT(-0500)] <colinclark> but it's probably a reasonably fun exercise, anyway

[08:24:27 CDT(-0500)] <colinclark> I'd love to chat more about your designs, too...

[08:24:44 CDT(-0500)] <colinclark> I was really impressed to hear you evaluating the goals of your design in the channel yesterday

[08:25:18 CDT(-0500)] <colinclark> that "self-persistent model object" design is one I used to encounter a lot in Java, with more interesting consequences

[08:25:35 CDT(-0500)] <colinclark> the fact that you're already a JSONist helped to deflect most of the pain you would have felt...

[08:25:57 CDT(-0500)] <colinclark> if you were thinking more traditionally in Object Oriented terms, you would have, long ago, modelled all your data as typed object

[08:26:03 CDT(-0500)] <colinclark> probably with lots of getters and setters

[08:26:22 CDT(-0500)] <colinclark> and then you'd be inserting this self-persistence logic as a base class for all your model types

[08:26:41 CDT(-0500)] <colinclark> shoe-horning in the save() functionality into each of your setters or whatever

[08:27:44 CDT(-0500)] <Justin_o> colinclark: yah.. i wouldn't want to do that..

[08:28:15 CDT(-0500)] <colinclark> If you look at how persistence is done in most frameworks, there are sort of two categories

[08:28:33 CDT(-0500)] <colinclark> the object/relational mappers I encountered in Java typically had a separate object that was the central point for persistence

[08:28:48 CDT(-0500)] <colinclark> like Hibernate's Session or, back in the old days, WebObjects had the "EOEditingContext"

[08:29:01 CDT(-0500)] <colinclark> which implemented methods for saving and the like

[08:29:24 CDT(-0500)] <colinclark> and then you'd probably roll your own "Data Access Object" layer to accompany it

[08:29:47 CDT(-0500)] <colinclark> michelled can probably remember the kinds of DataManagers and the like that would take the responsibility for persisting different types of data

[08:30:02 CDT(-0500)] <colinclark> again, much of it mitigated in your distinctly less typeful view of the world, Justin_o

[08:30:20 CDT(-0500)] <colinclark> In "client-side" APIs, you typically see an event system of some kind

[08:30:47 CDT(-0500)] <colinclark> some kind of observation of changes on objects to deal with state changes and the "side-effect" of the need to persist them

[08:31:20 CDT(-0500)] <colinclark> Cocoa and iOS have key/value coding, which has some analogs to our system

[08:31:36 CDT(-0500)] <colinclark> in that it's path-based, allowing you to traverse a graph of related objects using "key paths"

[08:32:01 CDT(-0500)] <colinclark> but then, if I remember, persistence ends up in the older pattern of having a CoreDataContext or something similar

[08:32:06 CDT(-0500)] <colinclark> been a while

[08:34:08 CDT(-0500)] <colinclark> I guess it's called the ManagedObjectContext in CoreData

[08:34:17 CDT(-0500)] <colinclark> which tells you a lot about the philosophy of its designm

[09:58:10 CDT(-0500)] <Justin_o> yura1, anastasiac: do you remember what fluid.get returns of the elpath doesn't exist?

[09:58:27 CDT(-0500)] <anastasiac> hm

[09:58:48 CDT(-0500)] <yura1> undefined

[09:58:58 CDT(-0500)] <anastasiac> good question, no, and the docs don't say. I'll have to fix that. Thanks for pointing it out

[09:59:43 CDT(-0500)] <Justin_o> anastasiac, yura1: thanks

[10:25:24 CDT(-0500)] <Justin_o> yura1: do you know if i'm reading this correctly, if i want to perform a deletion of part of the model with the changeApplier, i still need to pass in a value?

[10:27:24 CDT(-0500)] <yura1> not sure you do, but i would have a "DELETE" directive

[10:27:28 CDT(-0500)] <yura1> otherwise i would pass undefined

[10:28:01 CDT(-0500)] <Justin_o> yura1: thanks

[11:41:54 CDT(-0500)] <colinclark> Justin_o: Remind me again what the standard bug workflow is...

[11:42:03 CDT(-0500)] <colinclark> if I review and push a fix, do I resolve and close it?

[11:52:46 CDT(-0500)] <Justin_o> colinclark: yes

[11:54:36 CDT(-0500)] <colinclark> ok, great

[12:55:12 CDT(-0500)] <jessm> idrc, you've gone dark on IM

[12:55:22 CDT(-0500)] <jessm> except the jabber server

[12:55:30 CDT(-0500)] <jessm> oh, maybe just jameswy

[12:55:32 CDT(-0500)] <jessm> nevermind

[13:13:41 CDT(-0500)] <alexn> colinclark michelled: I'm looking into FLUID-4793 and it happens that I found 2 other issues along the way. I created 2 separate JIRAs for them to tackle separately. FLUID-4796 and FLUID-4797 respectively. FLUID-4793 has some explanations how I stumbled upon them. In the meantime colinclark I submitted a fix for FLUID-4796 here https://github.com/fluid-project/videoPlayer/pull/60

[13:14:30 CDT(-0500)] <colinclark> cool, yes

[13:14:59 CDT(-0500)] <colinclark> alexn: I wonder if you have some time this afternoon to think through the "setupEnvironment" thing with me here in the channel?

[13:15:33 CDT(-0500)] <alexn> yes sure we can chat about it any time

[13:16:37 CDT(-0500)] <colinclark> cool

[13:16:40 CDT(-0500)] <colinclark> i'm just eating some late lunch

[13:16:49 CDT(-0500)] <colinclark> i hear i missed indian buffet today

[13:16:56 CDT(-0500)] <colinclark> yura1 must have that special glow

[13:17:01 CDT(-0500)] <alexn> oh no worries I'm still looking into this evil FLUID-4793

[13:17:10 CDT(-0500)] <alexn> oh yes indian lunch was great

[13:17:33 CDT(-0500)] <yura1> colinclark: wasn't my idea

[13:17:37 CDT(-0500)] <alexn> yura1 has a special "butter chicken" glow

[13:18:17 CDT(-0500)] <Bosmon> colinclark - nice discussion of persistence methodologies

[13:18:27 CDT(-0500)] <colinclark> oh hey

[13:18:30 CDT(-0500)] <colinclark> "morning"

[13:18:39 CDT(-0500)] <Bosmon> Such a relief we can put these evil days of Hibernatism behind us

[13:18:40 CDT(-0500)] <colinclark> glad you enjoyed it in the logs

[13:18:48 CDT(-0500)] <Bosmon> And the mysterious idea of "objects that save themselves" : P

[13:19:11 CDT(-0500)] <colinclark> I never really spent very much time with Hibernate

[13:19:23 CDT(-0500)] <colinclark> but I guess it, like EnterpriseObjects, raised some interesting quetsions about "lifecycle"

[13:19:36 CDT(-0500)] <colinclark> about what the relationship was between a model object and its "context"

[13:19:41 CDT(-0500)] <colinclark> how many of these things you'd have around

[13:19:42 CDT(-0500)] <Bosmon> It was one of those ideas that invariably appeared attractive to everyone when they first heard about it

[13:19:45 CDT(-0500)] <colinclark> when they would live and die

[13:19:54 CDT(-0500)] <Bosmon> But when investigated in any detailed way, invariably proved Dreadful

[13:19:57 CDT(-0500)] <colinclark> what kind of independence a "model" object could have from their context

[13:20:36 CDT(-0500)] <Bosmon> It also started off the big debate about "Long Sessions or DTOs" : P

[13:20:42 CDT(-0500)] <colinclark> right

[13:20:46 CDT(-0500)] <Bosmon> What nonsense we all lived with...

[13:21:07 CDT(-0500)] <Bosmon> All, as it turns out, because of "object-orientation"..

[13:22:53 CDT(-0500)] <colinclark> so what are you working on today, Bosmon?

[13:23:03 CDT(-0500)] <Bosmon> I am rewriting fluid.merge

[13:23:17 CDT(-0500)] <Bosmon> Which it seems can actually happen in two stages

[13:23:35 CDT(-0500)] <Bosmon> Firstly it can be rewritten basically, to use the new idiom of "segs", and "compiled mergePolicies"

[13:23:45 CDT(-0500)] <Bosmon> After that it can have the new "strategy API" retrofitted into it

[13:24:23 CDT(-0500)] <colinclark> Cool

[13:24:32 CDT(-0500)] <colinclark> This is all part of the larger "ginger" project?

[13:24:48 CDT(-0500)] <Bosmon> Yes, it is

[13:25:07 CDT(-0500)] <Bosmon> Once we have "ginger expansion" (now working) and "ginger merging", the two of them can then be bolted together

[13:27:01 CDT(-0500)] <colinclark> Can you summarize, in a sentence or two, the core value that the ginger project will have on users of the framework, Bosmon?

[13:28:00 CDT(-0500)] <Bosmon> I guess it's not completely easy to summarise, but I'll do my best

[13:28:25 CDT(-0500)] <Bosmon> Right now the limitations in the framework can cause a lot of "design problems", where there are things that you believe you SHOULD be able to refer to in IoC configuration, but you can't

[13:28:27 CDT(-0500)] <colinclark> fair enough

[13:28:41 CDT(-0500)] <colinclark> Can you give a concrete example?

[13:28:52 CDT(-0500)] <colinclark> I'm thinking, maybe, your sibling components?

[13:29:28 CDT(-0500)] <Bosmon> And a lot of these limitations relate to references made from a component back to THE SAME COMPONENT - in fact, people very naturally want to write, say, references from one value in a component's options, or even more usefully, a reference from the "listeners" block of a component onto its own invokers

[13:29:50 CDT(-0500)] <colinclark> ahh

[13:29:53 CDT(-0500)] <Bosmon> Right now, references made "against the grain" will fail - that is, a reference made to a part of a component which is not definitely part of an earlier workflow step in the framework will fail

[13:29:54 CDT(-0500)] <colinclark> that makes quite a bit of sense

[13:30:10 CDT(-0500)] <Bosmon> This is particularly annoying since it puts the burden on framework users of knowing what this workflow actually IS

[13:30:35 CDT(-0500)] <colinclark> the pre/post/final init workflow, specifically?

[13:30:39 CDT(-0500)] <Bosmon> And, for example, memorising the set of workflow steps, and the name of the particular "initFunction" which is associated with the start or end of it, or looking it up in a table (the way I always do)

[13:30:43 CDT(-0500)] <Bosmon> Yes, those

[13:32:58 CDT(-0500)] <Bosmon> So working around these framework limitations often causes people to have to pervert their designs - either they find a way to make a component work without the reference, or they make some kind of "lifecycle hack" (of which we have a few in UIOptions), or they create a whole new level of component containment so that they can get a fresh set of lifecycle points

[13:36:22 CDT(-0500)] <colinclark> So it sounds like those lifecycle points won't really be relevant in the next version of Infusion?

[13:36:37 CDT(-0500)] <Bosmon> Their relevance should be greatly reduced, yes

[13:36:45 CDT(-0500)] <Bosmon> And in a future version of Infusion we would like to remove them completely

[13:42:16 CDT(-0500)] <colinclark> Anything else noteworthy, Bosmon?

[13:42:39 CDT(-0500)] <Bosmon> I've been working with yura1 on our "asynchronous request grade architecture"

[13:42:50 CDT(-0500)] <Bosmon> Well, he's been doing the work, and I've been making silly suggestions : P

[13:45:06 CDT(-0500)] <yura1> Bosmon: i m still not sure what's the best way to proceed with fixing tests for matchmaker

[13:45:18 CDT(-0500)] <Bosmon> yura1 - because of the issue with loading "when"?

[13:47:18 CDT(-0500)] <yura1> Bosmon: yes

[13:47:22 CDT(-0500)] <Bosmon> I think we should operate a "dual loading system" right now.... which is pretty much what we always did

[13:47:45 CDT(-0500)] <Bosmon> That is, leave the "require" statements in, but continue to stub out the browser version of require

[13:47:53 CDT(-0500)] <Bosmon> Well

[13:48:47 CDT(-0500)] <colinclark> Bosmon, yura1: Do you guys mind bouncing over to fluid-tech while I chat through some pull requests here with alexn?

[13:49:00 CDT(-0500)] <Bosmon> cool, colinclark

[13:49:13 CDT(-0500)] <yura1> colinclark: sure

[13:49:17 CDT(-0500)] <colinclark> cool

[13:49:26 CDT(-0500)] <colinclark> i'll keep an eye out there as well

[13:49:31 CDT(-0500)] <colinclark> So, alexn, got a sec?

[13:50:00 CDT(-0500)] <alexn> yeah, also getting closer and closer for that bug resolution I mentioned earlier

[13:50:13 CDT(-0500)] <alexn> so setupEnviornment

[13:50:15 CDT(-0500)] <colinclark> cool

[13:50:17 CDT(-0500)] <colinclark> Yes

[13:50:21 CDT(-0500)] <colinclark> It's been bugging me

[13:50:38 CDT(-0500)] <alexn> tell me more

[13:50:39 CDT(-0500)] <colinclark> And I think, if we talk through it a bit, we'll probably find that your current solution, while admirable, doesn't quite work

[13:51:22 CDT(-0500)] <alexn> ok let's split it into parts - why it does not work and what could be a possible solution

[13:51:52 CDT(-0500)] <colinclark> I like that you've tried to factor it out as a utility you can use in several places

[13:51:54 CDT(-0500)] <alexn> *opening the file with the code

[13:52:06 CDT(-0500)] <colinclark> https://github.com/fluid-project/videoPlayer/pull/58/files#L6R56

[13:52:17 CDT(-0500)] <colinclark> I guess the first issue is that it's not quite as generic as it sounds

[13:52:37 CDT(-0500)] <colinclark> In that the function is called "setupTestEnvironmentFeature"

[13:52:43 CDT(-0500)] <colinclark> I guess the word "Feature" is really important here

[13:53:11 CDT(-0500)] <alexn> yes, because we are considering the fact that the user/developer may potentially add more "features"

[13:53:14 CDT(-0500)] <colinclark> since it assumes that the only kind of component you'd want to put into the static environment for a test is one that starts with the prefix "fluid.browser/

[13:53:23 CDT(-0500)] <colinclark> Sorry, "fluid.browser."

[13:53:48 CDT(-0500)] <alexn> right

[13:54:42 CDT(-0500)] <Bosmon> Also, morally, this utility should ensure that the environment is cleaned up probably as soon as the test ends - not reserving this task to the next time it is called

[13:55:00 CDT(-0500)] <colinclark> That was where I was going to get to, Bosmon

[13:55:04 CDT(-0500)] <colinclark> though you're jumping the gun a bit

[13:55:07 CDT(-0500)] <Bosmon> Sorry

[13:55:31 CDT(-0500)] <alexn> well it should be a separate function for cleanup I assume

[13:55:48 CDT(-0500)] <colinclark> I think that's probably true, yes

[13:56:00 CDT(-0500)] <colinclark> and so that starts to point to this kind of a function's collapse

[13:56:08 CDT(-0500)] <colinclark> It's interesting… let's go back and look at how it used to look

[13:56:50 CDT(-0500)] <colinclark> https://github.com/colinbdclark/videoPlayer/blob/demo/tests/js/VideoPlayerTests.js#L85-91

[13:57:16 CDT(-0500)] <colinclark> And so, alexn, your refactoring seems like a natural trajectory for a function like this

[13:57:19 CDT(-0500)] <colinclark> You generalized it a bit

[13:57:24 CDT(-0500)] <colinclark> but not TOO much

[13:57:29 CDT(-0500)] <colinclark> and I think you did that for a specific reason

[13:57:44 CDT(-0500)] <colinclark> because if you supported a full component name as the first argument, then it's getting a bit more verbose

[13:57:48 CDT(-0500)] <Bosmon> I think the following set of code would be very useful for comparison

[13:57:49 CDT(-0500)] <Bosmon> https://github.com/fluid-project/infusion/blob/master/src/webapp/tests/component-tests/uploader/js/UploaderTests.js#L525-578

[13:58:03 CDT(-0500)] <Bosmon> This looks like a great opportunity to me to generalise and unify both of these pieces of code

[13:58:09 CDT(-0500)] <Bosmon> And perhaps gain a new piece of testing framework

[13:58:21 CDT(-0500)] <colinclark> and, the next step-that we should separate the lifecycle of cleaning up after the test runs from the work of adding a component to the static environment-would further "verbosity" the process

[13:58:29 CDT(-0500)] <colinclark> leading us to this function's ultimate collapse

[13:58:36 CDT(-0500)] <colinclark> i.e. it doesn't quite do what we want

[13:58:49 CDT(-0500)] <colinclark> Before we get to the Uploader, does that make sense, alexn?

[13:59:39 CDT(-0500)] <alexn> yes. I guess especially when the test cases are defined declaratively it would be fairly easy to force clean up after each execution

[14:00:11 CDT(-0500)] <alexn> after each test function execution I mean

[14:02:39 CDT(-0500)] <colinclark> yeah

[14:03:01 CDT(-0500)] <colinclark> So Mike Lam, a year or two ago, spent some time working with Bosmon to make the Uploader tests quite nice

[14:03:07 CDT(-0500)] <colinclark> for very similar kinds of situations

[14:03:19 CDT(-0500)] <colinclark> Let's have a look through them--I haven't cast an eye on them in a LOOONG time

[14:03:24 CDT(-0500)] <colinclark> so we'll look at them together

[14:03:38 CDT(-0500)] <colinclark> ah, yes, it's very similar

[14:04:22 CDT(-0500)] <Bosmon> This work was sort of "half finished"

[14:04:26 CDT(-0500)] <Bosmon> But it is sort of "suggestive" : P

[14:04:59 CDT(-0500)] <colinclark> right

[14:05:47 CDT(-0500)] <alexn> I'm just trying to understand how this "fluid.browser." or similar case is hidden in those functions

[14:05:56 CDT(-0500)] <colinclark> It's not

[14:05:59 CDT(-0500)] <alexn> because if user one day decides to extend the list of available features

[14:06:07 CDT(-0500)] <colinclark> this only shows you another example of the problem, not quite the solution

[14:06:29 CDT(-0500)] <colinclark> We can, if you'd like, back up a bit and try to enumerate what we think are the features a test developer would like from us

[14:06:39 CDT(-0500)] <colinclark> Do you want to give that a stab, alexn?

[14:06:46 CDT(-0500)] <colinclark> Since you are, yourself, a test writer

[14:08:21 CDT(-0500)] <alexn> well it depends on the problem - I mean, do we want tests for the components we have, do we want to have flexible tests which would handle all our components or we want to write a test framework which would handle anything and just general.

[14:08:40 CDT(-0500)] <alexn> sorry my 1 and 2 probably look similar

[14:09:08 CDT(-0500)] <alexn> I guess the 2nd case is when we try to generalize given tests to create functions for them to avoid copy paste

[14:09:35 CDT(-0500)] <colinclark> My question was a bit more specific

[14:09:46 CDT(-0500)] <colinclark> Let's see if we can unpack the nature of the problem

[14:09:57 CDT(-0500)] <colinclark> We want to be able to run tests in different "contexts"

[14:10:42 CDT(-0500)] <alexn> I guess there should be a mapping between a context and available solutions/test settings

[14:10:42 CDT(-0500)] <colinclark> Or, put another way, to "simulate" a particular context in a unit test, and then verify that the component responds to the context appropriately

[14:10:50 CDT(-0500)] <colinclark> Right

[14:11:06 CDT(-0500)] <colinclark> So a test should have some way to declare what context it was to set up for the test

[14:11:36 CDT(-0500)] <colinclark> The second core requirement is that we need to be able to clean up after the test runs

[14:11:45 CDT(-0500)] <colinclark> to erase that context we were testing in

[14:12:43 CDT(-0500)] <alexn> Actually it would be good to have a component for testing since you can easily configure contexts through demands

[14:12:50 CDT(-0500)] <colinclark> Is that about all your particular Video Player tests need, alexn?

[14:13:06 CDT(-0500)] <colinclark> (those two things I listed, I mean)

[14:13:21 CDT(-0500)] <alexn> not all of them but some of them yes

[14:13:37 CDT(-0500)] <colinclark> Some of the features or some of the tests?

[14:13:42 CDT(-0500)] <colinclark> I'm confused

[14:13:57 CDT(-0500)] <alexn> some of the tests need some of the features

[14:14:07 CDT(-0500)] <alexn> if we look at the word "need"

[14:14:43 CDT(-0500)] <alexn> but there are some tests which just rely only on their internal functionality

[14:14:47 CDT(-0500)] <colinclark> Okay, so the features we've outlined:

[14:15:23 CDT(-0500)] <colinclark> 1. The ability to set up a "context" by placing one or more components into the IoC resolution tree

[14:15:31 CDT(-0500)] <colinclark> 2. The ability to clean up these components once the test is done

[14:15:56 CDT(-0500)] <colinclark> So first, do your tests need these two features?

[14:16:11 CDT(-0500)] <colinclark> and second, do your tests need any other features I haven't listed?

[14:16:31 CDT(-0500)] <alexn> should be it

[14:16:48 CDT(-0500)] <alexn> what is IoC resolution tree in the context of tests ?

[14:17:09 CDT(-0500)] <alexn> are we talking about fluid.typeTag() ?

[14:17:11 CDT(-0500)] <colinclark> There is probably some documentation about how IoC works in the wiki

[14:17:22 CDT(-0500)] <alexn> I know I read it

[14:17:28 CDT(-0500)] <alexn> but not sure in the given example

[14:17:54 CDT(-0500)] <colinclark> I don't know that I want to assume the given implementation

[14:17:56 CDT(-0500)] <alexn> because right now we create fuild.staticEnvironment.feature = fluid.typeTag

[14:18:03 CDT(-0500)] <colinclark> but, last I looked, there were three places you could define a component

[14:18:08 CDT(-0500)] <colinclark> 1. The static environment

[14:18:13 CDT(-0500)] <colinclark> 2. The dynamic environment

[14:18:28 CDT(-0500)] <colinclark> 3. A component's configuration

[14:18:50 CDT(-0500)] <colinclark> And those three sources become the tree by which "types" are resolved in the IoC system

[14:19:06 CDT(-0500)] <colinclark> Bosmon might want to correct me here if I'm out of date or a little awkward with my terminology

[14:19:39 CDT(-0500)] <colinclark> alexn: Right, our current approach is to place components (using fluid.typeTag()) into the static environment

[14:19:59 CDT(-0500)] <colinclark> but it need not be the only way

[14:20:36 CDT(-0500)] <alexn> can I ask a question? Why we did not think about this before when we started writing tests for videoPlayer and defined features because it sounds like a pretty general thing to have

[14:21:15 CDT(-0500)] <alexn> I guess we came to the idea with the introduction of more features.

[14:21:17 CDT(-0500)] <colinclark> Well, I think this is one of the core points I'm trying to express in general, alexn

[14:21:27 CDT(-0500)] <alexn> one of the good points

[14:21:33 CDT(-0500)] <alexn> I will take a look into it

[14:21:34 CDT(-0500)] <colinclark> It's all of our responsibility to produce code that doesn't just fix our own problems

[14:21:45 CDT(-0500)] <colinclark> but rather solves other people's problems as well

[14:22:16 CDT(-0500)] <colinclark> I tried my best, years ago when I first wrote the VideoPlayer in "43 minutes" to provide some of the basic infrastructure for growth of the component

[14:22:24 CDT(-0500)] <colinclark> this was prior even to IoC, if I remember correctly

[14:22:41 CDT(-0500)] <colinclark> After that, we had a student work on the code, and he added a lot of features but didn't necessarily factor things to help you

[14:22:45 CDT(-0500)] <colinclark> and then you came along

[14:23:15 CDT(-0500)] <colinclark> So, I guess a JFK quote might be appropriate in this kind of case

[14:23:19 CDT(-0500)] <colinclark> THE JFK quote

[14:23:21 CDT(-0500)] <colinclark> right jessm?

[14:23:24 CDT(-0500)] <alexn> well it looks factored pretty well for what it has but we will make it better and more flexible

[14:23:28 CDT(-0500)] <alexn>

[14:24:07 CDT(-0500)] <colinclark> michelled: Curiously, do you concur with alexn on that point? ^

[14:24:28 CDT(-0500)] <alexn> I will definitely take a look into it colinclark. Thanks for example Bosmon I will take a look into it and will use as my lighthouse

[14:24:55 CDT(-0500)] <alexn> colinclark michelled: I just meant that it is was a pretty decent code for those 43 minutes

[14:24:56 CDT(-0500)] <jessm> colinclark: what JFK quote are you talking about?

[14:25:14 CDT(-0500)] <colinclark> "Ask not what your country can do for you…?"

[14:25:15 CDT(-0500)] <Bosmon> "Can't Think of Everything"? : P

[14:25:19 CDT(-0500)] <Bosmon> hahaha

[14:25:26 CDT(-0500)] <Bosmon> The following code written by yura may also be relevant

[14:25:27 CDT(-0500)] <Bosmon> https://github.com/yzen/universal/blob/5c98a3c31d76827464c075b90e38ecbe3716b339/tests/gpiiTests.js#L39-65

[14:25:29 CDT(-0500)] * michelled needs to catch up

[14:25:36 CDT(-0500)] <Bosmon> He produced a thing called "addToEnvironment" for use in GPII recently

[14:25:42 CDT(-0500)] <colinclark> "Ask not what your code base can do for you…"

[14:25:48 CDT(-0500)] <Bosmon> That I somewhat questioned at the time but let in for the time being.....

[14:26:04 CDT(-0500)] <jessm> colinclark: oh, yes! My father does a version, in a Fidel Castro voice, in Spanish, and there's a sandwich at the end. I've no idea what it means but I'm sure it's offensive

[14:26:10 CDT(-0500)] <alexn> thx Bosmon !

[14:26:10 CDT(-0500)] <jessm> don't use his version

[14:26:11 CDT(-0500)] <colinclark> lol

[14:26:18 CDT(-0500)] <colinclark> I suppose JFK was talking about a notion of "citizenship"

[14:26:23 CDT(-0500)] <colinclark> which I guess is very current

[14:26:58 CDT(-0500)] <Bosmon> Actually perhaps all I should have questioned was the NAME.... since it looks like what he has implemented here is what I had been talking about for a very long time, an "IoC Test case"

[14:26:59 CDT(-0500)] <colinclark> If it doesn't sound too pretentious and idealistic...

[14:27:09 CDT(-0500)] <Bosmon> That is, an IoC component which REPRESENTS the test case

[14:27:21 CDT(-0500)] <Bosmon> This follows colinclark point 3. above of "where you can put things"

[14:27:29 CDT(-0500)] <Bosmon> This has the advantage that it is much easier to throw away afterwards

[14:27:40 CDT(-0500)] <colinclark> that seems about like what we want, Bosmon

[14:27:43 CDT(-0500)] <Bosmon> Since putting things in the static environment creates the issue of deleting them afterwards

[14:28:00 CDT(-0500)] <colinclark> yura: ALL YOUR TEST ARE BELONG TO US

[14:28:07 CDT(-0500)] <alexn>

[14:28:08 CDT(-0500)] <colinclark> eek, now I'm using dated memes

[14:28:15 CDT(-0500)] <jessm> colinclark: citizenship in open source – very relevant

[14:28:20 CDT(-0500)] <Bosmon> colinclark - it is generally what we want, but I should mention some points of caution resulting from the continuing weakness in the framework

[14:28:20 CDT(-0500)] <alexn> well I'm sure most of us know this meme

[14:28:34 CDT(-0500)] <Bosmon> For example, some of our components, most notably UIOptions, behave badly if they are embedded at other points in an IoC tree

[14:28:49 CDT(-0500)] <alexn> this test component would be a great addition to cspace or videoPlayer

[14:28:55 CDT(-0500)] <Bosmon> So although this route is attractive, don't necessarily expect the road to be bump-free : P

[14:29:05 CDT(-0500)] <colinclark> jessm: I hope so. The point I'm trying to get at is that even writing a single line of code involves this idea of citizenship. That you don't just fix a bug or make something work, but leave a tool for the next guy/gal to not have to do the same thing all over again

[14:29:17 CDT(-0500)] <Bosmon> I believe that UIOptions is our only "dangerous" component in this sense

[14:29:47 CDT(-0500)] <jessm> colinclark: yes!

[14:29:58 CDT(-0500)] <jessm> it matters

[14:31:34 CDT(-0500)] <alexn> colinclark: should it be a separate JIRA for creating this test component and converting some of the test cases to use it or should I use that JIRA-4787

[14:34:24 CDT(-0500)] <colinclark> sorry, phone cal

[14:34:26 CDT(-0500)] <colinclark> one sec

[14:40:57 CDT(-0500)] <colinclark> alexn: I'd file a new JIRA, sure

[14:41:15 CDT(-0500)] <colinclark> I guess the question is what to do with this particular code

[14:41:29 CDT(-0500)] <colinclark> since once again, we want to keep moving forward, but at least leave things a bit better than they were before

[14:42:12 CDT(-0500)] <alexn> colinclark: once you create a JIRA could you please send it my way so I can start looking into it

[14:42:22 CDT(-0500)] <colinclark> yup

[14:42:30 CDT(-0500)] <colinclark> if you want to file the JIRA, please go ahead

[14:42:31 CDT(-0500)] <colinclark> up to you

[14:42:44 CDT(-0500)] <alexn> ok I will do it then, you have enough on your plate

[14:42:49 CDT(-0500)] <colinclark> yura: Got a sec?

[14:42:53 CDT(-0500)] <alexn> not including 6 pull requests from me

[14:42:58 CDT(-0500)] <colinclark>

[14:43:59 CDT(-0500)] <colinclark> Bosmon: What are the caution points you were going to highlight?

[14:45:39 CDT(-0500)] <alexn> maybe it would be easier for us if 4787 gets in. I'm a bit worried that I will have to do this new JIRA and refactor some of the tests even though some refactoring already present in 4787. But it is your call colinclark

[14:46:08 CDT(-0500)] <colinclark> alexn: I'm thinking we can perhaps find an incremental step along the way

[14:47:24 CDT(-0500)] <alexn> colinclark: I can revert the part related to setupTestEnvironmentFeature

[14:47:47 CDT(-0500)] <colinclark> Before you do that, let's think about what that interim step might look like

[14:48:02 CDT(-0500)] <colinclark> Going back to those two requirements I listed above

[14:48:21 CDT(-0500)] <colinclark> 1. The ability to set up a "context" by placing one or more components into the IoC resolution tree

[14:48:22 CDT(-0500)] <colinclark> 2. The ability to clean up these components once the test is done

[14:48:51 CDT(-0500)] <colinclark> Remind me, alexn, does QUnit support some kind of tear down function?