fluid-work IRC Logs-2012-01-31

[08:53:44 CST(-0600)] <Justin_o> cindyli: hello.. I'm looking into some server side file type validation for Decapod. I'm trying to figure out how to best implement it. I'm wondering if you could tell me how you've done it in PHP?

[08:54:21 CST(-0600)] <cindyli> Justin_o: sure, what kind of validation do you need?

[08:54:27 CST(-0600)] <cindyli> file type

[08:54:34 CST(-0600)] <cindyli> by checking file extensions?

[08:54:59 CST(-0600)] <Justin_o> cindyli: yes file type..

[08:55:32 CST(-0600)] <Justin_o> is it typical to just check file extension.. i suppose you can't do more than that unless you actually put it on the server first

[08:56:03 CST(-0600)] <cindyli> Justin_o: yes

[08:58:50 CST(-0600)] <cindyli> Justin_o: PHP has a filetype() function which returns the file types in the way whether it's a dir or a file or a link etc

[08:58:52 CST(-0600)] <cindyli> http://php.net/manual/en/function.filetype.php

[09:00:34 CST(-0600)] <Justin_o> cindyli: thanks. so you would typically let a file upload to the server, test it, then send the appropriate response back?

[09:00:35 CST(-0600)] <cindyli> may not be the kind of the "file type validation" that you want

[09:00:45 CST(-0600)] <cindyli> yes, Justin_o

[09:01:03 CST(-0600)] <Justin_o> cindyli: so i guess what i'd want is for the uploader to only accept certain types of images and nothing else

[09:02:37 CST(-0600)] <cindyli> Justin_o: first, the file needs to be uploaded and reach the server anyway before any validation starts

[09:03:39 CST(-0600)] <cindyli> to check the image type: 1. file extension; 2. use getImageSize() sort of image-specific function to furthur ensure

[09:04:19 CST(-0600)] <Justin_o> cindyli: ah okay, great thanks

[09:04:26 CST(-0600)] <cindyli> np, Justin_o

[09:24:12 CST(-0600)] <colinclark> hey Justin_o, I was thinking...

[09:24:36 CST(-0600)] <colinclark> There's no reason you can't do quite sophisticated file validation on the client-side nowadays, if you wanted

[09:25:03 CST(-0600)] <colinclark> You may well still want equivalent checks on the server side, too

[09:25:32 CST(-0600)] <colinclark> but if you want to give the user immediate feedback, rather than having the push up the file to the server and wait for a response back, you can get some metadata about the file on the client side

[09:25:40 CST(-0600)] <colinclark> or even access the file's data directly if needed

[09:31:26 CST(-0600)] <Justin_o> colinclark: cool.. i'd guess we would want both just to be safe, especially since the server could be used directly without the Decapod client.. but it would be great to have that there as well

[09:32:01 CST(-0600)] <colinclark> I guess validating on file extension probably isn't the sort of validation you'd do for security reasons

[09:32:07 CST(-0600)] <colinclark> just to help the user, mostly

[09:32:17 CST(-0600)] <colinclark> since, of course, people can make up extensions

[09:32:47 CST(-0600)] <Justin_o> colinclark: i'm planning on using this http://docs.python.org/library/imghdr.html

[09:33:16 CST(-0600)] <Justin_o> so it will look into the file and see what image type it really is

[09:33:32 CST(-0600)] <Justin_o> i think it will return None if it isn't a file type it supports

[09:33:53 CST(-0600)] <colinclark> ah, this is good

[09:33:57 CST(-0600)] <colinclark> it's reading the image's header

[09:34:00 CST(-0600)] <colinclark> that's exactly what you want

[09:34:17 CST(-0600)] <colinclark> I'd imagine there are equivalents on the client side these days

[09:34:25 CST(-0600)] <colinclark> I wrote something that parses audio file formats like this

[09:34:40 CST(-0600)] <colinclark> but again, you're probably all set on the server with this library

[09:35:04 CST(-0600)] <Justin_o> colinclark: great.. i might look into the client side when i get back down there later.. thanks for letting me know that it is possible

[09:38:55 CST(-0600)] <Justin_o> colinclark: by the way, do you think you might have a chance today to look over the Decapod server side code

[09:41:44 CST(-0600)] <colinclark> Sure, I think I can do that

[09:42:14 CST(-0600)] <Justin_o> colinclark: thanks

[10:13:00 CST(-0600)] <jhung> justin_o: I'm going to re-open DECA-217 (remove camera capture and calibration). There are some image files in the shared folder that needs removing.

[10:13:22 CST(-0600)] <Justin_o> jhung: sure

[10:13:25 CST(-0600)] <Justin_o> thanks for letting me know

[10:13:39 CST(-0600)] <Justin_o> jhung: i'm wondering if we should remove the mock-images from the server too

[10:14:37 CST(-0600)] <jhung> justin_o: yes, I think they should be removed.

[10:14:50 CST(-0600)] <jhung> they weren't sufficient quality / resolution anyway justin_o.

