fluid-work IRC Logs-2011-04-14

Owned by Fluid IRC Log Bot
Last updated: Apr 14, 2011Version comment
21 min read

[09:06:42 CDT(-0500)] <anky> Justin_o: till when would you be online ? was working on the mock-up, would be finished in 2-3 hours
[09:06:52 CDT(-0500)] <anky> so had to discuss it with you
[09:26:08 CDT(-0500)] <Justin_o> anky: sorry.. was just in a meeting
[09:26:19 CDT(-0500)] <Justin_o> i'll be around till 4pm EDT today
[09:28:27 CDT(-0500)] <anky> thanks Justin_o, i would get back to you with the mockup and designs
[10:16:01 CDT(-0500)] <anky> Justin_o: had a doubt, theme i created is different, so it would probably not go in accordance to the 5 FSS themes available. Thats ok, right ?
[10:17:21 CDT(-0500)] <Justin_o> anky: what do you mean by that exactly?
[10:21:06 CDT(-0500)] <anky> Justin_o: like we ahve 5 fixed themes in FSS, using specific color combinations, the theme which i have made is different
[10:21:56 CDT(-0500)] <Justin_o> anky: sure.. you can make your own themes
[10:22:06 CDT(-0500)] <anky> ok thanks
[10:33:32 CDT(-0500)] <jameswy> fluid-everyone: is standup happening on the OCAD server?
[12:31:38 CDT(-0500)] <anky_> Justin_o: i am done with my mockups, can i discuss it with you right now ?
[12:33:13 CDT(-0500)] <Justin_o> anky_: sorry.. i'm just in a meeting at the moment
[12:33:29 CDT(-0500)] <anky_> ok, let me know whenever you get free
[12:56:43 CDT(-0500)] <Justin_o> heidi: this is an interesting page about hidden elements
[12:56:44 CDT(-0500)] <Justin_o> http://webaim.org/techniques/css/invisiblecontent/
[12:56:49 CDT(-0500)] <Justin_o> anky_: hello
[12:56:52 CDT(-0500)] <Justin_o> i'm available now
[12:57:57 CDT(-0500)] <anky_> Justin_o: please go through my notebook http://www.evernote.com/pub/ankurdnana/gsoc
[12:58:41 CDT(-0500)] <anky_> i have made a mockup of the design + its sketch, also there is a note anatomy of the Theme, it explains my theme
[12:59:33 CDT(-0500)] <anky_> i have not included the mockup for the focussed reader feature, search page, UI options panel on my theme - would do them in some time
[13:05:07 CDT(-0500)] <Justin_o> anky_: okay.. looking through it now.. what did you use to make your sketches? just out of curiousity
[13:05:36 CDT(-0500)] <anky_> omnigraffe - a mockup tool for mac
[13:06:49 CDT(-0500)] <anky_> *omnigraffle sorry
[13:07:23 CDT(-0500)] <Justin_o> anky_: okay.. yes i'm somewhat familiar with that.. haven't used it much myself though
[13:08:03 CDT(-0500)] <anky_> its nice, time consuming to get into the habit, but then its good
[13:10:38 CDT(-0500)] <anky_> i would soon complete the other pages too, was a bit busy with a firefox launch party we are hosting in our college
[13:17:36 CDT(-0500)] <Justin_o> anky_: (smile)
[13:20:07 CDT(-0500)] <Justin_o> anky_: so i'm not so sure about the various shades of blue for the navigation
[13:20:37 CDT(-0500)] <anky_> Justin_o: even i am not, they are jus to communicate the idea, the colors are not the final ones
[13:20:45 CDT(-0500)] <Justin_o> anky_: okay
[13:21:08 CDT(-0500)] <anky_> (somehow blue is too bright for some parts )
[13:23:52 CDT(-0500)] <Justin_o> anky_: i'm also not sure about having the two sets of navigation links (right and left side)
[13:24:15 CDT(-0500)] <Justin_o> anky_: will the "Preferences" button be what opens UI Options?
[13:25:13 CDT(-0500)] <anky_> no Justin_o, UI options button is not there, i have to put it
[13:25:21 CDT(-0500)] <Justin_o> anky_: okay
[13:25:38 CDT(-0500)] <Justin_o> anky_: the ui is getting a bit crowded i think
[13:25:50 CDT(-0500)] <Justin_o> don't feel that it has too look a lot like our current wiki
[13:25:58 CDT(-0500)] <anky_> and it does not have 2 navigation links, left side is the only one, right side is for "contents"
[13:27:08 CDT(-0500)] <Justin_o> anky_: I suppose contents is same page navigation.. so anchors to other parts of the page, the related links will probably navigate you to other portions of the wiki or external links i would guess
[13:27:48 CDT(-0500)] <anky_> ya contents is same page navigation
[13:27:54 CDT(-0500)] <anky_> see this link : http://wiki.fluidproject.org/display/fluid/Fluid+Skinning+System+%28FSS%29
[13:28:14 CDT(-0500)] <anky_> the "see also " box is what i meant when i wrote "related links"
[13:28:40 CDT(-0500)] <Justin_o> anky_: yes.. thought that's what you were getting it from..
[13:28:54 CDT(-0500)] <Justin_o> it is slightly different in that those panels are part of the content panel
[13:29:29 CDT(-0500)] <anky_> i have seen that related links are usually there, even went through mozilla wiki, so i thought if we could give them a fixed place
[13:30:34 CDT(-0500)] <anky_> the boxes are either way going to be there, so if we could give them a fixed place, and one more thing, in case these are not there, the whole side panel would not be displayed
[13:31:05 CDT(-0500)] <anky_> and if it just has related links, then that box would shift up, just below the watch option
[13:31:19 CDT(-0500)] <Justin_o> anky_: it's an interesting idea.. you just have to make sure the user won't get overwhelmed and/or confused about the ui
[13:32:31 CDT(-0500)] <anky_> i though about that also, that i would make up the UI working as early as possible and put it live, and ask for reviews from people
[13:33:11 CDT(-0500)] <anky_> so by the time, i have finished by the project, i would have already iterated upon the changes, and tested too..
[13:33:26 CDT(-0500)] <Justin_o> anky_: yes.. user testing is a good thing
[13:33:27 CDT(-0500)] <Justin_o> (smile)
[13:33:39 CDT(-0500)] <Justin_o> you can also do paper prototyping.. which is sort of what you are doing now with me
[13:34:22 CDT(-0500)] <Justin_o> so you can run your sketches/mockups by people to get feedback from earlier.. then you save yourself the time of building something tearing it down and rebuilding
[13:34:22 CDT(-0500)] <anky_> ya, i had thought of finalizing this mockup, just some changes left, and then sending the mockup with the notes on the mailing list and ask for feedback
[13:35:03 CDT(-0500)] <anky_> hmmm
[13:36:03 CDT(-0500)] <anky_> it would be ok to send the design and ask feedback on the mailing list ?
[13:36:53 CDT(-0500)] <Justin_o> anky_: you might want to take a look at some of the site designs that our designers have been working on.. jhung do you have any links to those
[13:37:42 CDT(-0500)] <jhung> justin_o, anky_: I can send you links to the work we've been doing recently for the Infusion website.
[13:37:47 CDT(-0500)] <Justin_o> anky_: sure you can send stuff to the work list... just make sure you note that it is for your gsoc proposal
[13:38:05 CDT(-0500)] <jhung> It's a bit old at this point, but it shows some process and how things come together.
[13:38:13 CDT(-0500)] <anky_> Justin_o: i did go through some presentations, and some design considerations which i could find on the wiki, but would love to see them
[13:38:40 CDT(-0500)] <anky_> jhung: please send them to ankurdnana@gmail.com.
[13:39:11 CDT(-0500)] <anky_> Justin_o: i also had to discuss one more thing, about the UI panel
[13:39:29 CDT(-0500)] <jhung> anky_: it's public information on our wiki. So do you mind if I just paste the links in here? This way others who may be interested can take a look too.
[13:39:45 CDT(-0500)] <anky_> ya sure jhung
[13:40:11 CDT(-0500)] <jhung> anky_: cool. Give me a sec to dig up the URLs.
[13:40:48 CDT(-0500)] <anky_> Justin_o: i wanted to put the UI button below the logo and above navigation, so that on clicking of it, the panel would slide down above the nav bar
[13:41:12 CDT(-0500)] <anky_> and there would be no preview panel, everything left on the right would be the preview
[13:41:46 CDT(-0500)] <anky_> ( just that i dont have much idea over how to do it, have not studied much about UI Options, would do so in the next 2-3 days
[13:41:55 CDT(-0500)] <Justin_o> anky_: no preview makes sense
[13:42:11 CDT(-0500)] <Justin_o> i'm not sure the positioning of it would work though
[13:42:41 CDT(-0500)] <anky_> Justin_o: also, as the user goes into the "Focus mode", the UI panel would automatically slide down
[13:42:43 CDT(-0500)] <Justin_o> in our new version of UI Options it's more likely to slide down from the top.. although if you wanted you could make it look however you like
[13:43:08 CDT(-0500)] <Justin_o> anky_: are you sure the user would always want it to be there..
[13:43:34 CDT(-0500)] <Justin_o> meaning that if you already set your preferences, would you want it to always be there when you go to read
[13:43:44 CDT(-0500)] <anky_> no, its just a button, so when you click, it would slide down, you do the settings and then the panel goes up
[13:44:16 CDT(-0500)] <anky_> no once the user has put his preferences for the reading mode, the panel would not slide down automatically
[13:45:19 CDT(-0500)] <Justin_o> anky_: okay
[13:45:25 CDT(-0500)] <Justin_o> makes sense
[13:46:04 CDT(-0500)] <anky_> in normal view or when the preferences are saved, the user clicks on the button, then it slides down
[13:46:21 CDT(-0500)] <anky_> in focus reading view without preferences saved, it slides down automatically
[13:47:20 CDT(-0500)] <jhung> anky_ I have some links for the sites we're designing. They don't depict interactions, rather they're more intended for layout, style, and information structure.
[13:47:37 CDT(-0500)] <jhung> anky_: Scenarios for the technical documentation. Designs, information structure docs are children to this page. http://wiki.fluidproject.org/display/fluid/Documentation+Redesign+Notes
[13:47:46 CDT(-0500)] <jhung> anky_: Multiple designs and experimentation for the Fluid Project website.
[13:47:46 CDT(-0500)] <jhung> http://wiki.fluidproject.org/display/fluid/Fluid+style+suggest+and+experimentation
[13:48:02 CDT(-0500)] <jhung> anky_: This design is the one we've settled on and refined to be our final candidate: http://wiki.fluidproject.org/display/fluid/Fluid+style+suggest+and+experimentation#Fluidstylesuggestandexperimentation-Fluidpublicsite%28fluidproject.org%29
[13:48:54 CDT(-0500)] <Justin_o> anky_: i'm thinking you may not always want it in the reading mode too
[13:49:39 CDT(-0500)] <anky_> no it would still be a slider only, the user cliks on the button and the panel slides back up
[13:50:08 CDT(-0500)] <anky_> or are you saying that it should not always slide down automatically ?
[13:50:55 CDT(-0500)] <anky_> jhung: i would go through the designs, and then get back to you if i have some doubts, thanks for the links
[13:51:08 CDT(-0500)] <Justin_o> anky_: yes the latter
[13:51:45 CDT(-0500)] <anky_> then we will not make it automatic in that case
[13:52:15 CDT(-0500)] <jhung> anky_: np
[13:52:17 CDT(-0500)] <anky_> but i would still test the automatic feature, i somehow think it might work
[13:52:31 CDT(-0500)] <Justin_o> anky_: sure.. doesn't hurt to test it out
[13:52:55 CDT(-0500)] <anky_> Justin_o: rather, it always gives you something to learn
[13:53:02 CDT(-0500)] <Justin_o> user testing is great for situations like this where you're not quite sure about the best approach.. it also ends up telling you things you may not have thought of at all
[13:54:03 CDT(-0500)] <anky_> definetly, have you read about the 80-20 rule ?
[13:54:24 CDT(-0500)] <Justin_o> anky_: oh yes..
[13:55:07 CDT(-0500)] <anky_> its a great example of the fact that user would not react the way you want
[13:56:03 CDT(-0500)] <anky_> Justin_o: did you read the anatomy note ?
[13:57:42 CDT(-0500)] <Justin_o> anky_: yes.. i think.. it looks like you were mentioning the tech you would use for each section
[13:58:05 CDT(-0500)] <anky_> ya, i wen through the FSS files in details
[14:00:49 CDT(-0500)] <Justin_o> anky_: great.. you should check it out again when 1.4 is released.. you can even follow our changes to the project repo on github to see what's going on
[14:01:23 CDT(-0500)] <Justin_o> anky_: it's mostly going to be bug fixes, but a few small new features here and there too
[14:01:37 CDT(-0500)] <anky_> i would start following it
[14:02:11 CDT(-0500)] <Justin_o> anky_: anything else you needed to chat about today
[14:03:12 CDT(-0500)] <anky_> no Justin_o, just had to discuss the mockup only. Would soon complete the remaining work and get back to you
[14:03:58 CDT(-0500)] <Justin_o> anky_: great thanks...
[14:05:40 CDT(-0500)] <anky_> Justin_o: thanks a lot, btw did you try firefox 4 ?
[14:17:19 CDT(-0500)] <Justin_o_> anky_: yes... i was using the beta for a while... it came out here a few weeks ago.. it's really nice
[14:18:22 CDT(-0500)] <anky_> i love the panaroma feature, had been waiting ever since it was posted as "tab candy" by aza raskin
[14:53:25 CDT(-0500)] <heidi> anky_ what's the panaroma feature?
[14:55:00 CDT(-0500)] <anky_> sorry its panorama heidi, its the feature through which you can arrange the tabs into groups
[14:55:35 CDT(-0500)] <heidi> anky_ sounds neat, is it a plugin or comes with?
[14:55:56 CDT(-0500)] <anky_> comes with
[14:58:05 CDT(-0500)] <anky_> heidi: you can see this link, it has a video, tab-candy is the old name of panaroma http://www.azarask.in/blog/post/designing-tab-candy/
[14:59:48 CDT(-0500)] <heidi> anky_ um, woahhhh this is rad!
[15:00:25 CDT(-0500)] <anky_> it sure is, i am a fan of aza raskin
[15:00:32 CDT(-0500)] <anky_> and his works
[15:01:45 CDT(-0500)] <heidi> thanks for the tip anky_
[15:02:10 CDT(-0500)] <anky_> anytime heidi
[15:06:41 CDT(-0500)] <mlam> Bosmon: are you free for a couple questions about these uploader tests?
[15:13:57 CDT(-0500)] <Bosmon> Hi mlam - sure, go ahead
[15:14:07 CDT(-0500)] <mlam> ok, cool
[15:15:24 CDT(-0500)] <mlam> if you look at line 111 of this file: https://github.com/fluid-project/infusion/blob/master/src/webapp/components/uploader/js/HTML5UploaderSupport.js, we create an xhr object
[15:15:43 CDT(-0500)] <mlam> so what i've done is i've pulled the instantiation of the xhr object out into a separate public function
[15:16:04 CDT(-0500)] <Bosmon> Yes
[15:16:23 CDT(-0500)] <Bosmon> So, the next step is, in order for this function to be conveniently configured via IoC, it needs to be given a proper public name
[15:16:36 CDT(-0500)] <Bosmon> Right now the name is not actually public
[15:17:22 CDT(-0500)] <mlam> i thought anything with the fluid. namespace is public?
[15:17:25 CDT(-0500)] <Bosmon> Also your current function does "too much"
[15:17:45 CDT(-0500)] <Bosmon> The version I see is named "var createFileUploadXHR" - is the code in github up to date?
[15:18:05 CDT(-0500)] <mlam> so should the progress listener and state listeners be separated out?
[15:18:15 CDT(-0500)] <mlam> yes, the url i sent you is from the main project repo
[15:18:19 CDT(-0500)] <Bosmon> Yes, since those are things that you will want to be under teat
[15:18:33 CDT(-0500)] <Bosmon> For me, line 107 reads var createFileUploadXHR = function (file, events) {
[15:18:35 CDT(-0500)] <Bosmon> Under test
[15:18:42 CDT(-0500)] <Bosmon> Which doesn't create a public function
[15:19:35 CDT(-0500)] <mlam> oh right...sorry, so what i've done is pulled out the instantation of the xhr object into a function called fluid.uploader.html5stratety.createFileUploadXHR()
[15:19:42 CDT(-0500)] <Bosmon> Ok cool
[15:19:48 CDT(-0500)] <Bosmon> Can you give me a URL to your version too?
[15:19:55 CDT(-0500)] <mlam> and then i've renamed the remainder of what's left in the funciton into something else...also in the public namespace
[15:20:12 CDT(-0500)] <mlam> i haven't pushed up yet bosmon, i've made a lot of changes since my last push
[15:20:45 CDT(-0500)] <Bosmon> One of the great benefits of github is that it's easy to push early and often (smile)
[15:21:01 CDT(-0500)] <Bosmon> Nobody minds if you have some broken or preview code in one of your personal branches...
[15:21:01 CDT(-0500)] <mlam> ok, let me do that now. and then i can better point you to some line numbers.
[15:21:06 CDT(-0500)] <mlam> ok
[15:21:09 CDT(-0500)] <Bosmon> Cool, thanks
[15:23:28 CDT(-0500)] <mlam> ok Bosmon: https://github.com/mlam/infusion/blob/FLUID-4163/src/webapp/tests/component-tests/uploader/js/UploaderTests.js
[15:23:39 CDT(-0500)] <mlam> the only thing that matters in this file right now is the function beginning at line 348
[15:23:52 CDT(-0500)] <Bosmon> Ok, looking at it now
[15:24:21 CDT(-0500)] <Bosmon> akh, they still haven't fixed this line number bug with Chrome ;P
[15:24:31 CDT(-0500)] <mlam> (sad)
[15:24:40 CDT(-0500)] <mlam> it's the function called checkHTML5Uploader
[15:25:28 CDT(-0500)] <mlam> so what i've done is i've tested to see what happens after the file dialog is closed. at which case the onFilesQueued event is fired
[15:26:01 CDT(-0500)] <mlam> the result of this is that files are added to the queue. so i've confirmed a couple things that will happen: the queue is updated, and the status region at the bottom of the uploader gets updated
[15:26:22 CDT(-0500)] <Bosmon> Ok, this looks like a good test
[15:26:28 CDT(-0500)] <mlam> ok, good ...so far so good.
[15:26:38 CDT(-0500)] <Bosmon> The one thing that concerns me that it is called "checkHTML5Uploader"
[15:26:47 CDT(-0500)] <Bosmon> Is there anything specific to a particular configuration of the Uploader in this test?
[15:26:56 CDT(-0500)] <mlam> so i'll add a few more tests in a similar fashion that tests the local.
[15:27:09 CDT(-0500)] <mlam> Not yet, i'm just going to put everything into that function then separate it out afterwards
[15:27:14 CDT(-0500)] <mlam> the funciton will be renamed
[15:27:51 CDT(-0500)] <Bosmon> Another thing that would be good to see is the removal of some more of the duplicated code between the tests, if you could get round to that
[15:28:10 CDT(-0500)] <Bosmon> So, for example, lines like this appear in every test:
[15:28:11 CDT(-0500)] <Bosmon> var container = $(".flc-uploader");
[15:28:11 CDT(-0500)] <Bosmon> var that = fluid.uploader(container);
[15:28:15 CDT(-0500)] <mlam> Yes, that's also in the plan. To have a generic "utility" file for all the uploader tests
[15:28:31 CDT(-0500)] <mlam> ie. the set up code.
[15:28:35 CDT(-0500)] <Bosmon> cool
[15:29:13 CDT(-0500)] <mlam> ok, so back to the original question. now that the xhr is in a separate public function how can i cleanly override it to test the remote with my own dummy xhr object?
[15:29:17 CDT(-0500)] <Bosmon> A good way of organising it would be to have just ONE instance of uploader.test(....) for all of these cases, which is parameterised by some kind of "strategy function"
[15:29:33 CDT(-0500)] <Bosmon> Since the variable material is generally in the MIDDLE of the test rather than at the ends
[15:30:02 CDT(-0500)] <Bosmon> Actually I notice that your argument map checking functions are actually identical
[15:30:08 CDT(-0500)] <Bosmon> So those could be folded together too
[15:30:16 CDT(-0500)] <Bosmon> Ok, yes, back to your question (smile)
[15:30:21 CDT(-0500)] <mlam> Yes, I moved focus away from those for now (smile)
[15:30:43 CDT(-0500)] <Bosmon> You want to be able to set things up so that the choice of XHR function can be configured via IoC
[15:31:17 CDT(-0500)] <Bosmon> The best way to do this is to have the function which actually constructs the XHR to be either a subcomponent, or an invoker, attached to the component in question
[15:31:36 CDT(-0500)] <mlam> which is better?
[15:31:44 CDT(-0500)] <Bosmon> And then to write a demands block which resolves the XHR constructor one way in the live app, and a different way in the test case
[15:31:51 CDT(-0500)] <Bosmon> Well, to some extent it is a matter of taste (tongue)
[15:32:00 CDT(-0500)] <Bosmon> I know that yura_ is extremely fond of invokers, for example (tongue)
[15:32:07 CDT(-0500)] <mlam> which is less code?
[15:32:13 CDT(-0500)] <mlam> an invoker is, right?
[15:32:40 CDT(-0500)] <Bosmon> Personally I've always been a little suspicious of invokers, but I think we are still gathering experience about what the long-term implications are of one choice rather than another
[15:32:50 CDT(-0500)] <Bosmon> Yes, probably an invoker would be a better fit here
[15:32:52 CDT(-0500)] <colinclark> I have a particular suspicion about invokers
[15:33:00 CDT(-0500)] <colinclark> and that's just that they get resolved each time they are invoked
[15:33:05 CDT(-0500)] <colinclark> which in many cases is not necessary
[15:33:06 CDT(-0500)] <Bosmon> Since it is something that i) you don't expect to have any further substructure, and ii) just does some work once and gets out of the way
[15:33:08 CDT(-0500)] <colinclark> but they are very cool
[15:33:14 CDT(-0500)] <Bosmon> colinclark - yes, that's correct
[15:33:25 CDT(-0500)] <Bosmon> It has been on the table for a while to make "more efficient" kinds of invokers
[15:33:29 CDT(-0500)] <Bosmon> But that is certainly one big drawback, yes
[15:33:56 CDT(-0500)] <Bosmon> So writing a subcomponent has the effect of slightly more verbose syntax for the caller
[15:34:05 CDT(-0500)] <Bosmon> You would write something like that.xhrMaker.make() or some such
[15:34:17 CDT(-0500)] <Bosmon> Whereas invokers "look like" plain functions
[15:34:50 CDT(-0500)] <Bosmon> Anyway, if it were yura_ writing these test cases, I am quite sure he would use an invoker (smile)
[15:35:55 CDT(-0500)] <mlam> ok, so if i go with an invoker, it would go under the the doUpload invoker in the defaults block of line 169
[15:35:59 CDT(-0500)] <mlam> right?
[15:35:59 CDT(-0500)] <Bosmon> colinclark - out of interest, any other concerns about invokers?
[15:36:14 CDT(-0500)] <colinclark> Bosmon: Nope
[15:36:15 CDT(-0500)] <colinclark> They're wicked
[15:36:19 CDT(-0500)] <Bosmon> The efficiency issue is one we can tackle reasonably straightforwardly I think
[15:36:28 CDT(-0500)] <colinclark> Just that there are lots of cases where you really only want to resolve their arguments once
[15:36:31 CDT(-0500)] <Bosmon> Yes
[15:36:34 CDT(-0500)] <colinclark> and then invoke them over and over again
[15:36:50 CDT(-0500)] <Bosmon> Certainly, in the case like this, where they don't even take any arguments (tongue)
[15:36:58 CDT(-0500)] <colinclark> (smile)
[15:37:28 CDT(-0500)] <Bosmon> mlam - which file are you looking at, with line 169?
[15:38:00 CDT(-0500)] <mlam> maybe i should point to the file in my branch instead of the main branch.
[15:38:33 CDT(-0500)] <mlam> https://github.com/mlam/infusion/blob/FLUID-4163/src/webapp/components/uploader/js/HTML5UploaderSupport.js
[15:38:40 CDT(-0500)] <mlam> so line 177 of the above file
[15:39:16 CDT(-0500)] <Bosmon> mlam - yes, that looks like a perfect place to configure this invoker
[15:40:08 CDT(-0500)] <mlam> ok, so now define the invoker, create the function being invoked which simply is an xhr creator function and returns the created xhr
[15:40:20 CDT(-0500)] <Bosmon> yup
[15:41:29 CDT(-0500)] <mlam> so i think this is my last question for now, how do i resolve this by IoC? create a separate demands block in the test file and set the invoker to the function in my test file that creates the dummy xhr?
[15:41:40 CDT(-0500)] <Bosmon> That's correct, yes
[15:42:11 CDT(-0500)] <Bosmon> The other missing element is to attach a "type tag" into the fluid.staticEnvironment that indicates, in the testing file, that you are in a configuration for testing
[15:42:19 CDT(-0500)] <Bosmon> We do something very similar in CollectionSpace, for example
[15:42:45 CDT(-0500)] <Bosmon> In fact there, there are TWO such tags - one of them indicates that we are in a "local filesystem" configuration, and the 2nd one distinguishes whether this is an automated test or not
[15:42:59 CDT(-0500)] <mlam> what happens if i don't include the type tag?
[15:43:32 CDT(-0500)] <Bosmon> Leaving out the type tag signifies you are in the "live" configuration and that the real XHR invoker should be used
[15:43:53 CDT(-0500)] <flyankur> hey guys, any one working on FSS based theme for drupal ?
[15:43:59 CDT(-0500)] <Bosmon> So, to be clear, you will set up two versions of this invoker
[15:44:15 CDT(-0500)] <Bosmon> One, which produces the live XHR, and the other which produces the mock
[15:44:23 CDT(-0500)] <flyankur> any related proposal this google summer of code ?
[15:44:24 CDT(-0500)] <Bosmon> And these will be configured in using two different demands blocks
[15:44:39 CDT(-0500)] <Bosmon> One written in the main file, and one written in the testing file
[15:44:58 CDT(-0500)] <Bosmon> And only in the testing file is the type tag put into the staticEnvironment that causes resolution onto the mock version
[15:45:01 CDT(-0500)] <Bosmon> Does that make sense?
[15:45:49 CDT(-0500)] <Bosmon> Really we should already standardise these tags across all test cases for Infusion
[15:46:08 CDT(-0500)] <mlam> so the first way i described the invoker is the one that produces the live XHR. the 2nd invoker in my test code is to call the function i created which creates the dummy invoker, right?
[15:46:19 CDT(-0500)] <Bosmon> That's right, yes
[15:46:44 CDT(-0500)] <mlam> Ok, makes sense. just re-reading the above about the type tag to make sure i understand
[15:46:57 CDT(-0500)] <michelled> flyankur: I'm not really sure
[15:47:09 CDT(-0500)] <michelled> flyankur: justin_o or heidi may know
[15:47:12 CDT(-0500)] <Bosmon> The type tag works in just the same way that the ProgressiveEnhancer does - we treat "the testing environment" just like another configuration
[15:47:19 CDT(-0500)] <michelled> although both are away from their computers at the moment
[15:47:21 CDT(-0500)] <Bosmon> Since one of the main uses of IoC is to facilitate testing
[15:48:03 CDT(-0500)] <mlam> do you know where i can see this in the collectionspace code?
[15:48:13 CDT(-0500)] <michelled> mlam: I was about to drop this in for you: https://github.com/yzen/ui/blob/master/src/test/js/CSpaceTests.js
[15:48:24 CDT(-0500)] <Bosmon> Thanks, michelled
[15:48:50 CDT(-0500)] <flyankur> michelled, thanks. As my drupal UX developers, drupal really need good themes, frameworks like FSS could really do the work
[15:48:55 CDT(-0500)] <michelled> that has the type tag but not the demands blocks
[15:49:28 CDT(-0500)] <Bosmon> The ordering of demands blocks in CSpace is not completely as we would recommend yet, but this is being fixed up over time
[15:49:32 CDT(-0500)] <flyankur> michelled, as my experience as drupal ux developer*
[15:49:36 CDT(-0500)] <Bosmon> But you can see the basic approach working here
[15:49:56 CDT(-0500)] <Bosmon> So, this is a file included by every CollectionSpace test case
[15:50:03 CDT(-0500)] <Bosmon> And at the start it issues this line:
[15:50:04 CDT(-0500)] <Bosmon> fluid.staticEnvironment.cspaceTests = fluid.typeTag("cspace.test");
[15:50:29 CDT(-0500)] <michelled> flyankur: yep, seems to be a consistent problem in software (smile)
[15:51:07 CDT(-0500)] <michelled> mlam, Bosmon: the demands are all in a singe file right now. the test ones will eventually be pulled out of here
[15:51:08 CDT(-0500)] <michelled> https://github.com/yzen/ui/blob/master/src/main/webapp/js/Demands.js
[15:51:13 CDT(-0500)] <flyankur> heidi, is there a drupal themeing related work being initiated this gsoc ?
[15:51:29 CDT(-0500)] <flyankur> heidi, or apart from gsoc.
[15:51:40 CDT(-0500)] <michelled> mlam: line 884 is where the test demands start
[15:51:47 CDT(-0500)] <Bosmon> So lower down in this file you can see a simple use of this type tag
[15:51:49 CDT(-0500)] <Bosmon> fluid.demands("messageBar", "cspace.test", {
[15:51:49 CDT(-0500)] <Bosmon> container: "body"
[15:51:49 CDT(-0500)] <Bosmon> });
[15:52:10 CDT(-0500)] <Bosmon> These lines supply configuration for the "messageBar" component which is active only in the testing environment
[15:52:44 CDT(-0500)] <colinclark> flyankur: So we have this GSoC project related to creating themes with FSS for a variety of CMSs, including Drupal
[15:52:50 CDT(-0500)] <colinclark> One student has applied so far
[15:52:51 CDT(-0500)] <mlam> ohhh
[15:53:07 CDT(-0500)] <colinclark> heidi has also done work with FSS in Drupal, but hasn't created a formal theme for it
[15:53:12 CDT(-0500)] <mlam> I see it now. Ok, it was good for me to see it in action
[15:53:27 CDT(-0500)] <colinclark> I totally agree, flyankur, that an FSS and UI Options-based theme in Drupal would be really great
[15:53:32 CDT(-0500)] <colinclark> are you interested in contributing to the effort?
[15:53:57 CDT(-0500)] <colinclark> justin_o is the official mentor of that GSoC project, by the way
[15:54:10 CDT(-0500)] <Bosmon> So you can see the advantage of this approach - we can inject the "mock" XHR creator into the uploader without the uploader's code having to change
[15:54:18 CDT(-0500)] <Bosmon> And we can keep the code which does the injection all in the same file
[15:54:29 CDT(-0500)] <Bosmon> That is, in the testing file
[15:54:39 CDT(-0500)] <mlam> Yes
[15:55:04 CDT(-0500)] <Bosmon> Another kind of test might, for example, require a different kind of mock, or a different configured mock - but that code could be isolated too
[15:55:40 CDT(-0500)] <flyankur> colinclark, yes, i am totally upto it , i can co-mentor or help in anyway i can. It is not necessary to be primary mentor . right ?
[15:56:18 CDT(-0500)] <flyankur> flyankur, i am gsoc 2009 student, i had 3 mentors , 1 primary and other 2 helping me in anycase.
[15:56:28 CDT(-0500)] <flyankur> colinclark, ^
[15:58:39 CDT(-0500)] <flyankur> colinclark, can i put my reviews/comments on the proposals - is it on mailing list or only on melange ?
[16:00:48 CDT(-0500)] <mlam> Bosmon: you have time for one more?
[16:01:39 CDT(-0500)] <Bosmon> mlam - sure - I need to step out for a couple of minutes, but type your question here and I will answer it shortly
[16:01:57 CDT(-0500)] <mlam> ok. it's about testing the removal of a file from the queue
[16:02:13 CDT(-0500)] <mlam> https://github.com/mlam/infusion/blob/FLUID-4163/src/webapp/components/uploader/js/FileQueueView.js if you look at line 157, a click handler is created to remove a file from the queue
[16:03:19 CDT(-0500)] <mlam> so for me to test this, I'll have to manually locate the row of interest, then locate the fileIcon button and call a click on it to invoke the function to delete?
[16:03:49 CDT(-0500)] <Bosmon> Well, that would be a very full kind of "integration" test, yes
[16:04:06 CDT(-0500)] <Bosmon> One thing to keep in mind is how these various test fixtures can be pooled together and executed in different contexts
[16:04:18 CDT(-0500)] <mlam> I made a half attempt in the commented out code of line 364: https://github.com/mlam/infusion/blob/FLUID-4163/src/webapp/tests/component-tests/uploader/js/UploaderTests.js
[16:04:30 CDT(-0500)] <Bosmon> I mean, this would be a useful kind of test to issue against the uploader itself, separately from any particular issues surrounding XHR
[16:04:49 CDT(-0500)] <Bosmon> But that is the kind of test we DO have against many of our components, where it is possible
[16:04:53 CDT(-0500)] <flyankur> colinclark, are you there ?
[16:05:02 CDT(-0500)] <Bosmon> For example, the Reorderer "animates" itself in its test cases in this kind of way
[16:05:19 CDT(-0500)] <Bosmon> it is only a shame that it is currently impossible to simulate mouse dragging operations in the browser currently, or we would test even more
[16:06:04 CDT(-0500)] <Bosmon> So mlam, conceptually, this approach is ok - just bear in mind ways you can make your test fixture as reusable as possible
[16:06:22 CDT(-0500)] <Bosmon> I'm wondering why you took the trouble to clone the template row in the commented out line 364?
[16:08:08 CDT(-0500)] <mlam> A simple locate would better, huh?
[16:09:20 CDT(-0500)] <colinclark> flyankur: Sorry, I was in a meeting... let me just catch up
[16:09:38 CDT(-0500)] <flyankur> colinclark, no problems
[16:10:56 CDT(-0500)] <colinclark> mlam, Bosmon: I'm pretty sure some of the Uploader tests already create a testing type tag
[16:11:08 CDT(-0500)] <colinclark> you could either use it as an example or modify the existing uses of it to suit what you're doing
[16:11:38 CDT(-0500)] <colinclark> flyankur: we'd love to have you co-mentor
[16:11:47 CDT(-0500)] <colinclark> At the moment, the applications are all up on melange
[16:11:59 CDT(-0500)] <colinclark> We've had students in chatting about their work here in the channel
[16:12:08 CDT(-0500)] <flyankur> colinclark, i have applied on melange as mentor, but i think i have been rejected
[16:12:22 CDT(-0500)] <colinclark> flyankur: I'll talk to greggy about it
[16:12:27 CDT(-0500)] <colinclark> He probably rejected you, not knowing
[16:12:38 CDT(-0500)] <colinclark> If you take a look at the channel archives for today and yesterday, you'll see justin_o and anky (the prospective student) chatting about ideas.
[16:13:07 CDT(-0500)] <colinclark> flyankur: If you're around sometime tomorrow, ping justin_o and he can start to work with you
[16:13:14 CDT(-0500)] <colinclark> and in the meantime I'll let him know
[16:13:21 CDT(-0500)] <colinclark> I'm really excited that you want to help out!
[16:13:35 CDT(-0500)] <flyankur> colinclark, ok - great. looking up to it.
[16:13:44 CDT(-0500)] <colinclark> awesome!
[16:16:42 CDT(-0500)] <flyankur> colinclark, same here. I would really be very happy if we could get a FSS based drupal theme out by the august.
[16:16:55 CDT(-0500)] <colinclark> I think that's quite doable
[16:17:12 CDT(-0500)] <colinclark> Do you know our friend Everett Zufelt, who contributes a lot to Drupal accessibility?
[16:17:37 CDT(-0500)] <flyankur> colinclark, while informing justin_o , could you also CC me , so that we get introduced
[16:19:00 CDT(-0500)] <flyankur> i personally dont know EverettZ, but i seen him around and into few very small conversations
[16:22:02 CDT(-0500)] <Bosmon> mlam - yes
[16:22:26 CDT(-0500)] <mlam> ok, thanks for your help today Bosmon
[16:22:30 CDT(-0500)] <Bosmon> The commented out code is dubious - because it doesn't actually test the implementation
[16:22:44 CDT(-0500)] <mlam> right
[16:22:46 CDT(-0500)] <Bosmon> I guess this is an issue that increasingly looms large in test cases
[16:23:09 CDT(-0500)] <Bosmon> By "duplicating" part of the implementation (as you did on Tuesday for the XHR mocking) you remove the possibility of actually testing that part of the implementation
[16:23:16 CDT(-0500)] <Bosmon> So you are "testing the test" as it is called (tongue)
[16:23:42 CDT(-0500)] <mlam> right
[16:23:51 CDT(-0500)] <Bosmon> Ok, well, good luck with this
[16:23:54 CDT(-0500)] <Bosmon> Let's talk again tomorrow
[16:24:28 CDT(-0500)] <mlam> ok, sounds good