fluid-work IRC Logs-2008-10-24

[23:58:58 EDT(-0400)] * ptmahent (n=ptmahent@74.12.29.122) has joined #fluid-work
[08:23:10 EDT(-0400)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[09:22:22 EDT(-0400)] * jacobfarber (n=Main@CPE00095bc35ea1-CM001692f5798c.cpe.net.cable.rogers.com) has joined #fluid-work
[09:43:25 EDT(-0400)] * anastasiac (n=team@142.150.154.160) has joined #fluid-work
[09:48:24 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[09:51:47 EDT(-0400)] * ptmahent (n=ptmahent@net2.senecac.on.ca) has joined #fluid-work
[09:54:04 EDT(-0400)] <Bosmon> Ping
[09:54:16 EDT(-0400)] <Bosmon> OK, here is something interesting and unfortunate
[09:54:29 EDT(-0400)] <Bosmon> JQUnit tests simply cannot run if there is an iframe in the test area
[09:54:58 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[09:56:00 EDT(-0400)] * jacobfarber (n=Main@CPE00095bc35ea1-CM001692f5798c.cpe.net.cable.rogers.com) has joined #fluid-work
[10:06:06 EDT(-0400)] * ptmahent___ (n=ptmahent@net2.senecac.on.ca) has joined #fluid-work
[10:06:57 EDT(-0400)] <ptmahent___> .
[10:38:55 EDT(-0400)] <Justin_o> Bosmon: just saw your message... that is unfortunate for how the robot tests are currently being run
[10:39:10 EDT(-0400)] <Justin_o> jacobfarber: do you know how to find the size of the viewport in opera?
[10:40:36 EDT(-0400)] <Bosmon> Justin_o: Can remind me again why you are frequently wanting to find the viewport size?
[10:40:57 EDT(-0400)] <Justin_o> so that i can set the size of the iFrame
[10:42:01 EDT(-0400)] <Bosmon> What size do you want to set it to?
[10:42:05 EDT(-0400)] <Justin_o> i can specify the width to 100% in css but it doesn't seem possible to set the height in this manner... maybe I'm doing something wrong there though
[10:42:20 EDT(-0400)] <jacobfarber> Justin_o
[10:42:27 EDT(-0400)] <jacobfarber> there is a setting in opera to view the size
[10:44:07 EDT(-0400)] <Justin_o> sorry.. i mean programatically
[10:44:13 EDT(-0400)] <jacobfarber> Justin_o go to Tools > Preferences > Advanced Tab > Browsing
[10:44:18 EDT(-0400)] <jacobfarber> oh
[10:44:27 EDT(-0400)] <jacobfarber> clientWidth and clientHEight in JS
[10:44:29 EDT(-0400)] <jacobfarber> i think
[10:44:45 EDT(-0400)] <Justin_o> can the height of an iframe be set in css?
[10:44:53 EDT(-0400)] <Justin_o> it would be easier if that were the case
[10:44:54 EDT(-0400)] <jacobfarber> yup
[10:45:00 EDT(-0400)] <jacobfarber> height and width in css
[10:45:22 EDT(-0400)] <Justin_o> i want to set it to the size of the viewport, but when I put 100% it doesn't do anything
[10:45:28 EDT(-0400)] <Justin_o> the width works like this though
[10:45:44 EDT(-0400)] <jacobfarber> you have to set html + body to height:100% first
[10:45:52 EDT(-0400)] <jacobfarber> so
[10:45:56 EDT(-0400)] <jacobfarber> it would look like
[10:46:05 EDT(-0400)]

[10:46:15 EDT(-0400)]

<jacobfarber> iframe

Unknown macro: {height}

[10:46:24 EDT(-0400)] <Justin_o> oh okay... let me go try that.. thanks
[10:47:06 EDT(-0400)] <Bosmon> Why does the iframe need to fill the viewport?
[10:48:07 EDT(-0400)] <Justin_o> jacobfarber: thanks for your help, it worked
[10:48:11 EDT(-0400)] <jacobfarber>
[10:49:24 EDT(-0400)] <Justin_o> Bosmon: that's because the robot uses absolute positioning. if the window scrolls it causes problems because the positioning doesn't seem to point to the correct location on screen anymore. If I had access to the dijit.robot it will scroll the screen for you, but the doh.robot won't
[10:50:33 EDT(-0400)] <Bosmon> I see
[10:50:53 EDT(-0400)] <Bosmon> I think, even if the robot uses absolute positioning, we need to make sure that the physical expression of our test scripts doesn't....
[10:51:28 EDT(-0400)] <Bosmon> Perhaps we should start to put together at least some kind of jqUnit-like "shell" that makes sure that it wraps and unwraps any node and coordinate expressions on the way in and out
[10:52:55 EDT(-0400)] <Justin_o> what i'm doing now is finding the location of the of the item i want to move to before I call the mouse to move. So i use jQuery to locate the item and then perform some calculations to add the iframe offset to position of the item and the robot places it there.
[10:53:06 EDT(-0400)] <Bosmon> ok
[10:53:26 EDT(-0400)] <Justin_o> the problem when the screen scrolls is that the calculated position is based on the top of the page but the robot moves in relation to the top of the viewport...
[10:53:36 EDT(-0400)] <Bosmon> It would be helpful if you factored all your assertions through a common set of functions
[10:53:44 EDT(-0400)] <Bosmon> For example one which simulated a "click" on a particular node, etc.
[10:53:50 EDT(-0400)] <Bosmon> Then we can adjust the behaviour of those functions later
[10:54:09 EDT(-0400)] <Justin_o> Bosmon: sorry.. i'm not sure i'm following you...
[10:54:34 EDT(-0400)] <Justin_o> I'm assuming you want me to write a new function that calls the doh.robot function?
[10:54:41 EDT(-0400)] <Bosmon> Yes
[10:54:45 EDT(-0400)] <Bosmon> Or rather, a family of these functions
[10:54:53 EDT(-0400)] <Bosmon> Wherever you can isolate a "high-level" requirement in your mind
[10:55:04 EDT(-0400)] <Bosmon> You should write a function for it, that is independent of the intervening machinery
[10:55:08 EDT(-0400)] * michelled (n=michelle@CPE001310472ade-CM0011aefd3ca8.cpe.net.cable.rogers.com) has joined #fluid-work
[10:55:19 EDT(-0400)] <Bosmon> I can imagine, an awful lot of the time, your "high-level requirement" is "simulate a click on node X"
[10:55:39 EDT(-0400)] <Justin_o> hmmm.... i'm not sure what you mean by "intervening machinery"
[10:56:01 EDT(-0400)] <Bosmon> Well, all this gubbins relating to the fact that i) it is the doh.robot performing it, ii) it expects an absolute pixel coordinate, etc.
[10:56:02 EDT(-0400)] <Bosmon>
[10:56:56 EDT(-0400)] <Justin_o> okay... so something like myMouseMove(id of element) instead of doh.robot.mouseMove(absolute x, absolute y)
[10:57:18 EDT(-0400)] <Bosmon> Something like that, yes
[10:57:29 EDT(-0400)] <Bosmon> Although in this case I guess the "ultimate requirement" is actually something like "hover"
[10:57:47 EDT(-0400)] <Justin_o> hover?
[10:58:01 EDT(-0400)] <Bosmon> Our aim "in time" is to bring into harmony the kinds of simulations that can be performed via doh.robot and our existing simulate/direct invocation suite
[10:58:21 EDT(-0400)] <Bosmon> I mean, the "reason" you are causing a mouseMove, is that you want to have the "ultimate effect" of invoking a hover on an element
[10:58:33 EDT(-0400)] <Bosmon> I mean, I am guessing that is what the ultimate effect is
[10:58:34 EDT(-0400)] <Justin_o> yes... i see what your saying now
[10:58:52 EDT(-0400)] <Justin_o> yes... it just places the mouse at some location on the screen
[10:58:53 EDT(-0400)] <Bosmon> So yes, I am saying, in your mind, to try to boil down what you are doing into "semantics" rather than simply into raw mouse motions
[10:59:04 EDT(-0400)] <Bosmon> That will make the resulting scripts enormously easier to deal with later
[10:59:31 EDT(-0400)] <Bosmon> Since we will be able to make adjustments more easily for different environments and packaging
[10:59:40 EDT(-0400)] <Justin_o> right... so if i want to click on a field i may combine doh.robot.mouseMove and doh.robot.mouseClick into one function
[10:59:44 EDT(-0400)] <Bosmon> Yes
[10:59:54 EDT(-0400)] <Bosmon> That is exactly right
[11:00:18 EDT(-0400)] <Bosmon> I mean, we have "similar" infrastructure building up in a different direction from my test cases for the Reorderer
[11:00:28 EDT(-0400)] <Justin_o> I see... so this is probably something I should start analysing now...
[11:00:32 EDT(-0400)] <Bosmon> We found, when we wanted to generated complicated "composite" key sequences, we had to actually simulate a whole bunch of events
[11:00:49 EDT(-0400)] <Bosmon> For example, it is impossible to generate "out of the blue" a CTRL-keyboard or click event
[11:00:58 EDT(-0400)] <Bosmon> You have to break it down into an individual sequence of key-presses
[11:01:08 EDT(-0400)] <Bosmon> BUT, in the test script, you simply want to have a single assertion -
[11:01:21 EDT(-0400)] <Bosmon> "Simulate a modified-click" or "Simulate a modified keypress"
[11:01:46 EDT(-0400)] <Bosmon> That way the environment gets a chance to "break the event down" in a way that can be retargetted at different environments
[11:02:23 EDT(-0400)] <Justin_o> i'm not sure i understand your last statement there
[11:02:23 EDT(-0400)] <Bosmon> Your environment is "more broken-down" than any we have dealt with so far, since you actually need to take care of the actual mouse position at each instant in time
[11:02:27 EDT(-0400)] <Bosmon> But the overall goals are the same
[11:02:48 EDT(-0400)] <Bosmon> Well, doh.robot is really just one of many conceivable intermediates
[11:02:57 EDT(-0400)] <Bosmon> That is, transport mechanisms for delivering events to apps
[11:03:15 EDT(-0400)] <Justin_o> so you want to be able to substitute some other method into it,
[11:03:20 EDT(-0400)] <Bosmon> It is at the moment at the far end of a continuum of possible transports since it is capabl oe of simulating everything
[11:03:32 EDT(-0400)] <Bosmon> Well, ultimately, we want one unified way of writing test fixtures against something
[11:03:42 EDT(-0400)] <Bosmon> With the understanding that with some transports, some kinds of simulation are impossible
[11:04:03 EDT(-0400)] <Justin_o> i see... and in that case you want to substitute robot for something else, but the tests will stay the same?
[11:04:10 EDT(-0400)] <Bosmon> Yup, that's exactly right
[11:04:24 EDT(-0400)] <Bosmon> Or, even if we want to experiment with some different means of packaging the robot itself
[11:04:47 EDT(-0400)] <Bosmon> For example, exactly the issue you are thinking about right now, whether the robot is in the same iframe or not, or whether we have control over exact layout and size or not
[11:05:23 EDT(-0400)] <Bosmon> Or yes, indeed, if something better, or in some as yet unexpected way entirely different to the robot comes along for being a test machinery
[11:05:24 EDT(-0400)] <Justin_o> okay.. so where do the doh scripts get loaded? i mean are they added to the html file still or to the js file?
[11:05:37 EDT(-0400)] <Bosmon> Well, I don't know, anything that is sufficient to get them to work
[11:05:45 EDT(-0400)] <Bosmon> But alongside them, we should be building up a set of "wrappers"
[11:06:01 EDT(-0400)] <Bosmon> So that whenever we issue a "test assertion", it factors through one of a small set of "semantically meaningful" functions
[11:07:18 EDT(-0400)] <Bosmon> It is "morally similar" to what i did in reforming the Reorderer tests...
[11:07:35 EDT(-0400)] <Justin_o> i think ideally i would like to just have to load in the html a js file that has all the tests and a js file that has what those test commands are... the robot js files would be somehow loaded directly into the my js file that has the command functions
[11:07:45 EDT(-0400)] <Bosmon> The old ones used to i) bind directly to the thing being tested, instead of talking abstractly about the DOM and events, and ii) have an awfully broad set of "utility assertions"
[11:08:04 EDT(-0400)] <Bosmon> If you look in "TestUtils.js" now, you can see that there are just a couple of "core simulation functions"
[11:08:08 EDT(-0400)] <Bosmon> Essentially just one, "modKeyEvent"
[11:08:28 EDT(-0400)] <Bosmon> You tell it, what is the modifier, what is the keycode, and what is the target node
[11:09:12 EDT(-0400)] <Bosmon> And it then it goes away and does it - you can see that this function is at a level of abstraction that it could just as easily be fed to doh.robot as to the DOM infrastructure directly
[11:09:17 EDT(-0400)] <Bosmon> AND that there is also just one of it
[11:10:03 EDT(-0400)] <Bosmon> Well ok, some of this is actually in "ReordererTestUtils.js"
[11:10:11 EDT(-0400)] <Bosmon> There was only time to "half-refactor" it before the release
[11:10:28 EDT(-0400)] <Bosmon> fluid.testUtils.reorderer.compositeKey = function (reorderer, event, target)
[11:10:38 EDT(-0400)] <Bosmon> But here is a "high-level" directive of the sort I am talking about
[11:11:10 EDT(-0400)] <Bosmon> You tell it, "I want to simulate a composite key press" on this thing
[11:11:27 EDT(-0400)] <Bosmon> It breaks down the key press into a set of individual key presses that would result in the required event being possible
[11:11:31 EDT(-0400)] <Bosmon> And then generates them one by one
[11:11:36 EDT(-0400)] * ptmahent___ (n=ptmahent@net2.senecac.on.ca) has joined #fluid-work
[11:11:56 EDT(-0400)] <Bosmon> You don't really tell it "how" to do it, or where the actual thing is in any physical sense that needs to be tested
[11:12:24 EDT(-0400)] <Justin_o> when you say "you" you mean the person calling the function
[11:12:28 EDT(-0400)] <Bosmon> Yes
[11:12:58 EDT(-0400)] <Bosmon> This is all very partial, what we have, but there are things that we can do that make fixing stuff up later harder, and things that make it easier
[11:13:32 EDT(-0400)] <Justin_o> hmm okay... let me see if can put something together and send it over to you to check... is that okay
[11:13:38 EDT(-0400)] <Bosmon> Cool beans
[11:13:49 EDT(-0400)] <Justin_o> thanks...
[11:13:59 EDT(-0400)] <Bosmon> Really the "fine details" don't matter too much at this stage, as long as there is some kind of set of functions you "bottleneck" all your calls to
[11:14:26 EDT(-0400)] <Bosmon> You can see that the functions I have here are not "completely right", but they are already at a point where they could be "fixed up" later without having to touch all the testing code again
[11:15:32 EDT(-0400)] <Bosmon> And believe me, there is nothing more awful than having to revisit thousands and thousands of lines of testing code in the light of some "new discovery"
[11:26:50 EDT(-0400)] <Justin_o> I totally agree that would be painful and error prone...
[11:39:49 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-42.LIPS.Berkeley.EDU) has joined #fluid-work
[11:50:11 EDT(-0400)] <ecochran> ��continuing the conversation about this:
[11:50:18 EDT(-0400)] <ecochran> http://169.229.212.42/preferable/tests/css-tests/manual/complex-src-change.html
[11:50:49 EDT(-0400)] <ecochran> there is are four css files specified
[11:50:56 EDT(-0400)] <ecochran> base, font, size, spacing
[11:51:08 EDT(-0400)] <ecochran> when you change a dropdown only one is changed