[10:15:17 CST(-0600)] <jhung> but maybe we should add a samples directory with 2 images that are useful?

[10:15:18 CST(-0600)] <Justin_o> jhung: okay.. i'll look at removing those.. i wouldn't mind keeping one or two around for the unit tests, but i'll have to do some reorganizing of the test directory for that

[10:15:34 CST(-0600)] <Justin_o> jhung: if you have a couple useful ones please post them up on the jira or something

[10:15:38 CST(-0600)] <Justin_o> how big are they though?

[10:15:58 CST(-0600)] <Justin_o> keeping around large binaries isn't the strong suite of DVCs

[10:16:04 CST(-0600)] <jhung> justin_o: large unfortunately.

[10:16:25 CST(-0600)] <Justin_o> jhung: maybe for now we'll just stick with a couple of the ones we have

[10:16:59 CST(-0600)] <jhung> justin_o: how about we host a sample package on our wiki and our install script can download and extract them during the install procedure?

[10:17:07 CST(-0600)] <Justin_o> jhung: we can try to think of a better solution later.. just don't want to make the download unnecessarily large

[10:17:12 CST(-0600)] <jhung> ok

[10:17:32 CST(-0600)] <jhung> I guess we'll leave it for now then but clean it up a little for release.

[10:17:45 CST(-0600)] <Justin_o> jhung: you might be able to put something in our svn repo for that i guess

[10:17:57 CST(-0600)] <Justin_o> we can talk to avatar about it later today

[10:18:02 CST(-0600)] <jhung> justin_o: ok

[10:28:06 CST(-0600)] <jhung> justin_o: should import, imageManagement, capture, and calibration be removed from decapod-ui/components/ ?

[10:28:24 CST(-0600)] <jhung> I don't think we need them any more after this release.

[10:42:26 CST(-0600)] <Justin_o> jhung: i thought we had already removed capture and calibration.. if they are still there then yes, they could be removed.. same goes for imageManagement

[10:42:37 CST(-0600)] <Justin_o> as for import, if we aren't going to use any of it anymore, then sure..

[10:42:38 CST(-0600)] <jhung> oh.

[10:42:59 CST(-0600)] <jhung> justin_o: I realized I was in the wrong repo.

[10:43:07 CST(-0600)] <Justin_o> jhung:

[10:43:15 CST(-0600)] <jhung> thanks justin_o.

[10:55:59 CST(-0600)] <jhung> justin_o: decapod meeting in 5

[10:57:19 CST(-0600)] <Justin_o> jhung: thanks.. logging into Skype now

[11:14:07 CST(-0600)] <michelled> colinclark: wondering if you can help me with my current issue - in the computed style for my iframe I have a width of 300px - how can I tell where that is coming from?

[11:16:00 CST(-0600)] <colinclark> The Firebug CSS inspector isn't helping you find its origin, michelled?

[11:16:11 CST(-0600)] <colinclark> In other words, you can't find an appropriate rule for it?

[11:16:21 CST(-0600)] <michelled> colinclark: I don't seen any rule for in

[11:16:42 CST(-0600)] <colinclark> do you have a branch I can look at?

[11:16:46 CST(-0600)] <michelled> in fact, from what I can tell, I should be getting a width of 100% based on the use of the fl-container-flex class

[11:17:10 CST(-0600)] <michelled> yes, it's FLUID-4582

[11:17:18 CST(-0600)] <colinclark> url?

[11:17:46 CST(-0600)] <michelled> https://github.com/michelled/videoPlayer/tree/FLUID-4582

[11:17:50 CST(-0600)] <colinclark> thanks

[11:21:44 CST(-0600)] <colinclark> What file do I need to test with, michelled?

[11:22:04 CST(-0600)] <michelled> demos/VideoPlayer.html

[11:22:07 CST(-0600)] <colinclark> k

[11:22:29 CST(-0600)] <colinclark> wow, wacky styling here

[11:22:38 CST(-0600)] <michelled> yeah

[11:23:53 CST(-0600)] <colinclark> gimme a few minutes to explore your markup and styles

[11:25:04 CST(-0600)] <michelled> colinclark: a lot of the video player styling is changing in anastasiac's branch

[11:25:19 CST(-0600)] <michelled> but none of that should be effecting UIO on the page

[11:25:32 CST(-0600)] <colinclark> This is one of the reasons it would be great to have CSS and markup changes isolated from other issues

[11:25:39 CST(-0600)] <colinclark> so that you could just grab those changes and see how they impact things

[11:25:47 CST(-0600)] <colinclark> We'll get there soon, I'm guessing?

[11:26:26 CST(-0600)] <michelled> yep - anastasiac is working on it as we speak

[11:26:45 CST(-0600)] <colinclark> So, to start, I don't think it's an interaction with the Video Player's style sheet

[11:26:55 CST(-0600)] <colinclark> since removing it continues to show the strange UIO behaviour

[11:27:05 CST(-0600)] <colinclark> Are you perhaps missing a UIO stylesheet in the parent?

