fluid-work IRC Logs-2008-10-27

[08:20:26 EDT(-0400)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[08:46:29 EDT(-0400)] * jacobfarber (n=Jacob@142.150.154.106) has joined #fluid-work
[09:39:21 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[09:52:26 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:00:51 EDT(-0400)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[10:12:23 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[11:23:36 EDT(-0400)] * ptmahent (i=rlson86@kb-v832-130-63-234-259.airyork.yorku.ca) has joined #fluid-work
[11:59:22 EDT(-0400)] * Antranig (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[11:59:34 EDT(-0400)] <Antranig> I guess I am here now
[11:59:42 EDT(-0400)] <Antranig> Justin and I are discussing the evolution of our testing framework
[12:00:12 EDT(-0400)] <Antranig> In particular, to provide as "smooth as possible" a path for integrating our doh.robot test suite with our in-browser tests, whilst letting us get as much work as possible done in the short-term
[12:00:30 EDT(-0400)] <Justin_o> that sounds about right
[12:00:56 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-33.LIPS.Berkeley.EDU) has joined #fluid-work
[12:01:19 EDT(-0400)] <Justin_o> I guess my question now is that currently all of the tests are placed inside of a function passed to the fluid.test.runAutomatedTest function
[12:02:43 EDT(-0400)] <Antranig> Yes
[12:02:47 EDT(-0400)] <colinclark> jacobfarber: fluid.setLogging(true) will print you some meaningful errors.
[12:02:48 EDT(-0400)] <Justin_o> where should the context object go...
[12:02:52 EDT(-0400)] <Antranig> Let me backfill a bit of context to this discussion
[12:02:58 EDT(-0400)] <Antranig> So that people can follow this at all
[12:03:01 EDT(-0400)] <colinclark> This is an area of the framework that needs some work.
[12:03:18 EDT(-0400)] <Justin_o> Antranig: thanks.. probably a good idea to put this all in context
[12:03:28 EDT(-0400)] <Antranig> Justin has sent me a 1st iteration of our "convergence API"
[12:03:35 EDT(-0400)] <Antranig> The discussion ran like this:
[12:03:36 EDT(-0400)] <Antranig> (15:42:14) Antranig: OK - in outline, the functions are right, but still as a "low-level" API
[12:03:36 EDT(-0400)] <Antranig> (15:42:43) Antranig: For example, the adjustment and iframe options are things that a general user shouldn't have to supply - in fact they are things that no user should have to supply
[12:03:50 EDT(-0400)] <Antranig> (15:45:23) Antranig: I think the way to do this, is to create some kind of "context" object
[12:03:50 EDT(-0400)] <Antranig> (15:45:27) Justin Obara: also the adjustment is there because someone might need to click on a different part of the item... but i figure an adjust of 2 pixels should be okay for most anything
[12:03:50 EDT(-0400)] <Antranig> (15:45:37) Antranig: The user creates the context object once only, when they initialise their tests
[12:03:50 EDT(-0400)] <Antranig> (15:45:38) Justin Obara: a context object
[12:03:50 EDT(-0400)] <Antranig> (15:45:48) Antranig: And after they have done that, they then talk to this API only in terms of JQuery objects
[12:03:59 EDT(-0400)] <Antranig> (15:45:55) Justin Obara: oh so they pass it to the main function
[12:03:59 EDT(-0400)] <Antranig> (15:46:10) Antranig: Well, I guess there are a few ways of doing this
[12:03:59 EDT(-0400)] <Antranig> (15:46:19) Antranig: But probably a fairly clear one is to have something like this:
[12:04:00 EDT(-0400)] <Antranig> (15:46:38) Antranig: var tester = fluid.testUtils.getTestingContext(iframestuff, offsetstuff) etc.
[12:04:02 EDT(-0400)] <Antranig> (15:46:57) Antranig: Then you just say tester.mouseClick(node)
[12:04:04 EDT(-0400)] <Antranig> (15:47:05) Antranig: Or tester.mouseHover(node)
[12:04:20 EDT(-0400)] <Antranig> (15:51:02) Antranig: The "compensation" code shouldn't be written in mouseHover, but should be in a common utility function
[12:04:21 EDT(-0400)] <Antranig> (15:52:19) Justin Obara: i see what you're saying... it should call another function to perform this operation.. okay... that makes sense
[12:04:21 EDT(-0400)] <Antranig> (15:52:32) Antranig: Yes
[12:04:21 EDT(-0400)] <Antranig> (15:52:43) Antranig: And once you have this "context object" it will be clear where these calls shoudl happen
[12:04:22 EDT(-0400)] <Antranig> (15:53:48) Justin Obara: okay... i'm still thinking about this context object ... so i would have a function that needs to be called for any other functions to be called
[12:04:25 EDT(-0400)] <Antranig> (15:53:56) Antranig: yes
[12:04:27 EDT(-0400)] <Antranig> (15:54:04) Justin Obara: it's some sort of set up function
[12:04:30 EDT(-0400)] <Antranig> (15:54:04) Antranig: In Javascript, this tends to work quite nicely
[12:04:31 EDT(-0400)] <Antranig> (15:54:12) Antranig: Since you just make one gigantic closure, and stick everything inside it
[12:04:33 EDT(-0400)] <Antranig> (15:54:28) Antranig: If they don't provide an iframe, or any other kind of configuration, they just get a "vanilla" kind of object
[12:04:36 EDT(-0400)] <Antranig> (15:54:49) Antranig: But however they configure it, they always gets something that satisfies the same API
[12:04:38 EDT(-0400)] <Antranig> (15:54:52) Antranig: whether they are in an iframe or not
[12:04:40 EDT(-0400)] <Antranig> (15:55:14) Antranig: So it is no longer the user's job to remember whether the test is running in an iframe, but the framework's
[12:04:43 EDT(-0400)] <Antranig> (15:56:17) Justin Obara: i see.. so i make those considerations once in my code instead of in every function
[12:04:46 EDT(-0400)] <Antranig> (15:56:22) Justin Obara: that makes a lot of sense
[12:04:48 EDT(-0400)] <Antranig> (15:57:12) Antranig: The "adjustment" issue is an interesting one
[12:04:50 EDT(-0400)] <Antranig> (15:57:21) Antranig: I suggest you handle that by means of "optional arguments"
[12:04:52 EDT(-0400)] <Antranig> (15:57:39) Antranig: perhaps move all "event-specific" configuration into a 2nd optional "options" structure
[12:04:55 EDT(-0400)] <Antranig> (15:57:53) Antranig: That way the user doesn't need to bother about it unless they need to specifically
[12:04:55 EDT(-0400)] <colinclark> For those of you who are confused, Antranig is updating everyone on the conversation he was having with Justin privately.
[12:04:57 EDT(-0400)] <Antranig> (15:58:04) Antranig: And therefore become aware that their tests are non-portable, if they use it
[12:04:59 EDT(-0400)] <Antranig> (15:59:34) Justin Obara: in the current implementation all of the tests are placed inside of the runAutomatedTest function as a function
[12:05:02 EDT(-0400)] <Antranig> OK, this brings us up to the present date
[12:05:09 EDT(-0400)] <Antranig> How could anyone be confused about that ?
[12:05:40 EDT(-0400)] <colinclark> Antranig: Quite easily.
[12:05:42 EDT(-0400)] <colinclark>
[12:05:48 EDT(-0400)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[12:05:49 EDT(-0400)] <Antranig> For the record, this conversation actually occurred between Justin and Mr. Bimble, who lives in his finger
[12:06:51 EDT(-0400)] <Justin_o> so i was just about to ask Mr. Bimble where to put the context object
[12:08:24 EDT(-0400)] <Justin_o> Antranig: i guess i'm asking how would I be able to pass that context object if the tests are sort of called at the same time... is this possible in the current structure or should I be changing something else around as well
[12:08:37 EDT(-0400)] <Antranig> What do you mean by "at the same time"?
[12:08:41 EDT(-0400)] <Antranig> At the same time as what other thing?
[12:08:47 EDT(-0400)] <Justin_o> as the tests...
[12:08:51 EDT(-0400)] <Antranig> The setup of the context object can be written wherever you like
[12:09:07 EDT(-0400)] <Antranig> For example, either in an individual test, or as a once-off thing at (semi-) global scope
[12:09:20 EDT(-0400)]

[12:09:33 EDT(-0400)] <Antranig> ok
[12:09:58 EDT(-0400)] <Antranig> Well, one place for it might be to jam it as an "argument pair" in there
[12:10:01 EDT(-0400)] <Antranig> For example like this:
[12:10:18 EDT(-0400)]

<Antranig> fluid.test.runAutomatedTest(configuration, function(context)

Unknown macro: {all tests}

)

[12:10:35 EDT(-0400)] <Antranig> So, you hand the runner your "once-off" stuff that explains about the iframes and whatever as "configuration"
[12:10:50 EDT(-0400)] <Antranig> And "in return" it hands you a context object, which is capable of simulating events and performing assertions
[12:11:00 EDT(-0400)] <Antranig> Which is handed as the argument to your function which is invoked
[12:11:02 EDT(-0400)] <Antranig> Owzat?
[12:12:26 EDT(-0400)] <Justin_o> the fluid.test.runAtomatedTest is in the same js file as the testing framework stuff... is that a poor implementation or will that make this easier
[12:12:51 EDT(-0400)] <Justin_o> if i'm getting the terms correct, it is in the same closure as well
[12:14:21 EDT(-0400)] <Antranig> Hm
[12:14:26 EDT(-0400)] <Antranig> What is the "testing framework stuff"
[12:14:33 EDT(-0400)] <Antranig> You mean the overall Dojo testrunner?
[12:20:51 EDT(-0400)] <Justin_o> sorry... i ment my wrapper functions
[12:21:08 EDT(-0400)] <Justin_o> the ones that call the doh.robot stuff
[12:23:27 EDT(-0400)] <Antranig> I guess it makes sense for these to sit at something like "the same" top-level
[12:23:38 EDT(-0400)] <Antranig> People might occasionally want to call these in isolation, if they make some kind of sense
[12:23:50 EDT(-0400)] <Antranig> But most of the time, they should use the "runAutomatedTest" main driver
[12:25:09 EDT(-0400)] <Justin_o> they can still call the individual methods but would have to use the defaults if they didn't call it within the runAutomatedTest function
[12:26:02 EDT(-0400)] <Antranig> Yes, or rather that they "couldn't get access" to iframe compensation etc. unless they did that
[12:26:08 EDT(-0400)] <Justin_o> yes...
[12:26:15 EDT(-0400)] <Antranig> The individual methods will generally be "raw, uncompensated" access to the robot
[12:26:32 EDT(-0400)] <Antranig> With a glass panel and an axe sitting next to them, reading "break in case of emergency"
[12:26:49 EDT(-0400)] <Justin_o> sounds like a safe plan....
[12:27:59 EDT(-0400)] <Justin_o> one of the issues i was thinking about before though is that they may want to make individual compensations (i.e. for a mouse click on one object they may want to add a 2 px compensation but for something else a 4 px) i'm comfortable using a single adjustment value do think that is okay
[12:28:07 EDT(-0400)] <Antranig> Yes
[12:28:16 EDT(-0400)] <Antranig> Part of that could be done at initial configuration time
[12:28:32 EDT(-0400)] <Antranig> And then they can have an option to fine-tune it for an individual event using the "optional parameters" system I talked about above
[12:29:14 EDT(-0400)] <Justin_o> can you go over the "optional parameters" again.. is that on each test function?
[12:30:04 EDT(-0400)] <Justin_o> so it would be something like fluid.test.mouseClick(jQueryObject, x, y) where x and y are optional
[12:34:07 EDT(-0400)] <Antranig> Right, but it would be "more moral" to package these up as a single "options" structure
[12:34:14 EDT(-0400)] <Antranig> Somewhat similar to the way you had "locationObject" before
[12:34:29 EDT(-0400)] <Antranig> That way you will not get tied in knots about which things are optional when you want to skip over things in the arguments list
[12:34:48 EDT(-0400)] <Antranig> So it would go fluid.test.mouseClick(jQueryObject/node, options)
[12:35:02 EDT(-0400)] <Antranig> Another nice "courtesy" is to accept either a raw DOM node or a JQuery as arg 1
[12:35:11 EDT(-0400)] <Antranig> You can just do this with a call to fluid.unwrap as you start out
[12:38:58 EDT(-0400)] <Justin_o> fluid.unwrap? does that convert the jQueryObject into a raw dom node
[12:41:02 EDT(-0400)] <colinclark> Justin_o: Yep. It actually just unwraps the jQuery instance and gives you back the underlying raw DOM node.
[12:41:21 EDT(-0400)] <colinclark> So you can think about jQuery as a friendly wrapper around a list of ordinary dom nodes.
[12:41:59 EDT(-0400)] <Justin_o> so if there are multiple nodes in the jQuery object will it return an array?
[12:42:10 EDT(-0400)] <Justin_o> colinclark: ^
[12:42:14 EDT(-0400)] <Antranig> If there are multiple nodes, I believe it will just fail
[12:42:14 EDT(-0400)] <colinclark> Hmm, good question.
[12:42:26 EDT(-0400)] <Antranig> No
[12:42:29 EDT(-0400)] <Antranig> It will return the first node
[12:42:35 EDT(-0400)] <Justin_o> okay....
[12:42:58 EDT(-0400)] <Antranig> No
[12:43:00 EDT(-0400)] <Antranig> I am confused
[12:43:12 EDT(-0400)] <Antranig> Yes, if there are multpile nodes it will return an array
[12:43:22 EDT(-0400)] <Antranig> Being, the same array
[12:43:25 EDT(-0400)] <Antranig> Anyway
[12:43:29 EDT(-0400)] <Antranig> There should not be multiple nodes
[12:43:45 EDT(-0400)] <Antranig> We should certainly improve the comments on that method...
[12:43:47 EDT(-0400)] <Justin_o> yes... just wanted to know what would happen if someone passed a bad selector
[12:44:34 EDT(-0400)] <Justin_o> because I believe that $("someSelector").offset() will just give you the absolute position of the first element
[12:47:36 EDT(-0400)] <Justin_o> would it be easier to go the other way? convert a node to a jQuery
[12:49:16 EDT(-0400)] <Antranig> Well
[12:49:26 EDT(-0400)] <Antranig> You will always have an "issue" if someone passes in two or more nodes
[12:49:33 EDT(-0400)] <Antranig> It's not really possible to sidestep it
[12:50:32 EDT(-0400)] <Justin_o> yah i guess i'm just not used to having no restrictions on function arguments
[12:54:52 EDT(-0400)] <Antranig> Welcome to the wonderful world of being a framework designer
[12:55:16 EDT(-0400)] <Justin_o>
[12:55:43 EDT(-0400)] <Justin_o> where is fluid.unwrap located
[12:56:09 EDT(-0400)] <colinclark> in Fluid.js
[12:56:15 EDT(-0400)] <colinclark> It's part of the "framework"
[15:29:59 EDT(-0400)] * Justin_o (n=Justin@142.150.154.101) has left #fluid-work
[15:35:21 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[16:53:07 EDT(-0400)] * sgithens342f (n=sgithens@in-143-211.dhcp-149-166.iupui.edu) has left #fluid-work
[17:12:13 EDT(-0400)] <anastasiac> Bosmo1, do you have a moment for a question?
[17:12:38 EDT(-0400)] <Antranig> Yes
[17:12:52 EDT(-0400)] <anastasiac> Can the renderer fill in attribute values?
[17:13:15 EDT(-0400)] <anastasiac> For example, if I have an input field in my template, can it fill in the value attribute?
[17:13:28 EDT(-0400)] <Antranig> Now it can
[17:13:40 EDT(-0400)] <Antranig> Well, actually, it could always do that
[17:13:56 EDT(-0400)] <anastasiac> how do I do that in my component tree/code/etc?
[17:14:07 EDT(-0400)] <Antranig> Well, you just need to get a value into the "value" field of the component
[17:14:16 EDT(-0400)] <Antranig> You can see examples of this even in the ancient "baseball table" demo
[17:14:38 EDT(-0400)] <anastasiac> what type of component would it be?
[17:14:45 EDT(-0400)] <Antranig> A UIBound component
[17:15:07 EDT(-0400)] <anastasiac> so if my markup is
[17:15:08 EDT(-0400)] <anastasiac> <input rsf:id="beverage:" type="checkbox" name="beverage" value="type">Type</input>
[17:15:12 EDT(-0400)] <Antranig> aha
[17:15:21 EDT(-0400)] <Antranig> checkboxes are a bit special - but not very
[17:15:37 EDT(-0400)] <anastasiac> and I want to replace the "type" in the value with something, and I want to replace the "Type" with the user-facing string...
[17:15:40 EDT(-0400)] <Antranig> if you have them "in isolation", a UIBound with a boolean value will be fine
[17:15:49 EDT(-0400)] <anastasiac> ok, suppose it's a radio
[17:15:54 EDT(-0400)] <Antranig> OK, so it sounds like you do not have them in isolation
[17:16:00 EDT(-0400)] <anastasiac> do I have to wrap the Type in a span?
[17:16:01 EDT(-0400)] <Antranig> Looks like you want to look at some of the most recent test cases
[17:16:03 EDT(-0400)] <anastasiac> with it's own id?
[17:16:06 EDT(-0400)] <Antranig> The one you want is near the bottom
[17:16:10 EDT(-0400)] <anastasiac> ah test cases!
[17:16:14 EDT(-0400)] <anastasiac> right
[17:16:24 EDT(-0400)] <Antranig> renderTests.test("UISelect tests with radio buttons", function() {
[17:16:33 EDT(-0400)] <Antranig> renderTests.test("UISelect tests with checkboxes", function() {
[17:16:35 EDT(-0400)] <Antranig> These two
[17:16:47 EDT(-0400)] <anastasiac> excellent!
[17:16:52 EDT(-0400)] <anastasiac> thanks for reminding me about the tests
[17:16:55 EDT(-0400)] <Antranig>
[17:16:57 EDT(-0400)] <anastasiac> I forget to check them
[17:17:17 EDT(-0400)] <colinclark> anastasiac: If the commit logs are any indication, these tests are pretty much hot off the press.
[17:17:31 EDT(-0400)] <Antranig> So, to recap, for an "isolated" checkbox which might submit either true or false will be a UIBound
[17:17:34 EDT(-0400)] <anastasiac> yes, I did notice that
[17:17:49 EDT(-0400)] <Antranig> For a checkbox which is expected to submit one of a palette of values, you should use UISelect
[17:18:01 EDT(-0400)] <Antranig> Similarly, all radio buttons need to be used with UISelect
[17:18:05 EDT(-0400)] <Antranig> Since they can never be "in isolation"
[17:18:47 EDT(-0400)] <anastasiac> thanks, Bosmo1
[17:18:49 EDT(-0400)] <Antranig> Yes, they are, but I did send AC a note about them around 5 hours ago
[17:18:57 EDT(-0400)] <anastasiac> yes, I saw the note
[17:19:13 EDT(-0400)] <anastasiac> I just sometimes forget to look to the tests for 'documentation'
[17:19:19 EDT(-0400)] <Antranig> Sorry
[17:19:28 EDT(-0400)] <anastasiac> nothing to be sorry for - my lapse
[17:19:32 EDT(-0400)] <Antranig> At least it is one stage better than the days when you had to look to the code for "documentation"
[17:19:39 EDT(-0400)] <anastasiac> indeed!
[17:23:06 EDT(-0400)] * Topic is 'Don't forget to buy a gerbil at the pet shop.' set by colinclark on 2008-10-27 17:23:06 EDT(-0400)
[17:23:17 EDT(-0400)] <Antranig> .....
[17:23:39 EDT(-0400)] <colinclark> jrnorman's funny example in an email on the fluid work. It made me laugh.
[17:24:24 EDT(-0400)] <colinclark> "It may be that offering the reorderable announcement list is a good
[17:24:25 EDT(-0400)] <colinclark> way to get to the bottom of the requirement, but I think you are
[17:24:25 EDT(-0400)] <colinclark> saying they want a (re)programmable course outline that can send
[17:24:25 EDT(-0400)] <colinclark> announcements/prompts/reminders at specific points. I'm thinking e.g.
[17:24:25 EDT(-0400)] <colinclark> we're in week3, every year the students forget to buy a gerbil before
[17:24:26 EDT(-0400)] <colinclark> coming to the "what do snakes eat?" lab so I want an announcement to
[17:24:27 EDT(-0400)] <colinclark> go out saying "don't forget to buy a gerbil at the petshop""
[17:24:38 EDT(-0400)] <Antranig>
[17:43:28 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has left #fluid-work
[22:50:49 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279721821.dsl.bell.ca) has joined #fluid-work