Skip to end of metadata
Go to start of metadata

[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

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

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

[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>

[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 (smile)

[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 (smile)

[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

[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 (smile)

[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 (smile)

[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 (smile)

[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 (smile)

[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>

[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 (wink)

[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>

[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>

[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 (smile)

[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 (smile) 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> (smile) 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 (smile)

[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> (smile)

[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 (big grin)

[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>

[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 (tongue)

[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> (big grin)

[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 (big grin)

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

[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?

[14:49:08 CDT(-0500)] <colinclark> A function that will be invoked after the test function is done

[14:49:22 CDT(-0500)] <alexn> I will be honest I do not know one from the top of my head but will search for it

[14:49:38 CDT(-0500)] <colinclark> ok

[14:49:42 CDT(-0500)] <colinclark> the QUnit docs are pretty good

[14:50:49 CDT(-0500)] <alexn> there is Qunit.testDone() whenever a test block ends

[14:51:13 CDT(-0500)] <colinclark> Can you toss me a link to the docs for it?

[14:51:22 CDT(-0500)] <alexn>

[14:51:29 CDT(-0500)] <alexn> well this is the one I was looking into

[14:52:10 CDT(-0500)] <alexn> I would not say that their documentation is great to be honest (tongue)

[14:52:41 CDT(-0500)] <colinclark> Nor their API

[14:52:51 CDT(-0500)] <colinclark> This is probably a little bit more up our alley:

[14:53:06 CDT(-0500)] <colinclark> you'll notice the "lifecycle" argument

[14:53:24 CDT(-0500)] <colinclark> now, we should probably look at how this interfaces with jQUnit

[14:53:37 CDT(-0500)] <Bosmon> colinclark - the fact that not all of our component behave properly if they are not the top component in an IoC tree

[14:53:51 CDT(-0500)] <colinclark> that's what I feared

[14:54:00 CDT(-0500)] <colinclark> what's a specific case, Bosmon?

[14:55:31 CDT(-0500)] <colinclark> Here we go, alexn:

[14:56:27 CDT(-0500)] <alexn> sweet

[14:59:28 CDT(-0500)] <colinclark> So we don't really have a great API to work with here, unfortunately

[15:00:07 CDT(-0500)] <alexn> well it is bare minimum

[15:00:15 CDT(-0500)] <colinclark> but perhaps we can imagine some kind of helper that will allow us to run a test that takes one or more type tag names

[15:00:26 CDT(-0500)] <colinclark> which will be added to the static environment for us

[15:00:39 CDT(-0500)] <colinclark> and then cleaned up on tear down?

[15:01:27 CDT(-0500)] <colinclark> That might be a good interim improvement on the current idiom

[15:01:36 CDT(-0500)] <alexn> well out setUpFn can get multiple type tags as an argument

[15:02:42 CDT(-0500)] <colinclark> Which setupFn are you thinking of, specifically?

[15:03:10 CDT(-0500)] <alexn> oh the one which is an argument for testCase function in the link you sent ^

[15:04:07 CDT(-0500)] <alexn> oh wait

[15:04:40 CDT(-0500)] <alexn> (smile) ignore my comment about setUpFn

[15:04:57 CDT(-0500)] <colinclark> (smile)

[15:08:03 CDT(-0500)] <alexn> ok so. to sum it up colinclark. I will create a JIRA for this test component and start working on it using those code examples which Bosmon provided in the channel as well as using our discussion logs. But before doing this I will create this interim step.

[15:08:13 CDT(-0500)] <colinclark> yup

  • No labels