[11:27:40 CST(-0600)] <michelled> I suppose it's possible, although I've used a new build of infusion and didn't change much

[11:28:01 CST(-0600)] <colinclark> I don't see you linking to the Fat Panel UIO style sheet here

[11:29:26 CST(-0600)] <colinclark> That helps a bit

[11:29:40 CST(-0600)] <colinclark> At least showing and hiding works properly now, michelled

[11:29:46 CST(-0600)] <michelled> ah, good point - thx colinclark

[11:32:30 CST(-0600)] <colinclark> looks to me like this branch may also be missing the necessary jQuery UI stylesheets

[11:33:01 CST(-0600)] <michelled> yep - you're right - I was just making a note of that in my file

[11:33:04 CST(-0600)] <colinclark> from Infusion

[11:33:10 CST(-0600)] <michelled> thanks for your help - this is working now

[11:33:21 CST(-0600)] <colinclark> michelled: The UIOptions tutorial is pretty clear about the necessary style dependencies, which is great

[11:33:30 CST(-0600)] <colinclark> Not to say, "rtfm"

[11:33:43 CST(-0600)] <michelled>

[11:34:00 CST(-0600)] <colinclark> anyway, it's looking good here

[11:34:07 CST(-0600)] <colinclark> I could give you a pull request, but you've probably already got it?

[11:35:07 CST(-0600)] <michelled> yes, I've got it and anyway, you're going to have to look at my pull request when it's ready

[11:40:36 CST(-0600)]

[11:41:27 CST(-0600)] <cindyli> ah ha. i think that's the reason, as Bosmon has stated yesterday afternoon in the channel

[11:41:55 CST(-0600)] <anastasiac> I'll have to check that log to revise my understanding of when we should be attaching methods to the component object

[12:08:15 CST(-0600)] <colinclark> yura: Do you know if Kasper has permanently secured a time slot on Gregg's trace Connect instance for our weekly meetings?

[12:08:49 CST(-0600)] <yura> colinclark: as far as i know we had this time on weekly basis

[12:08:56 CST(-0600)] <colinclark> okay

[12:09:06 CST(-0600)] <colinclark> How did it go with connect last time? Should we use it again?

[12:12:41 CST(-0600)] <yura> ya it was pretty good

[12:13:13 CST(-0600)] <colinclark> triton is on his phone and would prefer skype

[12:13:15 CST(-0600)] <colinclark> so i'll start it up

[13:34:10 CST(-0600)] <michelled> colinclark: question for you: I've got the basic UIO working in the video player. There is still an issue with the button icons not showing in the white on black and yellow on black themes. These icons are changing soon to match the high fidelity mockups.

[13:34:32 CST(-0600)] <michelled> colinclark: do you think I should fix this before issuing the pull request?

[13:35:47 CST(-0600)] <colinclark> michelled: Can you elaborate on the issue?

[13:35:51 CST(-0600)] <colinclark> which button icons?

[13:36:07 CST(-0600)] <Bosmon> Hi cindyli

[13:36:13 CST(-0600)] <Bosmon> Initial comments on your pull request

[13:36:15 CST(-0600)] <cindyli> yes, Bosmon

[13:36:38 CST(-0600)] <Bosmon> i) You shouldn't be using the "options" structure to be storing modifiable state, for example as on line 100 of the "conductor"

[13:36:51 CST(-0600)] <Bosmon> But the overall algorithm and structure of the component are now looking good

[13:37:35 CST(-0600)] <Bosmon> ii) there is continued creepage in creating private utility functions such as "inInterval"....

[13:38:17 CST(-0600)] <Bosmon> iii) Always watch out for functions which have "return true/false" for whether you could express the more economically

[13:38:34 CST(-0600)] <michelled> sorry colinclark - I was taking a moment to chat with the designers. I was under the impression that were about to receive new wireframes but it looks like I'm wrong on that.

[13:38:56 CST(-0600)] <Bosmon> For example, you could write this function much more succinctly as "return currentTimeInMillis >= interval.begin && currentTimeInMills <= interval.end"

[13:39:10 CST(-0600)] <cindyli> ah, nice

[13:39:19 CST(-0600)] <michelled> colinclark: the issue is that we don't have icons in the correct colour for a couple of the themes so you can't visually see the play icon on the play button

[13:39:36 CST(-0600)] <michelled> colinclark: after talking to the designers we've decided that I should go ahead with what Charly had

[13:39:54 CST(-0600)] <michelled> sorry to bother you colinclark - I will fix the button visibility issue before doing the pull request

[13:40:10 CST(-0600)] <Bosmon> iv) It is probably time to rename the variable "currentIndice" as "currentIndex", being a more recognisable English word : P

[13:40:43 CST(-0600)] <colinclark> michelled: I still am slightly fuzzy

[13:41:01 CST(-0600)] <Bosmon> v) moving the "convertoToMilli" from a public function to a method is a regression, it should be returned to being a public utility

[13:41:07 CST(-0600)] <colinclark> You're saying that the Video Player doesn't currently have appropriate styles and graphics for some of our high contrast themes, michelled?

