[09:04:42 CDT(-0500)] <heidi_> Justin_o if a unit test fails in the swarm, does it alert somehow? <colinclark> jpg: <Bosmon> You can refer to the "direct arguments" using the " .n" syntax
[09:05:24 CDT(-0500)] <Justin_o> heidi_: it will show up red on the chart
[09:05:45 CDT(-0500)] <Justin_o> if you log into the swarm with the team account credentials you can see it
[09:06:09 CDT(-0500)] <heidi_> Justin_o team account credentials?
[09:06:20 CDT(-0500)] <anastasiac> Justin_o, I think the formatting in your email to the list got lost a bit - it's not quite clear which browser/os configurations you'd like to test
[09:07:04 CDT(-0500)] <Justin_o> anastasiac: oh yuck... you're right.. i'll try to fix that up
[09:08:02 CDT(-0500)] <heidi_> Justin_o after logging in this chart seems to help figure out which browsers haven't been tested... so maybe mention the login thing too?
[09:08:33 CDT(-0500)] <Justin_o> heidi_: okay.. makes sense
[09:11:54 CDT(-0500)] <heidi_> Justin_o would a wiki page for this be better than assigning browsers via email
[09:13:08 CDT(-0500)] <Justin_o> heidi_: okay.. i'll just update the testing tasks page for it then.. that might be easier
[09:18:32 CDT(-0500)] <heidi_> Justin_o swarm seems to be running through unit tests for each commit... is that necessary or is it just the latest or?
[09:18:42 CDT(-0500)] <harriswong> heidi_, justin_o: +1 on chart
[09:19:03 CDT(-0500)] <Justin_o> heidi_: you can let it run through each commit that's fine.. for this testing though we are only interested in the latest one though
[09:19:14 CDT(-0500)] <harriswong> ^i meant +1 on testing tasks page chart than email
[09:19:47 CDT(-0500)] <heidi_> Justin_o why would i let run through each commit? that seems unnecessary
[09:20:15 CDT(-0500)] <mlam> heidi_: ^^ + 1
[09:21:36 CDT(-0500)] <Justin_o> heidi_: it might be usefull if we ever need to go back and check when an error occured for example... or if we need to roll something back.. to see if there were issues that it may have resolved
[09:21:52 CDT(-0500)] <heidi_> Justin_o okay
[09:22:01 CDT(-0500)] <Justin_o> heidi_, mlam, harriswong: here's the task page http://wiki.fluidproject.org/display/fluid/Release+Testing+Tasks
[09:22:43 CDT(-0500)] <Justin_o> heidi_: for today though, if you are using a vm and need to shut it off before it runs through all the backlog of testswarm tasks. that's fine
[09:22:59 CDT(-0500)] <heidi_> Justin_o cool thanks
[09:24:45 CDT(-0500)] <heidi_> Justin_o i took safari 5 10.6 fyi
[09:26:19 CDT(-0500)] <Justin_o> heidi_: thanks
[09:26:40 CDT(-0500)] <harriswong> justin_o: is IE9 chrome not there for a reason?
[09:26:46 CDT(-0500)] <harriswong> uh Win7 chrome*
[09:28:17 CDT(-0500)] <Justin_o> harriswong: 
[09:28:17 CDT(-0500)] <Justin_o> y
[09:28:33 CDT(-0500)] <Justin_o> yes.. we don't have a-grade support for it
[09:28:41 CDT(-0500)] <harriswong> justin_o: ok
[09:28:45 CDT(-0500)] <Justin_o> harriswong: http://wiki.fluidproject.org/display/fluid/Browser+Support
[09:45:17 CDT(-0500)] <harriswong> Justin_o: how do you log into the testswarm?
[09:45:51 CDT(-0500)] <harriswong> ^do i need to sign up or is there a test-purpose username/pwd
[10:12:25 CDT(-0500)] <colinclark> Morning, Justin_o
[10:12:50 CDT(-0500)] <colinclark> Justin_o and cindyli: I'm terribly forgetful these days... I can't remember if there was something I needed to look into for the new PHP Uploader test server?
[10:13:07 CDT(-0500)] <Justin_o> colinclark: funny i was just going to ask you both about that
[10:13:17 CDT(-0500)] <cindyli>
[10:14:08 CDT(-0500)] <cindyli> colinclark: the infinite loop at the second uploader instantiation in IE
[10:14:15 CDT(-0500)] <colinclark> ok
[10:14:21 CDT(-0500)] <colinclark> Is there a JIRA for this?
[10:14:24 CDT(-0500)] <cindyli> no
[10:14:31 CDT(-0500)] <cindyli> should i create one?
[10:14:37 CDT(-0500)] <colinclark> Can you file one real quick with some instructions on how to reproduce it?
[10:14:42 CDT(-0500)] <colinclark> And then I'll try to fix it right away
[10:14:43 CDT(-0500)] <cindyli> sure
[10:14:49 CDT(-0500)] <colinclark> I'm on an Uploader roll these days
[10:14:52 CDT(-0500)] <colinclark> thanks so much, cindyli
[10:14:54 CDT(-0500)] <colinclark> hey mlam
[10:14:59 CDT(-0500)] <colinclark> Your fileTypes fix is now
[10:15:05 CDT(-0500)] <colinclark> I made one notable change that I want to run past you
[10:15:11 CDT(-0500)] <mlam> cool
[10:15:13 CDT(-0500)] <colinclark> I'm a bit worried I might have oversimplified something
[10:16:04 CDT(-0500)] <mlam> what was oversimplified?
[10:16:05 CDT(-0500)] <colinclark> So this is what the MimeTypesExtensions.js file looks like now: https://github.com/fluid-project/infusion/blob/master/src/webapp/components/uploader/js/MimeTypeExtensions.js
[10:16:33 CDT(-0500)] <colinclark> As I was reading your algorithm for using this data structure, and looking at writing my own to go the other direction, I couldn't quite figure out why it had been structured as it was
[10:16:42 CDT(-0500)] <colinclark> So it used to look roughly like this:
[10:17:04 CDT(-0500)]
[10:17:11 CDT(-0500)] <mlam> right
[10:17:25 CDT(-0500)] <colinclark> Which meant we had to do an extra property lookup to get at what we wanted
[10:17:44 CDT(-0500)] <colinclark> How come you keyed the structure by the file extension, but then also included the "ext" property?
[10:17:45 CDT(-0500)] <mlam> It was in that structure so that we have the ability to convert from one type to another if we ever needed to
[10:18:56 CDT(-0500)] <mlam> But I guess if we want to enforce the use of MIME types, there would only ever be one conversion
[10:19:39 CDT(-0500)] <colinclark> Can you elaborate on your first point?
[10:22:28 CDT(-0500)] <mlam> Sure. Before the backwards compatibility functionality was in place, I thought that we may want to reuse the option of converting from a MIME type to a file extension in the HTML5 strategy if the integrator didnt' upgrade to 1.4
[10:24:28 CDT(-0500)] <Justin_o> colinclark, michelled_, cindyli, jameswy, jhung: would any of you be able to help with a bit of testing.. we have four more configurations still open for testing that I could assign to you
[10:24:49 CDT(-0500)] <michelled_> Justin_o: I can help this afternoon
[10:24:54 CDT(-0500)] <cindyli> Justin_o: i sure can
[10:25:12 CDT(-0500)] <Justin_o> here are the taks http://wiki.fluidproject.org/display/fluid/Release+Testing+Tasks
[10:25:25 CDT(-0500)] <Justin_o> cindyli: would you be able to grab one of the IE tasks
[10:25:41 CDT(-0500)] <cindyli> sure
[10:25:51 CDT(-0500)] <Justin_o> cindyli: thanks
[10:25:59 CDT(-0500)] <cindyli> Justin_o: np
[10:26:16 CDT(-0500)] <cindyli> colinclark: for php image uploader bug: http://issues.fluidproject.org/browse/FLUID-4238
[10:27:32 CDT(-0500)] <colinclark> mlam: Were you thinking of something along the lines of this? https://github.com/fluid-project/infusion/blob/master/src/webapp/components/uploader/js/UploaderCompatibility-Infusion1.3.js#L30-52
[10:27:44 CDT(-0500)] <colinclark> Thanks cindyli
[10:27:55 CDT(-0500)] <cindyli> np, colinclark
[10:28:06 CDT(-0500)] <colinclark> Justin_o: Yes, please feel free to assign me something
[10:28:24 CDT(-0500)] <mlam> colinclark: Yes
[10:28:34 CDT(-0500)] <colinclark> Okay, interesting
[10:28:43 CDT(-0500)] <jhung> justin_o: possibly be able to help out, but not right away. If I have time, I'll pick up some of the Win7 tasks.
[10:29:05 CDT(-0500)] <colinclark> I found the algorithm was easier to write by just having a flat structure (i.e. "ext":"mimeType")
[10:29:26 CDT(-0500)] <colinclark> And for SWFUpload's sake, concatenating "*." and ";" to the extension
[10:29:34 CDT(-0500)] <colinclark> Do you think I'm missing anything here?
[10:30:03 CDT(-0500)] <mlam> No, I don't. I think the way you wrote it definitely has it's advantages. There's a lot less to keep track of
[10:30:26 CDT(-0500)] <colinclark> I guess its weakness will always be if we want to add some additional piece of information
[10:30:32 CDT(-0500)] <colinclark> like, say, a description of the file type
[10:30:45 CDT(-0500)] <mlam> Yeah, but I guess that can always be refactored later if we actually need it
[10:30:55 CDT(-0500)] <colinclark> or perhaps placed somewhere else
[10:44:33 CDT(-0500)] <jessm> greggy1: ping
[10:44:48 CDT(-0500)] <greggy1> jessm: hey
[10:44:59 CDT(-0500)] <jessm> greggy1: let's talk on skype about ILDH
[10:45:12 CDT(-0500)] <greggy1> k
[10:46:05 CDT(-0500)] <Justin_o> jhung: i think the win7 tasks are all taken already
[10:46:15 CDT(-0500)] <Justin_o> colinclark: you mind doing IE 6
[10:46:27 CDT(-0500)] <colinclark> me and my big mouth 
[10:46:32 CDT(-0500)] <colinclark> sure, I'd be happy to
[10:46:39 CDT(-0500)] <Justin_o> colinclark: thanks
[10:55:35 CDT(-0500)] <colinclark> mlam: The other thing I did with your branch was largely stylistic... super minor, but thought you'd be interested...
[10:55:55 CDT(-0500)] <colinclark> I refactored your fileTypeTransformer to use a set of nested calls to fluid.each() instead of for loops
[10:56:11 CDT(-0500)] <colinclark> The for loops are inevitably faster, but the code is quite a bit simpler and more compact with .each()
[10:56:17 CDT(-0500)] <colinclark> I guess it's one of those balancing acts
[10:56:28 CDT(-0500)] <colinclark> I am working on a JavaScript audio synthesis library in my spare time
[10:56:47 CDT(-0500)] <colinclark> there, I have to avoid .each() completely, because the cost of a function call is just too high while generating a real-time signal
[10:56:59 CDT(-0500)] <colinclark> in our case an extra 1/3 of a microsecond shoudn't count for much
[10:57:00 CDT(-0500)] <colinclark> https://github.com/fluid-project/infusion/blob/master/src/webapp/components/uploader/js/FlashUploaderSupport.js#L186-206
[10:57:28 CDT(-0500)] <mlam> ok, cool
[10:57:47 CDT(-0500)] <mlam> I should've used fluid.each() though. If it's in the framework, use it
[10:57:54 CDT(-0500)] <colinclark> lol
[10:58:12 CDT(-0500)] <mlam> I used it in my tests, so I'm not sure why I didn't use it here
[10:58:18 CDT(-0500)] <colinclark> Ideally, we could have said "it's in jQuery, so use it," but their implementation is problematic on several levels
[10:58:30 CDT(-0500)] <colinclark> As I say, it's largely stylistic
[10:58:33 CDT(-0500)] <colinclark> not a big deal at all
[10:58:38 CDT(-0500)] <mlam> coolio
[11:09:52 CDT(-0500)] <colinclark> cindyli, Justin_o: So I can confirm that the Uploader's problems in IE with the server are due to SWFUpload
[11:10:11 CDT(-0500)] <colinclark> So I'll see if there's a clean way to destroy and reinstantiate SWFUpload
[11:10:20 CDT(-0500)] <cindyli> thx, colinclark
[11:10:39 CDT(-0500)] <colinclark> when in doubt, blame swfupload
[11:10:44 CDT(-0500)] <cindyli>
[11:16:29 CDT(-0500)] <anastasiac> Justin_o, if I'm filing a bug that I have just found, what version should I file it against?
[11:17:03 CDT(-0500)] <Justin_o> anastasiac: i would file a fix for 1.4 for now
[11:17:16 CDT(-0500)] <anastasiac> ok, thanks
[11:17:31 CDT(-0500)] <Justin_o> anastasiac: i'm not sure what to do for the affects version.. i think leave it blank or 1.4
[11:26:30 CDT(-0500)] <colinclark> cindyli: So I think what I'll do is start by turning your Uploader server JavaScript code into a View Component
[11:26:54 CDT(-0500)] <colinclark> and then I should be able to, at least in theory, remove the old Uploader from the DOM and zap SWFUpload in a method on it
[11:27:48 CDT(-0500)] <cindyli> oh. ic
[11:28:05 CDT(-0500)] <cindyli> let me know if anything i can help, colinclark
[11:28:08 CDT(-0500)] <colinclark> SWFUpload seems to have a destroy() method
[11:28:15 CDT(-0500)] <colinclark> cindyli: You're busy enough with UI Options
[11:28:25 CDT(-0500)] <colinclark> but if I end up making a mess, I'll ask for help 
[11:28:29 CDT(-0500)] <cindyli> thx
[11:29:49 CDT(-0500)] <anastasiac> Justin_o, colinclark and mlam: I've filed a JIRA for that Uploader "stop" problem I'm seeing: http://issues.fluidproject.org/browse/FLUID-4240
[11:30:00 CDT(-0500)] <Justin_o> anastasiac: thanks
[11:30:17 CDT(-0500)] <colinclark> What browsers, anastasiac?
[11:30:25 CDT(-0500)] <anastasiac> I'm just updating that now
[11:30:31 CDT(-0500)] <anastasiac> FFF3.6 and FF4
[11:30:40 CDT(-0500)] <colinclark> mlam: anastasiac's instructions remind me that we still have some crud in the Uploader demo
[11:30:53 CDT(-0500)] <colinclark> Do you feel like your unit tests are now robust enough that we can get rid of Bosmon's temporary buttons in the demo?
[11:31:44 CDT(-0500)] <mlam> colinclark: Yes, I think so. Although, maybe we should confirm with Bosmon first before removing them?
[11:31:57 CDT(-0500)] <colinclark> mlam: Go ahead and make a branch to do so
[11:32:09 CDT(-0500)] <colinclark> and then make a pull request with his name in it
[11:32:13 CDT(-0500)] <mlam> Ok
[11:33:21 CDT(-0500)] <colinclark> Am I mistaken in thinking I just need to click Stop twice to get it to actually stop after the current file?
[11:33:36 CDT(-0500)] * anastasiac is double-checking
[11:33:49 CDT(-0500)] <colinclark> anastasiac: If you think you've found any related JIRAs, like ones for the fact that the Stop button doesn't get disabled, can you link them to this one?
[11:34:33 CDT(-0500)] <anastasiac> colinclark, that's not what I'm observing: If I just click stop twice, then the last two of the files don't upload
[11:34:39 CDT(-0500)] <anastasiac> and yes, I'll relate them
[11:35:40 CDT(-0500)] <colinclark> I'm not sure I'm seeing that, anastasiac
[11:39:44 CDT(-0500)] <colinclark> mlam, Justin_o, it seems like the salient point from this bug is that in order to get Uploader to stop the way it should, you need to press the Stop button as many times as there are files in the queue
[11:39:56 CDT(-0500)] <colinclark> anastasiac's Variation B at the bottom of her JIRA
[11:40:09 CDT(-0500)] <colinclark> If you have 5 files, you have to click Stop 5 times to get it to do the right thing
[11:40:18 CDT(-0500)] <colinclark> Fewer clicks will eventually get it to to stop
[11:40:28 CDT(-0500)] <colinclark> but not where you'd expect it rto
[11:41:42 CDT(-0500)] <mlam> colinclark: want me to tackle this one?
[11:41:48 CDT(-0500)] <colinclark> that'd be awesome, yes
[11:41:51 CDT(-0500)] <colinclark> thanks, dude
[11:42:03 CDT(-0500)] <mlam> ok, cool np
[11:50:57 CDT(-0500)] <colinclark> cindyli: Componentizing your Uploader demo is a revelation
[11:51:00 CDT(-0500)] <colinclark> can't wait to show it to you
[11:54:24 CDT(-0500)] <cindyli> colinclark: cannot wait to see it
[12:09:59 CDT(-0500)] <heidi_> hey jhung did you change the select styles for reorder? i'm looking at http://build.fluidproject.org/infusion/demos/reorderer/layoutReorderer/demo.html
[12:10:12 CDT(-0500)] <heidi_> and the blue outline goes away when i move the box. seems like it should stay
[12:12:05 CDT(-0500)] <heidi_> jhung n/m must be a safari thing
[12:12:21 CDT(-0500)] <jhung> heidi_ the problem may be in Chrome too.
[12:12:44 CDT(-0500)] <jhung> select style is a black border. then move style is thin yellow?
[12:13:23 CDT(-0500)] <heidi_> jhung the width of the outline on the left side boxes is too wide
[12:13:52 CDT(-0500)] <heidi_> there's other weirdness going on in firefox... now that focus can be on the divs, but not the portlet... confusing
[12:14:16 CDT(-0500)] <jhung> heidi_: at any rate I haven't touched any of the demos for a long time, so I don't know what changes have been made to them.
[12:14:48 CDT(-0500)] <heidi_> jhung cool thanks. it might be reset/focus issues. Justin_o have you looked at the layoutReorderer demo lately? i think focus might be weird with it
[12:16:47 CDT(-0500)] <Justin_o> heidi_: if it's the blue outline.. that's safari's default focus styling
[12:16:53 CDT(-0500)] <Justin_o> other than that.. i'm not sure
[12:17:01 CDT(-0500)] <heidi_> Justin_o try in firefox
[12:17:12 CDT(-0500)] <heidi_> i don't think the divs focused before - it's confusing in this demo
[12:17:41 CDT(-0500)] <Justin_o> heidi_: are you using FF4
[12:17:56 CDT(-0500)] <heidi_> Justin_o ya
[12:18:13 CDT(-0500)] <Justin_o> that's the FF4 bug where elements with overflow: auto; are focusable
[12:18:31 CDT(-0500)] <heidi_> ahh, ak
[12:18:41 CDT(-0500)] <Justin_o> yah.. it's annoying eh
[12:18:59 CDT(-0500)] <heidi_> Justin_o ya kinda feels like this demo is broken with it... bummer!
[12:25:31 CDT(-0500)] <Justin_o> yep.. colinclark mentioned it to david bolter already... but it was too late for them to get the fix into FF 4
[12:25:44 CDT(-0500)] <colinclark> It'll be in FF5
[12:25:59 CDT(-0500)] <colinclark> Bolter asked me if I knew any "big sites" that have this problem
[12:26:06 CDT(-0500)] <colinclark> 
[12:26:18 CDT(-0500)] <Justin_o> colinclark: oh we're too small ;(
[12:26:36 CDT(-0500)] <colinclark> Ah, well
[12:26:38 CDT(-0500)] <colinclark> It's been fixed
[12:26:41 CDT(-0500)] <colinclark> so we should still celebrate
[12:26:46 CDT(-0500)] <heidi_> that's good, funny they didn't catch that
[12:37:37 CDT(-0500)] <heidi_> Justin_o the entire list of images is focusable now, and can hit enter and it loads just an image... weird. thoughts? http://build.fluidproject.org/infusion/demos/reorderer/imageReorderer/html/imageReorderer.html
[12:38:03 CDT(-0500)] <heidi_> if you tab to the first img, then shift-tab back, it highlights the container
[12:38:09 CDT(-0500)] <heidi_> then hit enter
[12:38:57 CDT(-0500)] <heidi_> it's weird you can only shift-tab to focus it.. hmm
[12:43:34 CDT(-0500)] <Justin_o> heidi_: i think your second comment there is already filed
[12:43:47 CDT(-0500)] <heidi_> Justin_o cool, thanks
[12:44:04 CDT(-0500)] <Justin_o> heidi_: for your first one, are you saying the container is focusable and that hitting enter on it loads an image
[12:44:53 CDT(-0500)] <Justin_o> harriswong, mlam : just wondering how the testing is coming along?
[12:45:04 CDT(-0500)] <Justin_o> anastasiac: missed adding your name to the above ^
[12:45:16 CDT(-0500)] <harriswong> Justin_o: demo work fine, letting the swarm to run on itself
[12:45:19 CDT(-0500)] <heidi_> Justin_o when you focus the div and hit enter, it loads an image
[12:45:28 CDT(-0500)] <mlam> Justin_o: finished chrome for xp, working on ff3.6 and xp right now. also make a pull request for Bosmon to remove the uploader buttons in the demo
[12:45:39 CDT(-0500)] <Justin_o> heidi_: i'm not sure that's a problem
[12:45:45 CDT(-0500)] <anastasiac> Justin_o, I've finished testing FF3.6 and FF4 on Mac OSX - the only issue I found was that one I filed
[12:46:01 CDT(-0500)] <Justin_o> mlam: oh.. those aren't supposed to be there?
[12:46:07 CDT(-0500)] <Justin_o> anastasiac: thanks
[12:46:13 CDT(-0500)] <heidi_> Justin_o i think it is. it's unexpected, doesn't make sense, and brings you to a place with no way out
[12:46:28 CDT(-0500)] <mlam> They were before we had the integration tests. Now that we have the tests, it's necessary to have them
[12:46:46 CDT(-0500)] <Justin_o> heidi_: those are all live links to the image themselves.. if you click on it with the mouse that happens as well
[12:47:13 CDT(-0500)] <Justin_o> heidi_: so i guess what i'm saying is that it's expected.. but i think you can file a jira against the demo since it may not be desirable
[12:47:13 CDT(-0500)] <heidi_> Justin_o this is the page i get when i hit enter: http://build.fluidproject.org/infusion/components/reorderer/images/Dragonfruit.jpg
[12:47:14 CDT(-0500)] <harriswong> Justin_o: what would you like me to work on next
[12:47:20 CDT(-0500)] <michelled_> Justin_o: do you still need testing help?
[12:47:28 CDT(-0500)] <Justin_o> michelled_: i think we're okay
[12:47:37 CDT(-0500)] <heidi_> i don't think that's expected
[12:47:57 CDT(-0500)] <Justin_o> michelled_: jameswy has the last task
[12:48:18 CDT(-0500)] <Justin_o> heidi_: i mean.. that's how it was made.. it's the intended behaviour of the demo
[12:48:49 CDT(-0500)] <heidi_> Justin_o i think yr misunderstanding me. i'll file a jira
[12:49:14 CDT(-0500)] <heidi_> when the container is focused, and you hit enter, Dragonfruit.jpg is load in its own page
[12:49:40 CDT(-0500)] <Justin_o> heidi_: i could be
[12:49:48 CDT(-0500)] <Justin_o> best to file the jira i guess
[12:50:04 CDT(-0500)] <heidi_> Justin_o try it?
[12:51:06 CDT(-0500)] <Justin_o> heidi_: yep, just tried it.. i think it's behaving the way it always has.. in that regard, which is to open the image in a new page
[12:51:22 CDT(-0500)] <Justin_o> heidi_: but as you say, this may not be the best thing to happen
[12:51:33 CDT(-0500)] <heidi_> how does that make sense tho? as a user i would never expect that
[12:51:54 CDT(-0500)] <Justin_o> heidi_: i think it's legacy from a very old demo
[12:51:59 CDT(-0500)] <Justin_o> anastasiac: do you remember
[12:52:27 CDT(-0500)] <heidi_> Justin_o hitting enter on an image and getting the image makes okay sense, tho still weird, i mean hitting enter on the container div.
[12:53:00 CDT(-0500)] <Justin_o> heidi_: okay.. maybe i am misunderstanding you
[12:53:02 CDT(-0500)] <heidi_> tho i don't know why i user would want to load the image on its own, without being able to go back
[12:53:12 CDT(-0500)] <heidi_> not related to reordering...
[12:59:47 CDT(-0500)] <anastasiac> Justin_o, heidi_: iirc, being able to 'activate' the reorderable image thumbnails is how the interaction of image reorderer was originally designed. I'm not sure I recall why, but that was the original design. As to activating the first image when focus is on the containing div: I can't reproduce that...
[13:00:36 CDT(-0500)] <heidi_> anastasiac try tabbing to first item, then shift-tab to focus the container
[13:00:39 CDT(-0500)] <heidi_> and hit enter
[13:00:58 CDT(-0500)] <anastasiac> ah, gotcha. that "worked"
[13:01:03 CDT(-0500)] <anastasiac> and yes, seems odd
[13:02:51 CDT(-0500)] <heidi_> added FLUID-4246
[13:11:19 CDT(-0500)] <Justin_o> heidi_: thanks
[13:11:25 CDT(-0500)] <Justin_o> anastasiac: thanks for the explanation
[13:11:35 CDT(-0500)] <anastasiac> np
[13:43:05 CDT(-0500)] <Bosmon> Wow, Justin_o - you fixed it
[13:45:11 CDT(-0500)] <Justin_o> Bosmon:
[13:45:29 CDT(-0500)] <Justin_o> i didn't push that up to the main repo though.. not sure if people want me to or not
[13:45:40 CDT(-0500)] <Bosmon> So, I guess I don't understand how a merge can give rise to a FF commit, when it actually has to do a merge
[13:45:51 CDT(-0500)] <Bosmon> Surely the whole point of a merge is that it is NOT an FF
[13:45:54 CDT(-0500)] <harriswong> Justin_o: should this be resolved? http://issues.fluidproject.org/browse/FLUID-4113
[13:46:14 CDT(-0500)] <Justin_o> harriswong: i think so..
[13:46:40 CDT(-0500)] <Justin_o> Bosmon: yes.. i'm not so sure what happened here.. i would have thought that this would have had to have a merge commit
[13:47:05 CDT(-0500)] <Bosmon> Certainly your graph looks a LOT cleaner than master
[13:47:27 CDT(-0500)] <Bosmon> I would be happy if you pushed it - but are you sure that won't just cause it to flip again?
[13:48:06 CDT(-0500)] <Justin_o> Bosmon: well.. there's one way to be sure i could delete the master from the project repo
[13:48:11 CDT(-0500)] <Justin_o> actually i might have to do this
[13:57:13 CDT(-0500)] <Justin_o> Bosmon: can you take a look at the issues on this filter
[13:57:14 CDT(-0500)] <Justin_o> http://issues.fluidproject.org/secure/IssueNavigator.jspa?mode=hide&requestId=10128
[13:57:32 CDT(-0500)] <Justin_o> do you know if any can be closed
[13:57:36 CDT(-0500)] <Justin_o> or pushed to another release
[13:59:59 CDT(-0500)] <Bosmon> I guess 3675, 958, 3681 can be closed
[14:00:06 CDT(-0500)] <Bosmon> Isn't 958 resolved already?
[14:00:11 CDT(-0500)] <Bosmon> 3674 will need to be pushed out
[14:00:17 CDT(-0500)] <Bosmon> And 3716 will be with us until the END OF TIME
[14:00:28 CDT(-0500)] <Bosmon> 3725 and 3728 I don't know about
[14:01:21 CDT(-0500)] <Bosmon> 3681 I guess we should fork into a separate issue about ANTIGENS
[14:02:24 CDT(-0500)] <Bosmon> Although I quite like the number and am used to it
[14:12:43 CDT(-0500)] <Justin_o> Bosmon: the title for 3681 sounds quite different though...
[14:14:24 CDT(-0500)] <Justin_o> Bosmon: would you be able to update those as needed.. anastasiac could you please close off FLUID-3716 when it's good enough for 1.4. then we'll create new ones afterwards
[14:15:47 CDT(-0500)] <Bosmon> Yes... shouldn't someone else actually "close" them?
[14:17:23 CDT(-0500)] <colinclark> that is a very strange use of airquotes, Bosmon
[14:17:28 CDT(-0500)] <colinclark> "close" them
[14:17:33 CDT(-0500)] <Bosmon> gah
[14:17:44 CDT(-0500)] <colinclark>
[14:18:17 CDT(-0500)] <Justin_o> Bosmon: i don't mind you closing them since you were the reporter too.. but if anyone else can verify there doneness they could close it
[14:21:48 CDT(-0500)] <anastasiac> Justin_o: I'll garden FLUID-3716, though I'll warn you that it probably won't be closed till much closer to release. There's lots still to cover.
[14:22:42 CDT(-0500)] <Justin_o> anastasiac: yep no problem.. maybe we could rename it or something so that it is clear that it is only for this release.. or we could just remember to close it.. whatever you think is best
[14:24:10 CDT(-0500)] <anastasiac> Justin_o: renamed
[14:24:19 CDT(-0500)] <Justin_o> anastasiac: thanks
[14:40:18 CDT(-0500)] <Justin_o> michelled_, Bosmon, colinclark, did you want to chat about ui options for a bit
[14:41:26 CDT(-0500)] <colinclark> sure
[14:41:27 CDT(-0500)] <michelled_> yep
[14:42:36 CDT(-0500)] <Justin_o> so i had just been asking about how the new structure all works out.. at the moment I'm a bit unsure about how ui options and ui enhancer were proposed to work...
[14:43:04 CDT(-0500)] <Justin_o> i guess the part i'm currently stuck on is that for ui options there will be renderer components and for ui enhancer these will be ignored
[14:44:01 CDT(-0500)] <Bosmon> Hi Justin
[14:44:16 CDT(-0500)] <michelled_> that's a good point Justin_o - it does feel strange to have a renderer component that we sometimes want to render and sometimes don't want to render
[14:44:28 CDT(-0500)] <Bosmon> It is just an "aggregation issue"
[14:44:45 CDT(-0500)] <Bosmon> We could reassort the tree if we wanted to... but it seems like a lot of trouble
[14:44:53 CDT(-0500)] <Bosmon> It's a shame you weren't on the call on Friday
[14:45:22 CDT(-0500)] <Bosmon> I was trying to explain that IoC points towards a slightly different way of thinking about component aggregation and its "costs"
[14:45:28 CDT(-0500)] <Justin_o> Bosmon: sorry.. yes it probably would be clearer to me now
[14:45:53 CDT(-0500)] <Bosmon> In the old OO world, putting two things with common fates but unrelated functions "together" was costly
[14:46:02 CDT(-0500)] <Bosmon> Since they had to have mutual knowledge of each other
[14:46:37 CDT(-0500)] <Bosmon> Whereas with IoC, siblings, and even parents/children, need know virtually nothing about each other
[14:46:56 CDT(-0500)] <Bosmon> The real implication of this refactoring is that "the thing called UIEnhancer" will basically cease to exist in any case
[14:47:10 CDT(-0500)] <Bosmon> Both UIOptions and UIEnhancer will just become light "shells" for some, fairly arbitrary, tree of subcomponents
[14:47:23 CDT(-0500)] <Bosmon> So the idea of "putting" one, or other of them on a page, or not, will cease to have very much specific meaning
[14:48:40 CDT(-0500)] <Bosmon> If we cared, we could "transform" the tree so that the "old enhancer-specific" and "old uioptions-specific" subcomponents "went away" in the other contexts
[14:48:45 CDT(-0500)] <Bosmon> But it really doesn't matter so much
[14:49:02 CDT(-0500)] <Bosmon> We care much more about the experience of the person extending UIOptions/UIEnhancer to add or configure a new option
[14:49:20 CDT(-0500)] <Bosmon> That person should have a "one stop shop" for their changes
[14:49:30 CDT(-0500)] <michelled_> Bosmon: would the shell of UIEnhancer remove the renderer subcomponents from the tree?
[14:49:48 CDT(-0500)] <Bosmon> michelled_ it could - but I don't see it needs to
[14:49:59 CDT(-0500)] <Bosmon> Why is it worried that there are "extra" components in the tree that are not relevant to it?
[14:50:01 CDT(-0500)] <michelled_> what happens to an auto init renderer component?
[14:50:05 CDT(-0500)] <Bosmon> In fact, that is ALWAYS the case
[14:50:38 CDT(-0500)] <Bosmon> Well ok, we could write a demands block to make these components "go away"....
[14:50:52 CDT(-0500)] <Bosmon> In the context of the Enhancer, the options-specific ones could resolve to null or the emptySubcomponent
[14:51:12 CDT(-0500)] <Bosmon> but the auto init renderer components don't cost much apart from a bit of CPU time
[14:51:47 CDT(-0500)] <michelled_> meaning in the context of the UI Enhancer they wouldn't actually attempt to render?
[14:51:55 CDT(-0500)] <Bosmon> Well, they never should
[14:52:05 CDT(-0500)] <Bosmon> Remember, it is always the UIOptions shell that is responsible for their workflow anyway
[14:52:25 CDT(-0500)] <Bosmon> They never actually render by themselves, they are to expose a "produceTree" method which UIOptions prods at the appropriate time
[14:53:01 CDT(-0500)] <michelled_> yes in the short term. I thought that in the longer term we were expecting them to render themselves
[14:53:14 CDT(-0500)] <Bosmon> Yes, by then
[14:53:22 CDT(-0500)] <Bosmon> But in general no renderer component renders itself on init anyway
[14:53:31 CDT(-0500)] <Bosmon> I think we met this in UIOptions before you went away
[14:53:38 CDT(-0500)] <Bosmon> There always needs to be an explicit call to "refreshView"
[14:53:47 CDT(-0500)] <Bosmon> Although I think we will add a "renderOnInit" option soon
[14:53:47 CDT(-0500)] <michelled_> yes
[14:53:52 CDT(-0500)] <Justin_o> Bosmon: i'm kind of wondering now why there are two components, UI Options and UI Enhancer
[14:54:23 CDT(-0500)] <Justin_o> Bosmon: if they are as similar as they are sounding.. why aren't they the same component with slightlly different configuration?
[14:54:32 CDT(-0500)] <Bosmon> Because we haven't done the work yet?
[14:54:45 CDT(-0500)] <Justin_o>
[14:56:13 CDT(-0500)] <Justin_o> Bosmon: i guess if we are doing all of these changes.. wouldn't it be just as easy to make it into one component?
[14:56:35 CDT(-0500)] <Bosmon> Well, again ultimately it doesn't really matter
[14:56:49 CDT(-0500)] <Bosmon> To IoC "the same component" or "the different component" is just a matter of the name
[14:57:21 CDT(-0500)] <michelled_> Bosmon: if you were writing it from scratch today, would there be two components?
[14:57:32 CDT(-0500)] <Bosmon> It is a wacky new world
[14:57:42 CDT(-0500)] <Bosmon> Well... what are "two components"?
[14:58:07 CDT(-0500)] <Justin_o> Bosmon: i suppose this also changes the current idiom where a page might have both a UI Enhancer and UI Option component on them
[14:58:11 CDT(-0500)] <Bosmon> The difference between these two components will probably just be the name on a type tag, and the particular function supplied to finalInit
[14:58:47 CDT(-0500)] <Bosmon> Justin_o - that one is an interesting case
[14:58:59 CDT(-0500)] <Bosmon> I guess we could actually share the whole subtree in that case...
[15:00:10 CDT(-0500)] <Justin_o> Bosmon: what do you mean by subtree?
[15:00:23 CDT(-0500)] <Bosmon> All of the components
[15:00:51 CDT(-0500)] <Bosmon> So I guess the type tags we would create, relate to the ABSENCE of the parts we don't need, rather than the presence of the ones we do
[15:00:59 CDT(-0500)] <Justin_o> Bosmon: just so i'm clear, because i think i'm a bit confused still what are the rules of UI Options and UI Enhancer supposed to be
[15:01:17 CDT(-0500)] <Bosmon> That is, if we wanted to make the dialog rendering parts "go away" we would specifically contextualise that
[15:01:22 CDT(-0500)] <Justin_o> should be roles, not rules
[15:01:30 CDT(-0500)] <Bosmon> Whereas it sounds like there are cases where we would want BOTH flavours of components to be present
[15:03:09 CDT(-0500)] <michelled_> any time we have the ability to set options we require the thing that does the transformation. whether it's in the preview or on the whole page
[15:03:46 CDT(-0500)] <michelled_> but there and many time when all we want to do is the transformation based on settings that were set at some earlier point
[15:04:20 CDT(-0500)] <Bosmon> Yes, sure
[15:04:34 CDT(-0500)] <Bosmon> So in that case we would make the "unwanted components" go away through means of demands blocks
[15:05:02 CDT(-0500)] <Justin_o> Bosmon, michelled_ : do both ui options and ui enhancer have unwanted components?
[15:05:26 CDT(-0500)] <Bosmon> Justin_o - I think we agreed that "ui options" and "ui enhancer" will not exist any more?
[15:05:49 CDT(-0500)] <Justin_o> Bosmon: so we have the one component?
[15:05:54 CDT(-0500)] <Justin_o> okay
[15:06:19 CDT(-0500)] <Bosmon> Although I think we were planning to refactor "ui enhancer" vertically
[15:06:29 CDT(-0500)] <Bosmon> In order to split off the piece of itself that is responsible for fiddling with frames, etc.
[15:06:36 CDT(-0500)] <Bosmon> Into something like a "UIEnhancerInjector"
[15:06:52 CDT(-0500)] <Bosmon> So that the thing called "UIEnhancer" can become just a standard view component
[15:06:53 CDT(-0500)] <Justin_o> Bosmon: is that in enhancer too or just in the ui options preview component?
[15:08:05 CDT(-0500)] <Justin_o> Bosmon: okay so the "UI Options" state of the component will have both the ui and the change mechanism, and the "UI Enhancer" state will just have the change mechanism
[15:08:09 CDT(-0500)] <Justin_o> is that correct?
[15:09:10 CDT(-0500)] <Bosmon> Justin_o - that sounds about right
[15:09:35 CDT(-0500)] <Bosmon> Although we could choose to deal with the "UI Options" state by just instantiating the component twice
[15:09:45 CDT(-0500)] <Bosmon> One with "ui only" and the other with "change only"
[15:10:02 CDT(-0500)] <Bosmon> And then transmitting the model from one instance to the other
[15:10:59 CDT(-0500)] <Justin_o> Bosmon: this second option has me wondering why they aren't two completely distinct components
[15:11:26 CDT(-0500)] <Bosmon> Well again, it just doesn't really matter whether we say they are distinct, or the same
[15:11:30 CDT(-0500)] <Bosmon> It is just a matter of configuration
[15:11:57 CDT(-0500)] <Justin_o> Bosmon: i think i know what you are getting at, since in the new world a component is really just a set of configuration..
[15:12:12 CDT(-0500)] <Bosmon> ALL of the stuff which says what these "components" will actually do in practice, appears in the "options" structure defining its subcomponents
[15:13:14 CDT(-0500)] <Justin_o> Bosmon: i guess what i'm worried about is that we could say that uploader and ui options are the same, they just have different configuration
[15:13:20 CDT(-0500)] <Bosmon> hahaha
[15:13:30 CDT(-0500)] <Bosmon> Well, in practice, we might
[15:13:35 CDT(-0500)] <Justin_o>
[15:13:39 CDT(-0500)] <Bosmon> What is not the same is the "type tag name"
[15:13:47 CDT(-0500)] <Bosmon> Which is used to guide resolution of demands blocks
[15:14:04 CDT(-0500)] <Bosmon> Whether that actually is the component's name, or just appears nearby it, is just a design choice
[15:14:53 CDT(-0500)] <Justin_o> Bosmon: I guess i like to think of our component as being something that has a specific default configuration... and these seem to be different..
[15:14:58 CDT(-0500)] <Bosmon> Yes
[15:15:15 CDT(-0500)] <Bosmon> Well, the real difference between them will be in their finalInit function
[15:15:41 CDT(-0500)] <Bosmon> It might clean things up if we just created an extra layer of indirection...
[15:15:57 CDT(-0500)] <Justin_o> Bosmon: what might that look like?
[15:16:08 CDT(-0500)] <Bosmon> That is, to write "UIOptions" and "UIEnhancer" as far as possible as distinct components, both of which have a single, commonly-configured subcomponent as their only child
[15:16:14 CDT(-0500)] <Bosmon> And all of the "variable material" goes into this subcomponent
[15:16:43 CDT(-0500)] <Bosmon> As far as resolving demands blocks goes, children of this subcomponent don't care how many levels deep they are away from the parent holding the context names
[15:17:00 CDT(-0500)] <Justin_o> Bosmon: "variable material" being the user settings?
[15:17:03 CDT(-0500)] <Bosmon> Yes
[15:17:11 CDT(-0500)] <Justin_o> Bosmon: i think i like that
[15:17:20 CDT(-0500)] <Justin_o> michelled_, colinclark what do you think?
[15:17:59 CDT(-0500)] <colinclark> So, it clear that despite Bosmon's relativism that there are still two lines of configuration
[15:18:18 CDT(-0500)] <colinclark> interestingly, it seems to me that the UI Options side of the equation is actually the whole configuration
[15:18:32 CDT(-0500)] <colinclark> In that UI Options, to do its thing, currently collaborates with a UI Enhancer
[15:18:59 CDT(-0500)] <colinclark> In cases where there isn't an "preferences editing dialog" on the page, then we're interested in one branch of the configuration
[15:19:09 CDT(-0500)] <colinclark> the parts of it that do stuff to the page
[15:19:39 CDT(-0500)] <colinclark> So I'm not sure Bosmon's design is really too much of a challenge to your desire to have an "identity" for components, Justin_o
[15:20:10 CDT(-0500)] <colinclark> Presumably we've just got a set of demands blocks that will resolve in the case of "just the parts that do stuff" vs. the whole deal
[15:20:35 CDT(-0500)] <colinclark> I guess if you look at cindyli's refactoring of UI Options, increasingly it is, as a component, losing its responsibility
[15:20:52 CDT(-0500)] <Justin_o> colinclark: i'm okay with that if we think of ui options as a the whole and when in ui enhancer mode, it's a subset
[15:20:55 CDT(-0500)] <colinclark> as more children are factored out to take over responsibility for discrete pieces of UI Options' former behaviour
[15:21:22 CDT(-0500)] <colinclark> Similarly, we've already been planning that UI Enhancer was too caught up in multiple responsibilities
[15:21:49 CDT(-0500)] <colinclark> So I guess the heart of Bosmon's design is the ability for implementers to extend the system in a way that "makes sense"
[15:21:54 CDT(-0500)] <colinclark> It's a bit like CollectionSpace or Engage
[15:22:03 CDT(-0500)] <colinclark> You can imagine a user approaching the system saying
[15:22:09 CDT(-0500)] <colinclark> "I'd like to add a new preference here"
[15:22:19 CDT(-0500)] <colinclark> The example I used during our conversation, Justin_o, was a new preference to turn off all images
[15:22:41 CDT(-0500)] <colinclark> So, let's say I want to do that
[15:22:59 CDT(-0500)] <colinclark> I'd like to just do two things:
[15:23:24 CDT(-0500)] <colinclark> okay, make it three?
[15:23:34 CDT(-0500)] <colinclark> 1. Edit the markup to add a new preference to the template
[15:23:48 CDT(-0500)] <colinclark> 2. Say "I'd like this preference to be a boolean, like these other preferences that are already in UI Options."
[15:24:18 CDT(-0500)] <colinclark> 3. Supply a bit of code that actually acts on the preference in some way--say by $.remove()ing all <img> tags on the page
[15:24:36 CDT(-0500)] <colinclark> Bosmon and michelled_'s design let's me basically deal with the unit of "a preference"
[15:25:13 CDT(-0500)] <colinclark> and then demands blocks or transformation is used to appropriately contextualize what these preferences mean
[15:25:23 CDT(-0500)] <colinclark> Am I making sense, at all?
[15:25:26 CDT(-0500)] <colinclark> Or have I just made it worse?
[15:25:28 CDT(-0500)] <colinclark>
[15:27:11 CDT(-0500)] <colinclark> btw, I think it would be a good tutorial for UI Options to teach people how to create this "no images" option
[15:27:21 CDT(-0500)] <colinclark> It's real-world yet fairly straightforward
[15:27:34 CDT(-0500)] <anastasiac> noted
[15:27:36 CDT(-0500)] <colinclark> to implement
[15:27:38 CDT(-0500)] <colinclark>
[15:29:44 CDT(-0500)] <Justin_o> colinclark: so i think i'm alright with think of this as one component.. where the "UI Options" version does everything, and the "UI Enhancer" version does everthing except have a ui. I guess i find it funny to think of if it is one component that has to be on the page twice and contains half of the options in each case
[15:30:13 CDT(-0500)] <colinclark> Well, in a way, isn't that what we currently have?
[15:30:17 CDT(-0500)] <colinclark> The latter case?
[15:30:43 CDT(-0500)] <Justin_o> colinclark: i think the current case is ui enhancer always does the changes on the page
[15:30:43 CDT(-0500)] <colinclark> Two components that have the same set of "options," but doing different things with them?
[15:31:11 CDT(-0500)] <colinclark> I guess the point in this design is that it's the little Ants that do changes on the page now
[15:31:22 CDT(-0500)] <Justin_o> colinclark: ants do work hard
[15:31:27 CDT(-0500)] <colinclark> exactly!
[15:31:38 CDT(-0500)] <colinclark> Where I say "Ants" I mean busy little components that are concerned with a particular job
[15:31:46 CDT(-0500)] <Bosmon> Yes
[15:31:52 CDT(-0500)] <Bosmon> We support ANTS rather than ANTHEAPS
[15:31:56 CDT(-0500)] <colinclark> lol
[15:32:00 CDT(-0500)] <Bosmon> Under the "ANT HILLARY" model
[15:32:14 CDT(-0500)] <colinclark> So UI Enhancer then just boils down to a name that aggregates together a set of Ants
[15:32:32 CDT(-0500)] <colinclark> Similarly, UI Options is just a name that aggregates an ever larger set of coordinated Ants
[15:32:42 CDT(-0500)] <colinclark> all of which are paired up into teams on a per-option basis
[15:33:00 CDT(-0500)] <Justin_o> colinclark: but then we shouldn't need to have both ui enhancer and ui options on the same page
[15:33:01 CDT(-0500)] <colinclark> Except that only IoC knows that they are paired up
[15:33:39 CDT(-0500)] <colinclark> Justin_o: In the case where "UI Options" is the name that encompasses both "the dialog on the page" and "the Ants that change the Page"
[15:33:40 CDT(-0500)] <colinclark> or rather
[15:33:54 CDT(-0500)] <Justin_o> colinclark: yes
[15:33:55 CDT(-0500)] <colinclark> "The Ants that draw the dialog" and "the Ants that change the Page"
[15:34:09 CDT(-0500)] <colinclark> The thing about Ants
[15:34:12 CDT(-0500)] <colinclark> along with IoC
[15:34:19 CDT(-0500)] <colinclark> is that we can make all kinds of new compositions of Ants
[15:34:35 CDT(-0500)] <colinclark> simply by giving them names and a set of demands blocks
[15:34:50 CDT(-0500)] <colinclark> Bosmon: Is that what you were getting at/
[15:34:52 CDT(-0500)] <colinclark> ?
[15:34:57 CDT(-0500)] <Bosmon> colinclark - yes
[15:35:15 CDT(-0500)] <Bosmon> We can even say, "black ants are not needed today"
[15:35:19 CDT(-0500)] <Justin_o> colinclark: yes.. i get that, but i think that pushes us to a point where we never have a component
[15:35:38 CDT(-0500)] <Bosmon> Justin_o - we already "never have a component"
[15:35:47 CDT(-0500)] <Bosmon> Given we can write an autoInit renderer component without any code
[15:35:58 CDT(-0500)] <Justin_o> Bosmon: not in the code sense.. right, but in the defined set of defaults i guess
[15:36:09 CDT(-0500)] <Bosmon> Yes - well, all defaults match is a NAME
[15:36:32 CDT(-0500)] <Bosmon> But the subcomponents attached to "a particular component" are just part of its configuration
[15:36:48 CDT(-0500)] <Bosmon> And there's no reason why you can't take the subcomponents which were configured "for one component" and attach them "to another"
[15:36:50 CDT(-0500)] <Justin_o> Bosmon: i guess i'm arguing for definition of a set of defaults
[15:37:12 CDT(-0500)] <Bosmon> Yes, and this is perhaps why the "common subcomponent" idea makes sense
[15:37:34 CDT(-0500)] <Justin_o> Bosmon: i think i'm fine with that
[15:37:34 CDT(-0500)] <Bosmon> Given it is THAT component's defaults which define "what a default set of UI Options elements" are
[15:37:54 CDT(-0500)] <Bosmon> It was always pretty peculiar the way we just arbitrarily decided that all of THOSE defaults would be on the "UI Enhancer" side
[15:38:02 CDT(-0500)] <Bosmon> In our current design
[15:39:53 CDT(-0500)] <Justin_o> Bosmon: so i guess this is winding down.. not sure... maybe we should also talk about what to do with the network graph
[15:40:01 CDT(-0500)] <Justin_o> colinclark, michelled_ ^
[15:41:23 CDT(-0500)] <colinclark>
[15:41:33 CDT(-0500)] <colinclark> Justin_o: So, can you summarize for us what you're fine with?
[15:41:47 CDT(-0500)] <colinclark> In other words, what does the architecture look like in this common subcomponent case?
[15:42:21 CDT(-0500)] <colinclark> And then, yes, I can tune out while you Git Connoisseurs talk about the network graph
[15:43:19 CDT(-0500)] <colinclark> Not that I will tune out
[15:43:23 CDT(-0500)] <colinclark> I'll just cheer from the sidelines
[15:46:48 CDT(-0500)] <Justin_o> colinclark: i think it's what bosmon said earlier "That is, to write "UIOptions" and "UIEnhancer" as far as possible as distinct components, both of which have a single, commonly-configured subcomponent as their only child"
[15:47:40 CDT(-0500)] <colinclark> What would the commonly-configured subcomponent contain?
[15:47:51 CDT(-0500)] <Bosmon> It would contain "all the ants"
[15:47:56 CDT(-0500)] <Bosmon> UIOptions.antBox
[15:48:07 CDT(-0500)] <colinclark> UIOptions.antFarm
[15:48:22 CDT(-0500)] <colinclark> Justin_o: So why does this make you feel better?
[15:50:02 CDT(-0500)] <Justin_o> colinclark: because i like to think of a component as a collection of defaults
[15:51:10 CDT(-0500)] <Bosmon> Justin_o: But, the fact that "antBox" has any defaults is purely incidental?
[15:51:17 CDT(-0500)] <Bosmon> It might not actually have any
[15:51:27 CDT(-0500)] <Bosmon> It could be a "completely empty component" and still do its work
[15:53:03 CDT(-0500)] <Justin_o> Bosmon: could an empty component do much work
[15:53:20 CDT(-0500)] <Bosmon> It could, if it was given the right options
[15:53:25 CDT(-0500)] <Bosmon> It could do any work conceivable
[15:53:45 CDT(-0500)] <Bosmon> Ultimately we will "not have components" any more.... there really will be just a universal component called "fluid.component"
[15:53:53 CDT(-0500)] <Justin_o> Bosmon: sorry.. i thought you meant that empty fluid component thing
[15:54:01 CDT(-0500)] <Bosmon> Whose job is simply to accept IoC configuration and execute it
[15:54:36 CDT(-0500)] <Justin_o> Bosmon: that's sort of the future i'm afraid of
[15:54:49 CDT(-0500)] <Bosmon> hahaha
[15:55:08 CDT(-0500)] <Bosmon> I guess we should all set down and have a showing of Terry Gilliam's "Brazil"....
[15:55:23 CDT(-0500)] <Bosmon> This is the future that we will have when all of our code is in the hands of our users
[15:55:33 CDT(-0500)] <Bosmon> Stored as a JSON document in a CouchDB or something similar
[15:55:52 CDT(-0500)] <Bosmon> All that an "application" will do is fetch this document, and pass it as an argument to "fluid.component"
[15:57:41 CDT(-0500)] <Justin_o> Bosmon: Robert De Niro is in that movie
[15:57:53 CDT(-0500)] <Justin_o> we should watch that on our screen array when you come in July
[15:58:22 CDT(-0500)] <Bosmon> Sure, amongst various other Prescribed Films
[15:58:26 CDT(-0500)] <colinclark> lol
[15:58:30 CDT(-0500)] <colinclark> eek
[15:58:36 CDT(-0500)] <Bosmon> For me it is famous because it contains Jonathan Pryce
[15:58:45 CDT(-0500)] <Bosmon> I always love to see anything he is in...
[15:58:59 CDT(-0500)] <colinclark> Maybe my next art video will be a single take of Bosmon watching Bullshot
[15:59:03 CDT(-0500)] <colinclark> that would be really great
[15:59:05 CDT(-0500)] <Bosmon> hahahaha
[15:59:09 CDT(-0500)] <Justin_o> Bosmon: did you watch this one http://www.imdb.com/title/tt1046173/
[15:59:10 CDT(-0500)] <Bosmon> SQUAWKING
[15:59:24 CDT(-0500)] <colinclark> That and my version of Andy Warhol's Sleep, but starring a cat instead
[15:59:30 CDT(-0500)] <Bosmon> I never saw that one
[15:59:43 CDT(-0500)] <Bosmon> Wow, he plays the "President"...
[15:59:48 CDT(-0500)] <colinclark> Given a cat's sleeping tendencies, it would also be twice as long as Warhol's
[16:00:02 CDT(-0500)] <Bosmon> What a bizarre-looking film
[16:00:37 CDT(-0500)] <heidi_> jameswy when talking about a sliding panel, does "panel" include the button or is panel only the slidey bit that's hidden/shown. coming up with terms for things...
[16:01:09 CDT(-0500)] <jameswy> heidi_: The latter
[16:01:18 CDT(-0500)] <heidi_> jameswy thanks
[16:01:23 CDT(-0500)] <jameswy> np
[16:01:24 CDT(-0500)] <colinclark> Wait, we're watching GI Joe?
[16:01:33 CDT(-0500)] <Justin_o> Bosmon: it was based on toys or a cartoon, caon't remember the order
[16:01:43 CDT(-0500)] <colinclark> Dr. Basman prescribes Brazil, and the King decrees G.I. Joe
[16:03:09 CDT(-0500)] <Justin_o> colinclark: i'd actually prefer transformers... the cartoons
[16:03:17 CDT(-0500)] <colinclark> Cool
[16:03:19 CDT(-0500)] <colinclark> I'd watch those
[16:03:29 CDT(-0500)] <Justin_o> i have the complete series i think
[16:03:37 CDT(-0500)] <Justin_o> haven't had chance to watch it yet though
[16:34:18 CDT(-0500)] <Justin_o> fluid-everyone: I'm going to try to fix the network graph tomorrow, so please hold off on any commits till then
[16:53:01 CDT(-0500)] <colinclark> Hey Bosmon
[16:53:07 CDT(-0500)] <colinclark> I'm trying to do something fairly bizarre
[16:53:22 CDT(-0500)] <colinclark> I have a component that has an Uploader as a subcomponent
[16:53:34 CDT(-0500)] <colinclark> It it has another subcomponent
[16:53:47 CDT(-0500)] <colinclark> which presents a UI for users to customize the options of the Uploader
[16:54:11 CDT(-0500)] <colinclark> and then the parent needs to zap the Uploader and reinstantiate it with the new options
[16:54:28 CDT(-0500)] <Bosmon> Yes
[16:54:34 CDT(-0500)] <Bosmon> FOr this, you can use "fluid.clearComponent"
[16:54:39 CDT(-0500)] <colinclark> oh
[16:54:42 CDT(-0500)] <colinclark> interesting
[16:54:47 CDT(-0500)] <colinclark> I didn't know about it
[16:55:06 CDT(-0500)] <Bosmon> It is far from bizarre, JURA is doing this kind of thing all the time
[16:55:23 CDT(-0500)] <Bosmon> OR, if you just register the thing as "createOnEvent", when you fire the event a 2nd time, it will be auto-zapped and recreated
[16:55:25 CDT(-0500)] <colinclark> forgive me
[16:55:36 CDT(-0500)] <colinclark> those of us who still live in caves find it quite bizarre
[16:55:47 CDT(-0500)] <colinclark> oh, yes, crazy
[16:55:54 CDT(-0500)] <colinclark> My Uploader is already registered as createOnEvent
[16:56:02 CDT(-0500)] <colinclark> fantastic
[16:56:03 CDT(-0500)] <Bosmon> ah cool
[16:56:04 CDT(-0500)] <colinclark> I can really do that?
[16:56:09 CDT(-0500)] <Bosmon> yes
[16:56:14 CDT(-0500)] <colinclark> no way
[16:56:19 CDT(-0500)] <Bosmon> way
[16:57:02 CDT(-0500)] <colinclark>
[16:57:09 CDT(-0500)] <colinclark> hurray for Yura
[16:58:13 CDT(-0500)] <colinclark> and you
[17:22:13 CDT(-0500)] <colinclark> Bosmon: this really has to be my best framework experience so far
[17:22:25 CDT(-0500)] <Bosmon> I'm glad
[17:23:57 CDT(-0500)] <colinclark> Everything I wanted to do was possible
[17:24:11 CDT(-0500)] <colinclark> and the framework actually simplified what was otherwise a bit tangled
[17:24:47 CDT(-0500)] <Bosmon> Hopefully we can make such experiences more frequent over time
[17:25:24 CDT(-0500)] <colinclark> Documentation will help
[17:25:52 CDT(-0500)] <colinclark> This, I think, is my first real set of autoInit components
[17:26:11 CDT(-0500)] <colinclark> Although I haven't taken Yura's "all invokers" approach so it really doesn't look terribly different
[17:26:26 CDT(-0500)] <colinclark> beyond the fact that it's no longer my problem to obtain a "that"
[17:34:01 CDT(-0500)] <colinclark> Bosmon: Another quick question?
[17:34:09 CDT(-0500)] <Bosmon> sure
[17:34:24 CDT(-0500)] <colinclark> I wanted to do something with an invoker that wasn't possible back in the dark ages
[17:34:31 CDT(-0500)] <colinclark> i.e. before 1.3
[17:34:34 CDT(-0500)] <colinclark> I have an invoker
[17:34:43 CDT(-0500)] <colinclark> Two of its arguments can be resolved up front
[17:35:02 CDT(-0500)] <colinclark> the third has to be computed, meaning it has to be passed in when it's actually invoked
[17:35:30 CDT(-0500)] <colinclark> Is that possible now?
[17:36:04 CDT(-0500)] <Bosmon> Was there really a time that wasn't possible?
[17:36:22 CDT(-0500)]
[17:36:49 CDT(-0500)] <colinclark> ok, great
[17:37:04 CDT(-0500)] <colinclark> I'm fairly certain it wasn't possible when I first started using invokers in the Uploader
[17:37:11 CDT(-0500)] <colinclark> but to be fair that was very early on in the life of IoC
[18:14:46 CDT(-0500)] <colinclark> I probably actually went a little overboard with my components
[18:15:02 CDT(-0500)] <colinclark> but I wanted to create at least one that represented each major area of the UI
[18:15:19 CDT(-0500)] <colinclark> here, you can have a look:
[18:15:58 CDT(-0500)] <colinclark> https://github.com/colinbdclark/image-gallery/blob/master/js/uploader.js
[18:17:49 CDT(-0500)] <colinclark> Any code review suggestions?
[18:18:00 CDT(-0500)] <colinclark> Aside from the few TODOs in the comments
Unknown macro: { mimeType}
Unknown macro: {arguments}
Manage space
Manage content
Integrations