fluid-work IRC Logs-2008-10-22

[08:29:34 EDT(-0400)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[08:33:30 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[09:45:36 EDT(-0400)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[09:59:42 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[10:18:54 EDT(-0400)] * apetro (n=apetro@ip68-3-58-144.ph.ph.cox.net) has joined #fluid-work
[10:46:21 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[10:57:35 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[11:48:42 EDT(-0400)] <Bosmon> Am I here?
[11:49:43 EDT(-0400)] <Bosmon> Justin_o: May I enquire why you want to fill a screen with an iframe?
[11:55:24 EDT(-0400)] * apetro (n=apetro@ip68-3-58-144.ph.ph.cox.net) has joined #fluid-work
[12:07:38 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-37.LIPS.Berkeley.EDU) has joined #fluid-work
[12:10:36 EDT(-0400)] <michelled> Bosmon, you are here but Justin_o is not
[12:10:56 EDT(-0400)] <michelled> what he is trying to do is not duplicate html files
[12:11:18 EDT(-0400)] <michelled> he's writing automated user tests again the existing springboards.
[12:11:47 EDT(-0400)] <michelled> we didn't want to introduce a dependency on the tests in the springboards so we are looking for alternatives
[12:22:18 EDT(-0400)] <Bosmon> Wait - how is non-duplication related to the requirement for a screen-filling iframe?
[12:22:59 EDT(-0400)] <michelled> Sorry - I was distracted and didn't finish my thought One suggestion was to load the springboard html into an iFrame inside the test page
[12:23:31 EDT(-0400)] <Bosmon> Why would we ever want to do that?
[12:23:45 EDT(-0400)] <Justin_o> that way the test files could live outside of the page we wanted to test
[12:24:17 EDT(-0400)] <michelled> and the tests would be written using the html that we ship as examples and springboards
[12:24:22 EDT(-0400)] <Bosmon> I don't think we should mix the role of markup which is a user-facing springboard, and part of an automated test
[12:24:24 EDT(-0400)] <Bosmon> I may be wrong about this
[12:24:59 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[12:25:24 EDT(-0400)] <Bosmon> Springboards are for people
[12:25:29 EDT(-0400)] <michelled> yes
[12:25:55 EDT(-0400)] <Bosmon> However, if we are really wanting to "reuse" the springboard markup, perhaps we could fetch it via AJAX and inject it into the document test area
[12:25:55 EDT(-0400)] * Topic is 'Springboards are made out of people! They're people!' set by colinclark on 2008-10-22 12:25:55 EDT(-0400)
[12:25:59 EDT(-0400)] <Bosmon> hahahaha
[12:26:01 EDT(-0400)] <michelled> and if we wrote tests that used the springboard markup and js then we'd be certain that we didn't break essential functionality
[12:26:04 EDT(-0400)] <colinclark> ... wait, you said "for people."
[12:26:05 EDT(-0400)] <colinclark> Sorry
[12:26:06 EDT(-0400)] <colinclark>
[12:26:24 EDT(-0400)] <michelled> that was another strategy that was tried
[12:26:37 EDT(-0400)] <michelled> Justin_o and colinclark hit a wall with that I think
[12:26:40 EDT(-0400)] <colinclark> Bosmon: Yeah, we started on that.
[12:26:44 EDT(-0400)] <colinclark> It wasn't a thick wall.
[12:26:45 EDT(-0400)] <Bosmon> They should have hit a wall more verbally
[12:26:55 EDT(-0400)] <Bosmon> Since this is functionality that we do have on the table for the framework
[12:27:02 EDT(-0400)] <Bosmon> In the form of the "Fluid Loader"
[12:27:04 EDT(-0400)] <colinclark> It seemed to have been an issue with jQuery's desire to execute scripts immediately.
[12:27:15 EDT(-0400)] <Bosmon> Yes... we also have a call for that
[12:27:20 EDT(-0400)] <colinclark> The iFrame-based approach strikes me as much simpler to start with.
[12:27:28 EDT(-0400)] <Bosmon> It sounds very dangerous...
[12:27:33 EDT(-0400)] <colinclark> Justin_o: Have you found any difficulties with it so far?
[12:27:35 EDT(-0400)] <colinclark> Dangerous!
[12:27:35 EDT(-0400)] <Bosmon> The environment it creates is entirely unrealistic
[12:27:44 EDT(-0400)] <colinclark> It's really not entirely unrealistic.
[12:27:46 EDT(-0400)] <Justin_o> difficulties.... yes i have...
[12:27:55 EDT(-0400)] <Bosmon> It is its own "classloader" for a start
[12:28:05 EDT(-0400)] <Bosmon> How do you plan to talk to things "inside the world"?
[12:28:18 EDT(-0400)] <Bosmon> None of the libraries or versions of anything will be known to concord
[12:28:25 EDT(-0400)] <Justin_o> I've tried using javascript to put the js file into the iframe... but then had problems with the execution of it
[12:29:17 EDT(-0400)] <Bosmon> Yes
[12:29:27 EDT(-0400)] <Bosmon> My "gut feel" is that the iframe is a no-hoper
[12:29:34 EDT(-0400)] <Justin_o> various errors... i'm evening having some problems now where even if i put all of the js into the file i'm loading into the iFrame. The test runs but the results aren't outputted to the screen
[12:29:47 EDT(-0400)] <Bosmon> The "Classloader separation issues" will just kill us
[12:30:01 EDT(-0400)] * apetro (n=apetro@12.164.139.7) has joined #fluid-work
[12:30:06 EDT(-0400)] <Bosmon> And we need to beef up our infrastructure in any case for dealing with "real" documents
[12:30:24 EDT(-0400)] <Bosmon> It's no point inventing a whole set of procedures which are not the ones we would ever recommend to our users
[12:34:04 EDT(-0400)] <colinclark> Just got a brief summary from Justin_o of the iFrame problems...
[12:34:33 EDT(-0400)] * michelled is impressed that colinclark can type and walk at the same time
[12:34:40 EDT(-0400)] <colinclark> Boz, you probably know the jQuery code best. We started with an AJAX-based approach, but ran into a problem where we weren't actually getting the whole document back when we passed it to jQuery.
[12:34:50 EDT(-0400)] <Bosmon> What do you mean?
[12:35:03 EDT(-0400)] <colinclark> The Fluid loader is not in scope for 0.6, but perhaps you can offer some advice to Justin_o in debugging htis.
[12:35:08 EDT(-0400)] <colinclark> He can show you some examples, I think.
[12:35:14 EDT(-0400)] <Justin_o> yes
[12:35:41 EDT(-0400)] <Bosmon> But could we briefly drop back and ensure that we really should be doing what we are trying to do here?
[12:36:20 EDT(-0400)] <Justin_o> it seemed as though we were getting back the html file with <body> and other tags removed but it was still trying to load the js files that i didn't want... basically i just wanted what was contained in the body, but wasn't able to seperate it out
[12:36:32 EDT(-0400)] <Bosmon> Right
[12:36:42 EDT(-0400)] <michelled> I think we really should be using the same markup files for these tests
[12:36:55 EDT(-0400)] <michelled> it will save Justin_o and other testers a lot of work
[12:37:04 EDT(-0400)] <Bosmon> Do we not feel that we really feel that we want to be moving to a model whereby we will use the established jqUnit model for our markup and tests?
[12:37:04 EDT(-0400)] <michelled> the strategy for reuse is up for discussion
[12:37:24 EDT(-0400)] * Bosmon frequently has feelings about feelings ...
[12:38:15 EDT(-0400)] <colinclark> Bosmon: What do you mean...
[12:38:17 EDT(-0400)] <colinclark> ?
[12:38:36 EDT(-0400)] <Bosmon> Well, one important difference between the springboards and the jqunit tests is that they are not packaged in the same way
[12:38:45 EDT(-0400)] <colinclark> Indeed.
[12:39:00 EDT(-0400)] <colinclark> The point with automated QA tests is that they have to test the real thing.
[12:39:01 EDT(-0400)] <Bosmon> What do we suppose we will do about this!
[12:39:21 EDT(-0400)] <colinclark> So to be clear, you and Michelle may have different requirements from the robot-style tests than Justin does.
[12:39:38 EDT(-0400)] <colinclark> Justin needs to be able to automate the testing against our real deliverables... the things we put in users hands.
[12:39:39 EDT(-0400)] <Bosmon> glarg
[12:39:51 EDT(-0400)] <colinclark> So Justin needs to test the Springboards in their "natural" form.
[12:39:58 EDT(-0400)] <Bosmon> OK, yes
[12:40:09 EDT(-0400)] <Bosmon> But I am just highlighting one of the important mismatches we face
[12:40:11 EDT(-0400)] <colinclark> You, as a developer, will want to use automated tests in context of the rest of your suite of unit tests.
[12:40:16 EDT(-0400)] <colinclark> Ensuring code coverage, etc.
[12:40:26 EDT(-0400)] <michelled> yes, there will likely be failure cases etc that we would still package up with our other tests
[12:40:40 EDT(-0400)] <michelled> non user facing markup
[12:40:44 EDT(-0400)] <Bosmon> I think it would be worrying if at this stage we stood by and let one "testing culture" diverge completely from the other
[12:40:57 EDT(-0400)] <colinclark> Yeah, there's tons of stuff we haven't been able to successfully test with jqUnits because of limitations with simulate, etc.
[12:41:04 EDT(-0400)] <michelled> but it's a completely different type of test
[12:41:09 EDT(-0400)] <colinclark> But Justin's needs are interesting and different.
[12:41:10 EDT(-0400)] <colinclark>
[12:41:23 EDT(-0400)] <Bosmon> But are they!
[12:41:28 EDT(-0400)] <colinclark> I believe so, yes.
[12:41:33 EDT(-0400)] <Bosmon> Why?
[12:41:48 EDT(-0400)] <colinclark> He needs to be able to automate the procedure of testing against a QA test plan....
[12:41:55 EDT(-0400)] <Bosmon> And so?
[12:42:04 EDT(-0400)] <michelled> partly because they are testing whole work flows and partly because they are testing the actual deliverables
[12:42:05 EDT(-0400)] <colinclark> with the real artifacts in an uncontrived environment.
[12:42:26 EDT(-0400)] <colinclark> So he has to test the springboards and the demos within the sample-code directory as-is.
[12:42:41 EDT(-0400)] <colinclark> Justin_o: Am I correct in this assumption, or I am putting words in your mouth?
[12:42:42 EDT(-0400)] <Bosmon> Well, ok
[12:42:54 EDT(-0400)] <Justin_o> colinclark: sounds right to me
[12:42:54 EDT(-0400)] <Bosmon> But don't we still think we want him to be using jqUnit?
[12:43:02 EDT(-0400)] <Bosmon> And writing happy assertions along with the rest of us?
[12:43:09 EDT(-0400)] <colinclark> Absolutely.
[12:43:13 EDT(-0400)] <Bosmon> ok
[12:43:15 EDT(-0400)] <colinclark> But I think that's a separate issue.
[12:43:23 EDT(-0400)] <Bosmon> Separate to what?
[12:43:30 EDT(-0400)] <colinclark> Point being that somehow we need to get real markup into the test environment...
[12:43:34 EDT(-0400)] <michelled> separate to the source of the test data
[12:43:35 EDT(-0400)] <colinclark> whereas the unit tests don't have that need.
[12:43:47 EDT(-0400)] <colinclark> They can happily test against simplified or contrived markup and data.
[12:43:56 EDT(-0400)] <Bosmon> Well
[12:44:09 EDT(-0400)] <Bosmon> It is only really "contrived" in that jQUnit imposes a particular top-level document structure
[12:44:19 EDT(-0400)] <colinclark> Well, no, it's contrived at another lover.
[12:44:21 EDT(-0400)] <colinclark> level
[12:44:22 EDT(-0400)] <colinclark> not lover
[12:44:23 EDT(-0400)] <colinclark>
[12:44:25 EDT(-0400)] <Bosmon> For example our LightboxTests really use something which is ..
[12:44:26 EDT(-0400)] <colinclark> freudian slip
[12:44:26 EDT(-0400)] <Bosmon> Wow
[12:44:34 EDT(-0400)] <colinclark> haha
[12:44:39 EDT(-0400)] <colinclark> contrived lovers
[12:44:56 EDT(-0400)] <Bosmon> Yes, moving along, something which is practically identical to our "real" lightbox file
[12:45:06 EDT(-0400)] <Bosmon> Suitably cut 'n' pasted, of course
[12:45:13 EDT(-0400)] <ecochran> that was great, first thing I saw on IRC this morning, "contrived at another lover"
[12:45:14 EDT(-0400)] * colinclark should not have technical arguments while on the phone, having completely unrelated technical arguments simultaneously.
[12:45:37 EDT(-0400)] <Bosmon> That must be some interesting "technical" argument
[12:45:41 EDT(-0400)] <Bosmon> Anyway, yes
[12:45:49 EDT(-0400)] <Bosmon> It sounds as usual we are in "violent agreement"
[12:45:52 EDT(-0400)] <colinclark> well, you know how much I admire Dan Sheppard.
[12:46:08 EDT(-0400)] <michelled> lol
[12:46:11 EDT(-0400)] <Bosmon> We do all, I think, want to see everyone continuing to use our jQunit infrastructure for writing fixtures
[12:46:19 EDT(-0400)] <colinclark> Sure.
[12:46:21 EDT(-0400)] <michelled> yes
[12:46:26 EDT(-0400)] <colinclark> But the problem is how we get real markup into that test world.
[12:46:31 EDT(-0400)] <colinclark> or any test world, for that matter
[12:46:46 EDT(-0400)] <Bosmon> And we do also, I think, agree we need to figure out a way of pointing a jQunit test at an "improperly packaged" markup file
[12:46:48 EDT(-0400)] <michelled> and also, of course, while integrating the robot
[12:46:52 EDT(-0400)] <colinclark> assuming that at the scale of QA tests, keeping cut and pasted stuff in sync will be an impossible headache
[12:47:07 EDT(-0400)] <Bosmon> There are a zillion issues here
[12:47:27 EDT(-0400)] <colinclark> yep
[12:47:31 EDT(-0400)] <colinclark> It's awesome!
[12:47:43 EDT(-0400)] * michelled is so happy we are addressing this
[12:47:49 EDT(-0400)] <Bosmon> And I feel that any credible solution to any of them will bring us a good deal closer to the reality of the "Fluid Loader"
[12:48:00 EDT(-0400)] <Bosmon> I want to make sure that any "gimmicks" that we pull end up enshrined in core framework code
[12:48:13 EDT(-0400)] <Bosmon> And not out in the miserable tundra of "testUtils"
[12:48:17 EDT(-0400)] <colinclark> Perhaps. I'd like to see this serve as a first step or as inspiration for the Loader...
[12:48:38 EDT(-0400)] <Bosmon> We need a way of parsing and stripping "entire documents"
[12:48:41 EDT(-0400)] <colinclark> recognizing that Justin_o wants to get testing, and that you're busy with the Renderer, and ecochran and I are busy with Uploader, and michelled is busy with PreferAble, etc.
[12:48:42 EDT(-0400)] <colinclark>
[12:48:46 EDT(-0400)] <Bosmon> Recognising the includes that they demand
[12:48:56 EDT(-0400)] <Bosmon> Figuring out which ones are duplicates, rebasing their relative file paths
[12:49:03 EDT(-0400)] <Bosmon> Injecting them into our own <head>
[12:49:07 EDT(-0400)] <colinclark> yep, exactly
[12:49:33 EDT(-0400)] <Bosmon> One important property of the iframe approach is that it at least allows some affordance of "unloading" stuff
[12:49:41 EDT(-0400)] <colinclark> Justin_o: That seems consistent with the problems we were seeing yesterday, right?
[12:49:46 EDT(-0400)] <Bosmon> But hopefully we would never need to unload stuff
[12:49:52 EDT(-0400)] <Justin_o> yes
[12:49:59 EDT(-0400)] <Bosmon> All framework code and test code is properly namespaced, isn't it
[12:50:20 EDT(-0400)] <colinclark> one would expect so, yes
[12:50:26 EDT(-0400)] <Bosmon> Well
[12:50:34 EDT(-0400)] <Bosmon> Sadly a lot of our "historical" test code still isn't...
[12:50:34 EDT(-0400)] <Justin_o> my main problem yesterday is that I was losing information that i needed so that I could seperate what I wanted from what I didn't
[12:51:08 EDT(-0400)] <Bosmon> But yes, I guess what we want to do is define a "special" type of jqUnit fixture
[12:51:27 EDT(-0400)] <colinclark> Justin_o: I'm speculating on the fact that this strangeness had to do with jQuery invoking each of the linked scripts before you'd had time to correctly rewrite their URLs.
[12:51:31 EDT(-0400)] <colinclark> But I have no idea.
[12:51:36 EDT(-0400)] <Bosmon> And a "monotonic inclusion model" for JS things
[12:51:50 EDT(-0400)] <Bosmon> That is, working out firmly whether we have included one instance of the required thing already
[12:51:55 EDT(-0400)] <Bosmon> And if not, injecting it
[12:52:06 EDT(-0400)] <colinclark> I suppose you could simplify the debugging by moving the test file into the same directory as the file being test so that URLs wouldn't need to be rewritten
[12:52:09 EDT(-0400)] <colinclark> Just to see what's going on.
[12:52:20 EDT(-0400)] <colinclark> Monotonic!
[12:52:21 EDT(-0400)] <Bosmon> Other than that, simply going for the <body> node of the incoming document and injecting it wholesale into the "test area" of the document just after fixture start
[12:52:25 EDT(-0400)] <Justin_o> colinclark: yes... that would be a problem. If I could have rewritten the paths it probably would have worked
[12:52:35 EDT(-0400)] <Bosmon> AFTER of course having dealt with the <head> script injection
[12:52:51 EDT(-0400)] <Bosmon> We have some path rebasing code still pending for migration from rsf.js to fluid.js...
[12:52:58 EDT(-0400)] <colinclark> Bosmon: Yes, that does sound consistent with the problem space Justin_o and I were working in yesterday.
[12:53:01 EDT(-0400)] <Bosmon> There is one final batch that has not yet been ported
[12:53:36 EDT(-0400)] <Bosmon> Which is the thing which Aaron uneuphoniously named "transformActionDomToAJAX"
[12:53:40 EDT(-0400)] <Bosmon> And its dependent functions
[12:54:01 EDT(-0400)] <Bosmon> Which are utilities I wrote called "evaluateScript" and "evaluateScriptUrl"
[12:54:13 EDT(-0400)] <ecochran> Justin_o and colinclark : sorry folks, I'm trying to catch up here. Did you try just creating an iFrame with the src set to URL of the file that you want to load? And not try to put something into the iFrame using JS?
[12:54:41 EDT(-0400)] <Bosmon> "evaluteScriptUrl" needs to be half-trashed
[12:54:45 EDT(-0400)] <colinclark> ecochran: Yep, I believe Justin_o did try that and it was problematic.
[12:54:53 EDT(-0400)] <ecochran> hmm
[12:54:55 EDT(-0400)] <Justin_o> ecochran: yes... that was todays problem
[12:54:57 EDT(-0400)] <Bosmon> Since it relies on our old illusion that it was impossible to cause scripts to be evaluated by <head> injection
[12:55:21 EDT(-0400)] <Bosmon> But it does all the same have the URL rebasing code we need
[12:55:34 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[12:55:38 EDT(-0400)] <colinclark> If I understand it correctly, the contents of the iFrame are a black hole for the robot scripts living in the parent document.
[12:55:45 EDT(-0400)] <Bosmon> Yes
[12:55:56 EDT(-0400)] <Bosmon> There will be awful issues
[12:56:13 EDT(-0400)] <Bosmon> The testing script itself would need to be "parachuted" into the iframe
[12:56:23 EDT(-0400)] <Bosmon> Otherwise it could not issue conventional jQuery requests
[12:56:24 EDT(-0400)] <ecochran> Justin_o: if I can help with that... it should work
[12:56:32 EDT(-0400)] <Bosmon> And then all of its dependencies would need to be sent in too
[12:56:37 EDT(-0400)] <Bosmon> It is not something we want to do
[12:57:41 EDT(-0400)] <colinclark> Hey, I wonder if phiggins has ever heard of anyone who has successfully tested markup with the Doh.robot in a way that didn't require adding the robot dependencies to the page itself.
[12:57:44 EDT(-0400)] <colinclark> If you know what I mean.
[12:58:37 EDT(-0400)] <phiggins> hmm seems like to use the robot you'd need the robot code on the page?
[12:58:57 EDT(-0400)] <phiggins> you could likely add them in programatically?
[12:59:18 EDT(-0400)] <colinclark> phiggins: Yeah, that's the challenge we'd like to solve...
[12:59:37 EDT(-0400)] <michelled> yes, we have attempted a couple of strategies of doing this but neither has panned out.
[12:59:43 EDT(-0400)] <colinclark> We would like to use it it automate our QA test plans. As a result, we'd have to test against pages that can't have a direct dependency on the robot.
[12:59:55 EDT(-0400)] <phiggins> my robot-foo is limited ... hmm
[13:00:11 EDT(-0400)] <colinclark> phiggins: I forget who wrote the robot. Is there someone we should ping about it?
[13:00:39 EDT(-0400)] <colinclark> I realize it's a somewhat unusual use case, but I imagine it's essential to anyone who wants to use it for automated QA testing.
[13:01:00 EDT(-0400)] <colinclark> So I guess it's not terribly unusual after all.
[13:01:01 EDT(-0400)] <phiggins> the hays': haysmark of IBM wrote it, doughays does all the commiting for him
[13:01:19 EDT(-0400)] <colinclark> Okay, great.
[13:01:31 EDT(-0400)] <ecochran> standup?
[13:01:34 EDT(-0400)] <phiggins> he's in #dojo atm - but not responding to pings
[13:01:59 EDT(-0400)] <phiggins> drop a line to doughays @ dojotoolkit.org
[13:02:00 EDT(-0400)] <colinclark> phiggins: Cool. We'll talk with him when he's around. Thanks for the reference.
[13:02:04 EDT(-0400)] <phiggins> np
[13:02:51 EDT(-0400)] <michelled> ack: standup
[13:08:23 EDT(-0400)] * doughays (n=doughays@74-137-88-132.dhcp.insightbb.com) has joined #fluid-work
[13:08:46 EDT(-0400)] <phiggins> heya doughays – colinclark is the folk asking
[13:08:59 EDT(-0400)] <phiggins> trying to post-onload load doh.robot deps
[13:09:01 EDT(-0400)] <colinclark> doughays: Hey, welcome.
[13:09:13 EDT(-0400)] <colinclark> We're hoping to use the robot for QA testing.
[13:09:18 EDT(-0400)] <phiggins> colinclark: meet doughays
[13:09:23 EDT(-0400)] * phiggins goes to lunch
[13:09:27 EDT(-0400)] <doughays> colinclark, hi
[13:09:32 EDT(-0400)] <colinclark> nice to meet you
[13:09:47 EDT(-0400)] <colinclark> ... which means we want to test real stuff; pages that can't have a direct dependency on the robot.
[13:10:01 EDT(-0400)] <colinclark> I'm curious if anyone has ever tried this.
[13:10:37 EDT(-0400)] <doughays> colinclark, yes - we tested a demo in plantsbywebsphere with the robot - had form submits and multiple pages
[13:10:37 EDT(-0400)] <colinclark> Obvious options that come to mind are to load the page into an iFrame, which is sort of a can of worms, or using AJAX to inject portions of one page into the other.
[13:10:43 EDT(-0400)] <colinclark> Aha, interesting.
[13:10:50 EDT(-0400)] <colinclark> doughays: Any advice?
[13:11:23 EDT(-0400)] <doughays> colinclark, advice? did u try it and it fell apart, or you're just worried?
[13:11:50 EDT(-0400)] <colinclark> Mostly just curious to learn from what others have done before diving into it.
[13:12:26 EDT(-0400)] <colinclark> doughays: How did you load the robot dependencies for your tests?
[13:12:51 EDT(-0400)] <colinclark> IFrame? Ajax? Something else?
[13:13:19 EDT(-0400)] <doughays> iframe
[13:13:31 EDT(-0400)] <colinclark> Okay, good to know.
[13:13:41 EDT(-0400)] <doughays> ew use the doh runner built into dojo/util
[13:13:55 EDT(-0400)] <colinclark> Cool.
[13:14:22 EDT(-0400)] <doughays> so the robot is loaded in an iframe inside the doh runner, then the app being tested is loaded inside an iframe in the robot and then the robot starts driving the app
[13:14:53 EDT(-0400)] <colinclark> Okay, that's very helpful.
[13:15:11 EDT(-0400)] <colinclark> We're actually pretty big jQuery users, so ultimately we're planning to provide an adaptor for running doh.robot tests within the qUnit testing environment. But in the meantime, we're using the doh runner, too.
[13:19:37 EDT(-0400)] <doughays> colinclark, have you read the robot blog? http://dojotoolkit.org/2008/08/11/doh-robot-automating-web-ui-unit-tests-real-user-events
[13:20:50 EDT(-0400)] <colinclark> doughays: I have. Our use of the robot is actually being led by Justin_o, our QA lead on Fluid, who has read the article in depth and been working with theclown to get our tests working.
[13:20:54 EDT(-0400)] <colinclark> So far, it's pretty great.
[13:21:02 EDT(-0400)] <colinclark> Nice work!
[13:23:50 EDT(-0400)] <Justin_o> doughays: colinclark: currently I have been using doh.robot. To use it with iFrames will I need to use dojo.robot instead
[13:26:13 EDT(-0400)] <doughays> Justin_o, you probably need to call doh.robot.initRobot("<iframe source file>"); to init the robot iframe with the starting page of the app
[13:26:33 EDT(-0400)] <Justin_o> okay.. and for that i can just use doh.robot
[13:26:35 EDT(-0400)] <Justin_o> ?
[13:27:32 EDT(-0400)] <michelled> and would the test scripts live in the outer page or would they need to be injected into the iframe?
[13:27:50 EDT(-0400)] <doughays> Justin_o, sorry, I thought that was a statement - yes, just doh.robot
[13:28:20 EDT(-0400)] <Justin_o> sorry... i was late on the question mark... thanks for letting me know
[13:28:26 EDT(-0400)] <doughays> michelled, the test scripts live in the outer page - you don't touch the app being tested
[13:28:33 EDT(-0400)] <michelled> cool!
[13:29:58 EDT(-0400)] <doughays> Justin_o, people like using dojo.robot so they get mouseMoveAt and then work with node id's
[13:31:11 EDT(-0400)] <Justin_o> yes... currently I'm getting in the offset and passing them to the mouseMove function
[13:31:38 EDT(-0400)] <doughays> dojo is loaded in the outer page and doesn't affect the app
[13:33:56 EDT(-0400)] <Justin_o> ah i see... so that may be something we can look at too then... thanks
[13:41:21 EDT(-0400)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[13:45:34 EDT(-0400)] <michelled> Justin_o: I've restarted continuum and rebuilt the nightly
[13:45:52 EDT(-0400)] <michelled> can you check that the most recent changes are visible now?
[13:46:03 EDT(-0400)] <Justin_o> okay.. will do... thanks for fixing
[13:46:14 EDT(-0400)] <michelled> np - let's hope it's all fine
[13:47:01 EDT(-0400)] <Justin_o> it looks like the updates are there. The inline edit field is now visible in the bookmarks portlet
[13:47:43 EDT(-0400)] <michelled> great
[13:47:53 EDT(-0400)] <Bosmon> cool
[13:56:45 EDT(-0400)] * doughays (n=doughays@74-137-88-132.dhcp.insightbb.com) has left #fluid-work
[14:02:07 EDT(-0400)] <theclown> Justin_o asked theclown "could you please tell me where I'm supposed to call doh.robot.init".
[14:02:25 EDT(-0400)] <theclown> take a look at this: http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/robot/test_Slider.html
[14:02:42 EDT(-0400)] <theclown> on my way to over to explain it (as best I can).
[14:37:37 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[15:35:11 EDT(-0400)] <theclown> Justin_o: I'm asking doughays about that initRobot() call in the #dojo room. I'll keep you posted.
[15:35:28 EDT(-0400)] <phiggins> I'll relay too
[15:35:31 EDT(-0400)] <phiggins>
[15:35:44 EDT(-0400)] <Justin_o> theclown phiggins: thank you
[15:51:29 EDT(-0400)] <theclown> Justin_o: some news. doughays wondered if the initRobot() functionality could be moved to the base doh.robot. alas: If you look at the internals of initRobot(), there is a call to dojo.addOnload().
[15:51:58 EDT(-0400)] <Justin_o> oh... so it will need to have dojo then...
[15:52:25 EDT(-0400)] <Justin_o> I guess dojo.js would be the minimum requirement
[15:52:40 EDT(-0400)] <theclown> I'm looking into a way where you could include dojo (core) but not have to add the various robot.js files into fluid's source repository.
[15:52:50 EDT(-0400)] <theclown> would that be acceptable?
[15:53:40 EDT(-0400)] <Justin_o> i guess so... colin was saying that if need be we could like to an external version of the code rather than add it to our repository
[15:57:34 EDT(-0400)] <colinclark> theclown, Justin_o: My idea was to link to Dojo in a CDN, rather than bring it all into our repository.
[15:58:14 EDT(-0400)] <theclown> Justin_o: yeah, that's what I was thinking. But I'm confirming that the link I'm thinking of actually contains the robot. FYI: here is the URL: http://o.aolcdn.com/dojo/1.2.0/dojo/dojo.xd.js
[15:58:30 EDT(-0400)] <theclown> colinclark: darn, you beat me.
[15:58:36 EDT(-0400)] <colinclark>
[15:58:45 EDT(-0400)] <colinclark> Great minds...
[15:58:51 EDT(-0400)] <theclown> fools...
[15:59:25 EDT(-0400)] <Justin_o> thanks for the link
[16:01:59 EDT(-0400)] <theclown> don't thank me yet. I'm playing with it, and I'm getting "doh is not defined".
[16:16:31 EDT(-0400)] <theclown> Justin_o: I"m getting closer. It's along the lines of:
[16:16:37 EDT(-0400)] <theclown> (1) <script src="http://o.aolcdn.com/dojo/1.2.0/dojo/dojo.xd.js" ...></script>
[16:16:39 EDT(-0400)] <theclown> (2) <script>dojo.require("dojo.robotx");</script>
[16:17:44 EDT(-0400)] <theclown> but that's not quite right. looking into it further.
[17:02:28 EDT(-0400)] <Justin_o> theclown: thanks... for now what I've found is a way to use jQuery to tunnel inside of the iFrame so that it can see some of the stuff.. it then passes this information to robot to use (called from the outer page)..
[17:03:05 EDT(-0400)] <theclown> justin_o: okay
[17:03:11 EDT(-0400)] * Justin_o (n=Justin@142.150.154.101) has left #fluid-work
[17:16:04 EDT(-0400)] * apetro_ (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[17:45:48 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has left #fluid-work
[17:46:26 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[17:58:10 EDT(-0400)] * apetro- (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[19:08:54 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[19:28:04 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[21:13:29 EDT(-0400)] * apetro- (n=apetro@12.164.139.7) has joined #fluid-work
[21:30:13 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279721821.dsl.bell.ca) has joined #fluid-work
[21:46:12 EDT(-0400)] * apetro (n=apetro@ip68-3-58-144.ph.ph.cox.net) has joined #fluid-work