[13:41:19 CST(-0600)] <michelled> colinclark: yes

[13:41:31 CST(-0600)] <colinclark> michelled: And what is the plan for getting those graphics/styles in place?

[13:41:52 CST(-0600)] <cindyli> Bosmon: in terms of , as said: "shouldn't be using the "options" structure to be storing modifiable state", why? Where's the proper place to store it?

[13:41:55 CST(-0600)] <Bosmon> This method could also do with more documentation - what exactly is the format which it accepts, and why is it there?

[13:42:08 CST(-0600)] <Bosmon> cindyli - a component's options should be considered modifiable after startup

[13:42:11 CST(-0600)] <Bosmon> sorry

[13:42:13 CST(-0600)] <Bosmon> Shouldn't

[13:42:26 CST(-0600)] <cindyli> ok

[13:42:45 CST(-0600)] <Bosmon> You could store the thing either in a closure, (messily) on the top-level "that", or (if appropriate) in the model

[13:43:18 CST(-0600)] <cindyli> ok

[13:44:52 CST(-0600)] <Bosmon> Given this is the only job of this component, giving it a model isn't a completely silly idea

[13:45:18 CST(-0600)] <cindyli> Bosmon: still (1), we are talking about intervalList, right? It's not modifiable after the startup

[13:45:53 CST(-0600)] <colinclark> So, basically, Bosmon, the rule of thumb is that options are for static component configuration used at startup time...

[13:45:57 CST(-0600)] <Bosmon> cindyli - i was speaking of previousIntervalId

[13:46:04 CST(-0600)] <colinclark> and a model is the appropriate place to put dynamically modified state

[13:46:05 CST(-0600)] <cindyli> ah, ok. i see

[13:46:09 CST(-0600)] <colinclark> is that correct, Bosmon?

[13:46:12 CST(-0600)] <Bosmon> Which right now you write to on line 105

[13:46:17 CST(-0600)] <Bosmon> colinclark - that's right

[13:46:26 CST(-0600)] <cindyli> cool. got you, Bosmon

[13:46:30 CST(-0600)] <colinclark> gold star for me!

[13:46:31 CST(-0600)] <Bosmon> We imagine that in the end there might be a "slow" model for options to change over time

[13:46:49 CST(-0600)] <Bosmon> perhaps under an event-driven scheme similar to the kind we are building for GPII

[13:46:59 CST(-0600)] <Bosmon> But the idea is that they are intended to be "not casually modifiable"

[13:47:19 CST(-0600)] <Bosmon> Anything which "routinely changes over the lifetime of a component" should probably be in its model

[13:47:21 CST(-0600)] <colinclark> like the change applier-backed options scheme we'd be considering a year or two ago?

[13:47:27 CST(-0600)] <Bosmon> colinclark - yes, that

[13:47:44 CST(-0600)] <colinclark> exactly like what we're advocating for GPII, yes

[13:50:51 CST(-0600)] <michelled> colinclark: I need to check all the icon files that are in the repo right now and maybe generate new ones using jquery ui. the video player is currently using jquery ui icons, as far as I can tell. Once the designers are done, we'll be moving to our own icons - at which point we'll need to create them to work in all of our UIO themes.

[13:51:14 CST(-0600)] <colinclark> michelled: seems reasonable to me

[13:51:23 CST(-0600)] <colinclark> you're good to go, as you already said

[13:51:39 CST(-0600)] <michelled> gold star for me too

[13:54:09 CST(-0600)] <Bosmon> cindyli - vi) your test case data (VPIECT.js line 26) could more idiomatically be expressed as a JSON structure than in code, and also I notice that it contains overlapping intervals

[13:54:32 CST(-0600)] <Bosmon> This probably isn't appropriate to test since the behaviour of the component on receiving overlapping intervals is not yet specified and probably shouldn't be

[13:54:40 CST(-0600)] <Bosmon> Although it is probably appropriate to test that it doesn't explode completely

[13:55:16 CST(-0600)] <Bosmon> I am suspicious of your "testIntervalChangeError" function since it doesn't look like it tests what it should

[13:55:40 CST(-0600)] <Bosmon> For example, you have an "onTimeChange" listener which prints out a message saying "onIntervalChange is NOT fired" : P

[13:55:43 CST(-0600)] <Bosmon> This doesn't seem completely logical

[13:56:19 CST(-0600)] <Bosmon> Similarly the message on the onIntervalChange listener doesn't seem to reflect its purpose, or use its argument

[13:57:35 CST(-0600)] <Bosmon> You really do need to be able to test for the ABSENCE of an event, which can only be done by performing the action which might fire the event, write a listener which modifies some state, and then having a test outside the listener that the state is not modified

[13:57:57 CST(-0600)] <cindyli> ok, i see

[13:58:56 CST(-0600)] <Bosmon> For example, just because my CATT is drinking his water, doesn't imply that he is not eating his CATT FFOOD : P

[13:59:58 CST(-0600)] <cindyli> agree. wasn't sure about how to test for "the ABSENCE of an event"

[14:00:09 CST(-0600)] <cindyli> will try ur suggestion

[14:05:27 CST(-0600)] <colinclark> hey avtar, are you available to join some discussions with Bosmon and yura sometime in the next week or so to talk about database and scalability?

[14:05:44 CST(-0600)] <colinclark> Based on the research they've been doing related to the Apache CouchDB vs. CouchBase fork?

[14:06:13 CST(-0600)] <colinclark> In the end, we're going to take a look at the scalability profile of a few other document-oriented stores, including MongoDB, Riak, Redis, and Cassandra

[14:06:26 CST(-0600)] <colinclark> but it's always good to have your cloudly perspective on it

[14:07:04 CST(-0600)] <avtar> that sounds good

[14:07:07 CST(-0600)] <avtar> which day?

[14:07:25 CST(-0600)] <colinclark> i'll leave that to you and yura and Bosmon to decide

[14:07:52 CST(-0600)] <colinclark> I'm keen to listen in too, but I'm fairly flexible schedule-wise these days

[14:08:52 CST(-0600)] <colinclark> Justin_o: You were asking about creating synthetic file upload POST requests for a Python unit test...

[14:09:18 CST(-0600)] <colinclark> you can see how the Uploader actually creates its POST in this file:

[14:09:22 CST(-0600)] <colinclark> https://github.com/fluid-project/infusion/blob/master/src/webapp/components/uploader/js/HTML5UploaderSupport.js

[14:09:59 CST(-0600)] <colinclark> in particular, the slightly insane code here is responsible for putting together the MIME header: https://github.com/fluid-project/infusion/blob/master/src/webapp/components/uploader/js/HTML5UploaderSupport.js#L225-245

[14:10:36 CST(-0600)] <colinclark> And then the image is going to just be a binary string wrapped in the MIME envelope

[14:10:56 CST(-0600)] <colinclark> For a unit test, I'd be tempted to grab a Web proxy like Charles, upload an image, and then grab the request for your unit test

[14:11:02 CST(-0600)] <colinclark> I guess this is an integration test

[14:14:00 CST(-0600)] <Justin_o> colinclark: thanks.. yes… i guess it's more of an integration test.. although i'm really just concerned with the response.. not as much what it is doing underneath

[14:14:34 CST(-0600)] <colinclark> the response from the server, when given a file in the request?

[14:15:39 CST(-0600)] <Justin_o> colinclark: yes… http response code, the response body

[14:17:24 CST(-0600)] <colinclark> Sounds like you're going to have some serious test coverage for Decapod

[14:17:44 CST(-0600)] <colinclark> Yeah, I'd probably grab a file upload request with a proxy and use that in your integration test

[14:18:03 CST(-0600)] <Justin_o> colinclark: thanks.. i'll try that

[14:19:32 CST(-0600)] <michelled> cindyli: shall we meet?

[14:19:40 CST(-0600)] <cindyli> sure, cindyli

[14:20:03 CST(-0600)] <cindyli> sure, michelled. my brain is going …. insane

[15:21:34 CST(-0600)] <cindyli> anastasiac, michelled, fyi, i've added the new jira http://issues.fluidproject.org/QuickSearch.jspa?searchString=FLUID-4586 (Add the detection of html5/non-html5 browser into framework) into the iteration plan

[15:21:46 CST(-0600)] <michelled> thx cindyli

[15:21:51 CST(-0600)] <cindyli> np

[15:22:21 CST(-0600)] <colinclark> michelled, cindyli Did you guys talk at all about how this will work?

[15:27:12 CST(-0600)] <cindyli> colinclark: how what will work? progressive enhancement within video player?

[15:27:20 CST(-0600)] <colinclark> yep

[15:27:33 CST(-0600)] <cindyli> no, i think just a mimic of uploader

[15:27:59 CST(-0600)] <cindyli> does it sound right, colinclark

[15:28:19 CST(-0600)] <colinclark> I wonder if this one is a bit different

[15:29:15 CST(-0600)] <colinclark> What will we degrade to if HTML5 media isn't available in the browser?

[15:29:35 CST(-0600)] <cindyli> mediaElement for non-html5

[15:29:38 CST(-0600)] <anastasiac> Bosmon, are you there?

[15:29:45 CST(-0600)] <colinclark> cindyli: Right

[15:29:57 CST(-0600)] <colinclark> So I guess it's slightly different, conceptually

[15:30:08 CST(-0600)] <colinclark> We will, in that case, not degrade to a different implementation

[15:30:16 CST(-0600)] <colinclark> We'll need to load another library

[15:30:27 CST(-0600)] <colinclark> and then the browser will behave as if it were HTML5-enabled

[15:30:32 CST(-0600)] <cindyli> right

[15:30:47 CST(-0600)] <colinclark> we don't really have any dynamic loading infrastructure right now

[15:30:48 CST(-0600)] <michelled> colinclark, Bosmon, cindyli: I'd like to schedule a code review of the toggle button - we touched it briefly on Friday but I think it needs a review before getting into the repo

[15:30:59 CST(-0600)] <colinclark> ok, sure

[15:31:00 CST(-0600)] <colinclark> when?

[15:31:07 CST(-0600)] <michelled> since we don't have a community meeting tomorrow, could we do it then?

[15:31:36 CST(-0600)] <colinclark> works ofr me

[15:31:45 CST(-0600)] <cindyli> fine with me too

[15:33:08 CST(-0600)] <colinclark> Can we think of anything that would actually change the resolution of specific VIdeo Player components?

[15:33:25 CST(-0600)] <colinclark> In other words, is there anything different in the dependency tree for, say, IE 8 than there would be for Chrome?

[15:35:05 CST(-0600)] <cindyli> colinclark: does uploader dynamically load swfobject lib only at the present of the flash version?

[15:35:15 CST(-0600)] <cindyli> no, i guess

[15:35:18 CST(-0600)] <colinclark> unfortunately it does not

[15:35:27 CST(-0600)] <colinclark> It's something we wanted to address at some point

[15:35:42 CST(-0600)] <colinclark> since we end up delivering more files to the browser than is likely needed

[15:35:49 CST(-0600)] <cindyli> exactly

[15:36:09 CST(-0600)] <colinclark> I guess we could probably do something IoC-powered

[15:36:14 CST(-0600)] <colinclark> It's just an issue of timing

[15:36:53 CST(-0600)] <colinclark> fascinating, anyway

[15:37:05 CST(-0600)] <colinclark> maybe a version 2 feature, in the end

[15:37:16 CST(-0600)] <colinclark> in which case, I guess you're right

[15:37:27 CST(-0600)] <cindyli> yes, would nice that way

[15:37:32 CST(-0600)] <cindyli> with 2 features i mean

[15:37:36 CST(-0600)] <colinclark> we'd do some IoC-based resolution that would involve including a component that instantiates MediaElement.js as needed

[15:37:47 CST(-0600)] <colinclark> and just live with the fact that we have to ship ME.js to every browser for now

[15:38:05 CST(-0600)] <colinclark> until we get some kind of IoC-enabled loader

[15:38:12 CST(-0600)] <cindyli> yes

[17:38:01 CST(-0600)] <anastasiac> hey, Bosmon, I have a conundrum I'm wondering if you could help with - do you have a few minutes?

[18:32:42 CST(-0600)] <Bosmon> Hi anastasiac

[18:32:45 CST(-0600)] <Bosmon> Are you still in? : P

[18:32:52 CST(-0600)] <anastasiac> yes, I am

[18:33:01 CST(-0600)] <anastasiac> well, I'm at home, but I'm still "here"

[18:33:18 CST(-0600)] <anastasiac> do you have a few minutes?

[18:33:23 CST(-0600)] <Bosmon> Yes, I do

[18:34:37 CST(-0600)] <anastasiac> I'm trying to refactor the controls for the captions in the VideoPlayer. Given the interactions requested by the designers, I'd like to hook the controls up to each other properly, but keep their concerns cleanly separated

[18:35:11 CST(-0600)] <anastasiac> First, we have the main Captions button: a control that is, in a sense, a toggle button: it has two states reflecting the two possible values of the model ("on" or "off"). However, activating the control doesn't affect the model state: it merely shows or hides a submenu that offers choices for affecting the model state. Depending on what the user chooses from the options in the menu, the model state reflected by the control may or

[18:35:11 CST(-0600)] <anastasiac> not change.

[18:35:37 CST(-0600)] <anastasiac> Second, we had the list of choices, which seems, on the surface, like a radio button group: selecting any one choice deselects the others. The choice affects two parts of the model: the actual selection and the above mentioned "on"/"off" state. One of the choices turns that state "off", any one of the other choices turns that state "on". So one of the "radio button" behaves a bit differently than the others.

[18:35:47 CST(-0600)] <anastasiac> As well, the label on this special "radio button" also changes to reflect the "on"/"off" state. So its seeming a bit less like a radio button.

[18:35:55 CST(-0600)] <anastasiac> But then what is it?

[18:36:39 CST(-0600)] <Bosmon> These problems are usually simplified by creating extra pieces of model

[18:36:39 CST(-0600)] <Bosmon> Which is something we haven't yet done enough on in Fluid

[18:36:54 CST(-0600)] <Bosmon> So for example, conundrum 1 is solved by creating a special piece of "view model" which relates to the condition of the captions button

[18:37:09 CST(-0600)] <anastasiac> yes, I realize that much

[18:37:37 CST(-0600)] <anastasiac> oh, wait, view model? not a state in the model reflecting the "on/off-ness" of the captions?

[18:37:50 CST(-0600)] <Bosmon> No, that is what it means

[18:37:58 CST(-0600)] <Bosmon> A state reflecting the on-offness of the captions

[18:38:04 CST(-0600)] <anastasiac> oh, ok. That's what i was planning.

[18:38:20 CST(-0600)] <anastasiac> and that same state needs to be reflected in the 'on/off' choice in the menu

[18:38:35 CST(-0600)] <anastasiac> the menu choices will affect that state

[18:38:42 CST(-0600)] <Bosmon> And the list of choices then does behave a lot like a radio button, but one which may be in a "globally off" state

[18:38:57 CST(-0600)] <Bosmon> Some older kinds of radio buttons on desktop apps actually worked like this : P

[18:39:08 CST(-0600)] <Bosmon> Do you remember the era of "tri-state checkboxes"? : P

[18:39:13 CST(-0600)] <anastasiac> yeah

[18:39:39 CST(-0600)] <anastasiac> but you couldn't really render this as all radio buttons, could you? one radio button needs to set the state to off, all the others set it to on

[18:39:43 CST(-0600)] <Bosmon> So the rest can be fixed up by creating various listeners through the changeApplier that coordinate pieces of the model state

[18:40:08 CST(-0600)] <Bosmon> This is a model which has various "restricted states" which are not valid in the UI, which is the use case addressed by "guards"

[18:40:14 CST(-0600)] <Bosmon> Which is also something we don't quite have enough of

[18:40:43 CST(-0600)] <anastasiac> how would guards be used here?

[18:40:54 CST(-0600)] <Bosmon> The guard reacts to an attempt to set the model to the "restricted state" and "corrects" it by firing a further changeApplier event

[18:41:10 CST(-0600)] <Bosmon> Once all the shouting is over, the UI is rendered in the newly "corrected" state

[18:41:32 CST(-0600)] <anastasiac> so in the context of selecting captions

[18:41:43 CST(-0600)] <Bosmon> In this way we put all the intelligence in the model, where it should be, rather than writing lots of complex controller/view logic

[18:42:03 CST(-0600)] <anastasiac> what does "restricted state" mean here?

[18:43:20 CST(-0600)] <Bosmon> Well, actually if we just reorganise the model a bit, we can probably get rid of this complexity entirely

[18:43:35 CST(-0600)] <Bosmon> If we represent the model state as an "array of booleans" rather than a "radio selection plus boolean"

[18:44:38 CST(-0600)] <Bosmon> It should be possible to use the renderer to bind to this kind of model using the radio buttons, let me check....

[18:45:53 CST(-0600)] <Bosmon> Yes, it looks fine...

[18:46:24 CST(-0600)] <Bosmon> So yes, I guess you still need the guard

[18:46:41 CST(-0600)] <anastasiac> so how would you bind an array of booleans to a set of radio buttons?

[18:46:44 CST(-0600)] <Bosmon> The "restricted state" is where someone has chosen on of the other buttons, and the captions state is not on

[18:46:47 CST(-0600)] <anastasiac> using the renderer, I mean

[18:47:16 CST(-0600)] <Bosmon> All you need to do is issue an array of "UIInput" controls, as if they were all checkboxes

[18:47:27 CST(-0600)] <Bosmon> And then in the UI, give it the type radiobutton

[18:47:37 CST(-0600)] <Bosmon> "radio"

[18:47:46 CST(-0600)] <anastasiac> so not using the section to inputs expander

[18:48:12 CST(-0600)] <Bosmon> Right

[18:49:07 CST(-0600)] <anastasiac> so the guard on the model is where all the logic would go

[18:49:17 CST(-0600)] <anastasiac> to figure out whether captions are being turned on or off

[18:49:46 CST(-0600)] <Bosmon> Yes

[18:50:00 CST(-0600)] <Bosmon> If you look in DataBindingTests, around line 285

[18:50:04 CST(-0600)] <anastasiac> it would look at the array of booleans, and it would know that the last one is the "off" switch and the rest are "on" switches

[18:50:08 CST(-0600)] <Bosmon> You can see some complex examples of applying guarsd to things

[18:50:33 CST(-0600)] <Bosmon> Well, I realise now that they would not actually be an array of booleans - they can all have names

[18:50:51 CST(-0600)] <Bosmon> It's just in the UI they will appear as an array, since that is how you issue multiple UIInput controls

[18:51:10 CST(-0600)] <anastasiac> ok

[18:51:15 CST(-0600)] <Bosmon> You'll need to give me an allowance for my lingering bronchitis : P

[18:51:39 CST(-0600)] <anastasiac> don't worry, this is very helpful, thanks so much for you time

[18:52:07 CST(-0600)] <Bosmon> Thanks for your model merging problem, I'll look at that this evening

[18:52:22 CST(-0600)] <anastasiac> oh, I was going to check if you saw that, thanks

[18:52:44 CST(-0600)] <anastasiac> so the model will be constructed based on the languages provided by the integration, with the "off" option added

[18:53:01 CST(-0600)] <Bosmon> Are you sure this (the model merging) worked correctly before we had the new implementation?

[18:53:31 CST(-0600)] <anastasiac> yes, it certainly seemed to – I didn't change anything in my code

[18:54:08 CST(-0600)] <anastasiac> I notice that the new fluid.model.mergeModel implementation is different than the old one

[18:54:30 CST(-0600)] <anastasiac> maybe I'm misunderstanding how models should be merged, but...

[18:54:57 CST(-0600)] <Bosmon> Yes, the problem looks like it is due to the jQuery shallow copy

[18:55:00 CST(-0600)] <Bosmon> But I'm surprised if this ever worked correctly

[18:55:16 CST(-0600)] <anastasiac> did the old version of the function use the same jQuery copy?

[18:55:31 CST(-0600)] <Bosmon> Aha

[18:55:33 CST(-0600)] <anastasiac> I thought it requested a model change

[18:55:44 CST(-0600)] <Bosmon> It looks like the changeApplier actually uses a deep copy at the final stage

[18:55:59 CST(-0600)] <Bosmon> Well it does, but everything hits jQuery.extend in the ultimate event : P

[18:56:10 CST(-0600)] <Bosmon> Ok, well, this will be great to have a test case for

[18:56:22 CST(-0600)] <Bosmon> I remember worrying when I reimplemented this whether I had got all the subtleties right

[18:56:34 CST(-0600)] <Bosmon> And then I looked at how many test cases there were and was given some confidence : P

[18:59:05 CST(-0600)] <anastasiac> Bosmon, thanks for you suggestions for the captions controls. I'll look at the DataBindingTests for inspiration on how to apply a guard for this case

[18:59:41 CST(-0600)] <Bosmon> You'll find at the moment that you will have to register these guards manually, since this is a very old part of the framework that dates to before we had declarative ways of doing most things

[18:59:54 CST(-0600)] <Bosmon> But I'm aiming to fix this as part of my UIOptions work during February

[19:00:04 CST(-0600)] <anastasiac> at which stage of the component creation should that be done?

[19:00:15 CST(-0600)] <Bosmon> You'll have to do it in the postInitFunction or so

[19:00:33 CST(-0600)] <anastasiac> ok, that's what i figured

[19:00:37 CST(-0600)] <Bosmon> It doesn't really matter particularly which timing you use, the applier will have been created by then anyway

[19:01:05 CST(-0600)] <anastasiac> that reminds me, I also wanted to check on what seems to be a documentation issue

[19:01:08 CST(-0600)] <Bosmon> This "guard" facility was really originally intended to be used in the "improved pager" implementation

[19:01:11 CST(-0600)] <Bosmon> But that never arrived

[19:01:32 CST(-0600)] <anastasiac> regarding cindy's "listener is undefined" problem earlier

[19:01:34 CST(-0600)] <Bosmon> You can see that it is an example of the same kind of thing - there are "next" and "previous" controls which add and subtract one to a page number

[19:01:47 CST(-0600)] <Bosmon> But should the page be at the end of the page, the model should end up in a "restricted state" and then correct itself

[19:01:57 CST(-0600)] <anastasiac> ah, good pointer

[19:02:00 CST(-0600)] <anastasiac> thanks

[19:02:01 CST(-0600)] <Bosmon> sorry, should the page be at the end of the list of pages

[19:02:10 CST(-0600)] <Bosmon> Well, this never actually got implemented in the Pager

[19:02:16 CST(-0600)] <Bosmon> The one we have just uses old-fashioned logic : P

[19:02:19 CST(-0600)] <anastasiac>

[19:02:37 CST(-0600)] <Bosmon> But the test cases suggest the way that it should have been

[19:02:45 CST(-0600)] <Bosmon> (should have going to be, who knows)

[19:02:59 CST(-0600)] <Bosmon> One day, lemon-soaked paper napkins may arise, and the Pager may become reimplemented

[19:03:23 CST(-0600)] <anastasiac> if I want to use IOC to use a component method as a listener for an event, that method has to be attached to the component object in the preInit, doesn't it? postInit is too late?

[19:03:37 CST(-0600)] <Bosmon> THat's correct

[19:03:40 CST(-0600)] <anastasiac> ok

[19:03:51 CST(-0600)] <anastasiac> the lifecycle docs say postInit is the time to attach methods

[19:03:53 CST(-0600)] <Bosmon> As you can see from the "diagram", IoC doesn't enter the picture until after preInit

[19:04:02 CST(-0600)] <anastasiac> we'll have to revise that to point out this restriction

[19:04:10 CST(-0600)] <Bosmon> It does, but they should also say that anything which is referred to using IoC needs to be attached earlier

[19:04:22 CST(-0600)] <anastasiac> right

[19:04:35 CST(-0600)] <anastasiac> ok, thanks for the double-check on that

[19:04:44 CST(-0600)] <Bosmon> Typically it is the methods which refer to IoC material, and not the other way round

[19:04:49 CST(-0600)] <Bosmon> But it can happen the other way

[19:05:25 CST(-0600)] <Bosmon> We only have this mess because of the lack of the GINGER WORLD

[19:07:40 CST(-0600)] <anastasiac> Bosmon, thanks so much for your help. Perhaps once i have an implementation, you can have a look at it?

[19:09:42 CST(-0600)] <anastasiac> ok, gotta sign off now. Thanks!