fluid-work IRC Logs-2012-07-25

[08:13:16 CDT(-0500)] <helipus> Hi guys, is this channel for the typo3 fluid framework which comes with extbase?

[08:18:06 CDT(-0500)]

[08:18:06 CDT(-0500)]

[08:18:06 CDT(-0500)] <helipus> the idea is to append "<br />" to every foreach item except the last

[08:18:24 CDT(-0500)] * Topic is 'This channel is logged – for details see: http://wiki.fluidproject.org/display/fluid/IRC+Channel' set by jessm on 07:30:00 CST(-0600)

[08:51:42 CDT(-0500)] <anastasiac> michelled, regarding FLOE-17, images that don't respond to UIO: Are the changes you've made merged into a11y-uio yet, or are you waiting for 660?

[08:53:11 CDT(-0500)] <michelled> anastasiac: I think 660 was that last thing outstanding - did you find other issues?

[08:54:21 CDT(-0500)] <anastasiac> michelled, I'm looking at the basic browse interface in high-contrast, and the small graphic beside the license info (e.g. "Share only" or "Remix and share" is not high contrast. Is that a known issue?

[08:55:01 CDT(-0500)] <michelled> yeah - 17 was about buttons, right?

[08:55:16 CDT(-0500)] <michelled> anastasiac: I think the other issues are covered in 43

[08:55:40 CDT(-0500)] <michelled> other than facebook, twitter and google + which has its own JIRA

[08:55:49 CDT(-0500)] <anastasiac> ah, right, I'm getting my JIRAs confused. And 43 is not yet merged into a11y-uio, right?

[08:56:53 CDT(-0500)] <michelled> anastasiac: most of 43 is - but there are a lot of details that are not done yet

[08:57:10 CDT(-0500)] <anastasiac> ok, michelled, just trying to figure out the best thing to work on today

[08:57:35 CDT(-0500)] <michelled> anastasiac: I think 12 or 46 make the most sense

[08:57:40 CDT(-0500)] <michelled> since I'm working on 43 still

[08:57:52 CDT(-0500)] <anastasiac> k, I'll check in with Joanna

[09:00:09 CDT(-0500)] <michelled> anastasiac: if you'd rather work on 43, you can take on a part of the UI

[09:00:19 CDT(-0500)] <anastasiac> no, no problem michelled

[09:06:21 CDT(-0500)] <michelled> anastasiac: I noticed another issue that we need to fix - I don't think there's a JIRA for it yet. On the preview, the learner options tab is on the wrong side of the user drop down

[09:06:45 CDT(-0500)] <anastasiac> ok, michelled, I'll file that one

[09:06:54 CDT(-0500)] <michelled> anastasiac: and another - there is a scroll bar on the main content in the authoring tool in high contrast

[09:07:12 CDT(-0500)] <anastasiac> michelled, is the scrollbar not there in the default theme?

[09:07:51 CDT(-0500)] <michelled> I don't think so - I don't have a working system at the moment so I can't check

[09:08:58 CDT(-0500)] <anastasiac> k

[09:26:51 CDT(-0500)] <Justin_o> michelled: i'm in a bit of bind for something in decapod… wondering if you might have some thoughts on how to do something

[09:27:09 CDT(-0500)] <michelled> what's going on Justin_o?

[09:27:24 CDT(-0500)] <Justin_o> michelled: okay.. here's the design.. http://issues.fluidproject.org/secure/attachment/12577/Decapod+0.6+Export-14.png

[09:27:39 CDT(-0500)] <Justin_o> michelled: i'm working on the bottom portion. when the user enters an invalid value

[09:28:12 CDT(-0500)] <michelled> ok

[09:28:26 CDT(-0500)] <Justin_o> michelled: so i had wanted to use the tooltip wrapper component we have in infusion.. the way it works is that a jQuery UI tooltip is created on the wrappers container

[09:28:43 CDT(-0500)] <michelled> right

[09:28:54 CDT(-0500)] <Justin_o> the issue i'm having is that i only want this tooltip to show up when the field with the invalid input has focus

[09:29:49 CDT(-0500)] <michelled> and right now when does it shoe?

[09:29:50 CDT(-0500)] <Justin_o> michelled: so the question is, how do i create it.. since the need for it will be sort of dynamic

[09:29:50 CDT(-0500)] <michelled> show?

[09:30:07 CDT(-0500)] <Justin_o> michelled: i haven't yet added it

[09:30:46 CDT(-0500)] <Justin_o> michelled: also those inputs are rendered based on a model passed into the component

[09:31:34 CDT(-0500)] <michelled> Justin_o: I guess you could lazily create it if you want - but regardless of when you create it you'll have to customize your 'show' so it only happens on error

[09:31:42 CDT(-0500)] <Justin_o> so i guess it would make the most sense for it to be added by the renderer, but it's only supposed to show on error

[09:32:26 CDT(-0500)] <michelled> yeah, I think you're going to have to over ride the default show behaviour - is there an easy way to do that?

[09:33:10 CDT(-0500)] <Justin_o> michelled: here's the wrapper code https://github.com/fluid-project/infusion/blob/master/src/webapp/components/tooltip/js/Tooltip.js

[09:33:22 CDT(-0500)] <helipus> Hi guys, I want to report a bug for the f:link.external view helper. Can you point me to th eplace or to someone?

[09:34:45 CDT(-0500)] <michelled> helipus: hi there, I'm not sure what you're referring to - is this in Infusion?

[09:34:48 CDT(-0500)] <Justin_o> michelled: here's the tooltip plugin code https://github.com/fluid-project/infusion/blob/master/src/webapp/lib/jquery/plugins/tooltip/js/jquery.ui.tooltip.js

[09:35:31 CDT(-0500)] <helipus> typo3 fluid?

[09:36:38 CDT(-0500)] <helipus> michelled: so sorry if this is not the right irc channel

[09:37:02 CDT(-0500)] <michelled> helipus: is think it's the wrong room

[09:37:11 CDT(-0500)] <helipus> thx anyway

[09:37:14 CDT(-0500)] <helipus> bye

[09:38:13 CDT(-0500)] <Justin_o> michelled: so it looks like i can drill down into the plugin code and disable it, then enable it when there is an error

[09:38:27 CDT(-0500)] <Justin_o> https://github.com/fluid-project/infusion/blob/master/src/webapp/lib/jquery/plugins/tooltip/js/jquery.ui.tooltip.js#L53-59

[09:38:38 CDT(-0500)] <Justin_o> michelled: i guess that's the best way.. what do you think?

[09:39:09 CDT(-0500)] <michelled> Justin_o: that seems so invasive but you might not have an option if you are using the tooltip plugin

[09:39:29 CDT(-0500)] <michelled> Justin_o: I'm sorry - I need to go off line for a bit - we can talk more about it later?

[09:39:51 CDT(-0500)] <Justin_o> michelled: no problem.. i'll try this approach out and see how it goes

[09:40:55 CDT(-0500)] <michelled> cool ttyl

[10:06:11 CDT(-0500)] <Justin_o> anastasiac: do you happen to remember if there is a way to use non-autoInit components within an IoC component?

[10:06:47 CDT(-0500)] <anastasiac> Justin_o, I think you just have to call initDependents yourself

[10:06:55 CDT(-0500)] <anastasiac> we used to do that before IoC

[10:07:18 CDT(-0500)] <Justin_o> anastasiac: but that would mean that my parent component couldn't be autoInit either?

[10:07:32 CDT(-0500)] <anastasiac> ah, hum

[10:08:24 CDT(-0500)] <anastasiac> maybe you could call iniDepenents in one of the lifecycle functions, Justin_o - the pre- or post- or final - whichever corresponds most closely and appropriately with when subcomponents would be initialized

[10:08:47 CDT(-0500)] <Justin_o> anastasiac: okay.. i'll try that.. thanks

[10:19:56 CDT(-0500)] <Justin_o> anastasiac: looks like it's a call to initSubcomponent that i would need to make, but i would need to change my defaults. Also seems like this just won't work in my use case since the renderer is destroying it's container.. so i guess i'll have to think of something else. since at least the proto style of component trees doesn't seem to support non-autoInit components either

[10:20:36 CDT(-0500)] <anastasiac> ah, interesting

[10:34:19 CDT(-0500)] <jessm> fluid-everyone: standup?

[10:50:39 CDT(-0500)] <Justin_o> Bosmon: just wanted to check with you that in the proto style component trees can't handle non-autoInit components as decorators

[10:52:46 CDT(-0500)] <Bosmon> Justin_o - actually there's not a requirement that a decorator even represents at component at all

[10:52:52 CDT(-0500)] <Bosmon> a component

[10:53:16 CDT(-0500)] <Bosmon> Although naturally it is preferable that it does

[10:53:17 CDT(-0500)] <Justin_o> Bosmon: interesting… so i'm getting an object passed in instead of container

[10:53:21 CDT(-0500)] <Bosmon> What is your use case here?

[10:54:03 CDT(-0500)] <Justin_o> Bosmon: i'm trying to use the fluid.tooltip in decapod

[10:54:38 CDT(-0500)] <Justin_o> https://github.com/fluid-project/infusion/blob/master/src/webapp/components/tooltip/js/Tooltip.js

[10:54:55 CDT(-0500)] <Justin_o> Bosmon: i had the same issue when i tried to use it in the components block of my decapod component

[10:55:06 CDT(-0500)] <Bosmon> I see... a venerable and ancient component

[10:55:24 CDT(-0500)] <Bosmon> In theory it should work fine

[10:55:43 CDT(-0500)] <Bosmon> But I guess the default grade is that of "littleComponent"....

[10:56:14 CDT(-0500)] <Justin_o> Bosmon: right.. the problem is not that it isn't autoInited, but that it isn't graded

[10:56:32 CDT(-0500)] <Bosmon> Yes

[10:56:43 CDT(-0500)] <Bosmon> You might just consider submitting a framework fix for that

[10:57:18 CDT(-0500)] <Bosmon> There is some evidence to suggest also, that if you issued a demands block for it that suggested that the component took 2 arguments, you might be able to get it to work....

[10:57:22 CDT(-0500)] <Bosmon> But that looks rather messy

[10:58:11 CDT(-0500)] <Justin_o> Bosmon: interesting… i suppose i could also just rewrite Tooltip.js to be graded.

[10:58:19 CDT(-0500)] <Justin_o> Bosmon: what would you suggest as the best approach

[10:58:35 CDT(-0500)] <Bosmon> We may as well insert grades into every view component in the framework in the same patch

[10:58:39 CDT(-0500)] <Bosmon> It is "no skin off our nose"

[10:58:55 CDT(-0500)] <Bosmon> We quite trust grades now, I think... in many ways despite being newer, they work a lot better than demands blocks

[11:00:33 CDT(-0500)] <Bosmon> I think we should even prepare for it to be an error to issue any component without a grade, in the quite near future

[11:00:42 CDT(-0500)] <Bosmon> Just as soon as we have fixed up all the ones in the framework

[11:00:47 CDT(-0500)] <Justin_o> Bosmon:

[11:00:55 CDT(-0500)] <Justin_o> Bosmon: yes. that makes sense

[11:01:18 CDT(-0500)] <Justin_o> Bosmon: so to be clear, you think we should go through all of our components in Infusion and make them graded.

[11:01:24 CDT(-0500)] <Bosmon> Justin_o - yes, i think so

[11:02:19 CDT(-0500)] <Justin_o> Bosmon: i guess if i don't make them autoInit it should just be a matter of adding gradeNames: … to the defaults

[11:02:27 CDT(-0500)] <Bosmon> Justin_o - that's right

[11:02:32 CDT(-0500)] <Bosmon> It should be a relatively harmless change

[11:02:39 CDT(-0500)] <Bosmon> No implementation code needs to be touched

[11:03:04 CDT(-0500)] <Justin_o> Bosmon: sounds good.. i'll write up a jira and get to that.. mind if i pass it off to you for review afterwards

[11:03:10 CDT(-0500)] <Bosmon> The relevant grade-guessing code is in lines 376-384 in FluidIoC.js

[11:03:18 CDT(-0500)] <Bosmon> As you can see, it is set up to guess wrong quite a lot of the time

[11:03:25 CDT(-0500)] <Bosmon> Justin_o - I'd love to review it

[11:05:40 CDT(-0500)] <Justin_o> Bosmon: thanks

[11:19:42 CDT(-0500)] <Justin_o> fluid-everyone: Just noticed that the imageReorderer tests are failing.. any ideas what might have happened?

[11:19:42 CDT(-0500)] <Justin_o> http://build.fluidproject.org/infusion/tests/component-tests/reorderer/html/ImageReorderer-test.html

[11:19:49 CDT(-0500)] <colinclark> eek

[11:20:27 CDT(-0500)] <Bosmon> That's pretty bad

[11:20:29 CDT(-0500)] <Justin_o> same with the reordered list tests http://build.fluidproject.org/infusion/tests/component-tests/reorderer/html/ReorderList-test.html

[11:20:55 CDT(-0500)] <Bosmon> My first thought was that my jquery upgrade is somehow to blame

[11:21:00 CDT(-0500)] <Bosmon> Although we did run those tests

[11:21:21 CDT(-0500)] <colinclark> I was thinking we might want to organize an Infusion mini-sprint

[11:21:23 CDT(-0500)] <colinclark> for a day or so

[11:21:27 CDT(-0500)] <Bosmon> I guess the good news is that they fail the same way cross-browser

[11:21:27 CDT(-0500)] <colinclark> to fix all these little things

[11:21:29 CDT(-0500)] <colinclark> and do some testing

[11:21:36 CDT(-0500)] <colinclark> the Builder is broken as well, which is a drag

[11:21:37 CDT(-0500)] <anastasiac> the layout reordered demo seems fine

[11:21:39 CDT(-0500)] <Bosmon> But still, the scale of the failure is quite startling

[11:32:30 CDT(-0500)] <colinclark> Justin_o: Do you think it would be reasonable to organize some kind of small day-long "Infusion tidy up" sprint in the next week or two?

[11:34:13 CDT(-0500)] <Bosmon> Justin_o - looks like the failure is due to the failure of our focusLightbox() function

[11:36:58 CDT(-0500)] <Justin_o> colinclark: that might be a good idea.. i guess we might need to collect a bunch of issues first though

[11:37:06 CDT(-0500)] <colinclark> Yeah, that makes sense

[11:37:35 CDT(-0500)] <Bosmon> It looks like this was done as a result of my fix for FLUID-4684

[11:38:09 CDT(-0500)] <Bosmon> Which is odd, because the purpose of the fix was to make the test cases pass again.....

[11:38:59 CDT(-0500)] <Justin_o> Bosmon: that seems strange.. these must have been run if that was the purpose of the fix

[11:39:34 CDT(-0500)] <Bosmon> Well, this is odd

[11:39:40 CDT(-0500)] <Bosmon> Reverting the change doesn't make them pass again.....

[11:58:54 CDT(-0500)] <Bosmon> The plot thickens... there seems to be something peculiarly wrong with the selectables plugin

[11:59:00 CDT(-0500)] <Bosmon> In that nothing seems to ever call "refresh" on it

[12:01:44 CDT(-0500)] <Justin_o> Bosmon: to distract you a bit, what grade would a component like this get https://github.com/fluid-project/infusion/blob/master/src/webapp/components/pager/js/Pager.js#L163

[12:02:06 CDT(-0500)] <Bosmon> No grade there

[12:02:25 CDT(-0500)] <Bosmon> That thing is something bizarre and malign : P

[12:02:30 CDT(-0500)] <Bosmon> And gets everything it deserves from the IoC system

[12:02:38 CDT(-0500)] <Bosmon> Anyway, it is never constructed via IoC

[12:02:44 CDT(-0500)] <Bosmon> You only need look at top-level Infusion components

[12:02:52 CDT(-0500)] <Justin_o> Bosmon: okay…

[12:02:55 CDT(-0500)] <Bosmon> So it seems we NEVER called "refresh" on the selectables

[12:03:05 CDT(-0500)] <Bosmon> This is rapidly getting into the "how did this ever work" territory....

[12:03:43 CDT(-0500)] <Bosmon> I'm wondering if my linting fix is involved somehow ....

[12:03:50 CDT(-0500)] <Bosmon> Somehow the keyboard-a11y tests pass by themselves

[12:06:35 CDT(-0500)] <Bosmon> Ok, nothing to do with that!

[12:06:46 CDT(-0500)] <Bosmon> Somehow, all the "movables" in the ImageReorderer test have the wrong CSS class on them

[12:07:01 CDT(-0500)] <Bosmon> .flc-reorderer-movable-default, rather than .flc-reorderer-movable

[12:08:45 CDT(-0500)] <Bosmon> Actually "fl-reorderer-movable-default"

[12:08:59 CDT(-0500)] <Bosmon> This name appears in ImageReordererTestConstants.js, but is never used..........

[12:18:20 CDT(-0500)] <Bosmon> Good grief

[12:18:25 CDT(-0500)] <Bosmon> It's a failure to do with defaults in graded options

[12:18:37 CDT(-0500)] <Bosmon> But I wonder when on earth it could have occurred

[12:19:46 CDT(-0500)] <Bosmon> I think I know!

[12:19:54 CDT(-0500)] <Bosmon> It was caused by the merge of ModelTransformations

[12:20:08 CDT(-0500)] <Bosmon> colinclark - remember that thing you queried... about the change in strategy for mergePolicies....

[12:20:24 CDT(-0500)] <colinclark> ?!

[12:20:51 CDT(-0500)] <colinclark> You mean when I was reviewing the latest version of ModelTransformations?

[12:20:56 CDT(-0500)] <Bosmon> Yes, exactly

[12:21:04 CDT(-0500)] <colinclark> Damn, I pushed failing unit tests

[12:21:11 CDT(-0500)] <Bosmon> You did!

[12:21:14 CDT(-0500)] <Bosmon> Yes...

[12:21:25 CDT(-0500)] <Bosmon> Although it would be hard to guess that there would be a failure so far away

[12:21:34 CDT(-0500)] <Bosmon> My work on "running all unit tests" becomes doubly as urgent....

[12:21:54 CDT(-0500)] <colinclark> Yeah, well

[12:21:59 CDT(-0500)] <colinclark> It still points out that I suck

[12:22:14 CDT(-0500)] <colinclark> There's no way anyone should be pushing anything to Infusion master without running the full test suite

[12:22:18 CDT(-0500)] <Bosmon> Actually the failure is in exactly the same bit of dodgy code I commented on to anastasiac in FLUID-4725

[12:22:19 CDT(-0500)] <colinclark> it's really not that hard to do

[12:22:36 CDT(-0500)] <colinclark> Literally the exact same code?

[12:22:49 CDT(-0500)] <colinclark> i.e. the improperly namespaced defaults?

[12:22:52 CDT(-0500)] <colinclark> in InlineEdit?

[12:22:52 CDT(-0500)] <Bosmon> No

[12:23:02 CDT(-0500)] <Bosmon> I JIRAed the problem separately as http://issues.fluidproject.org/browse/FLUID-4733

[12:23:05 CDT(-0500)] <Bosmon> Which is pretty ironic

[12:23:11 CDT(-0500)] <Bosmon> Given at the time I wrote this JIRA, this code had already failed

[12:23:17 CDT(-0500)] <Bosmon> But I highlighted it as an "implementation risk".....

[12:23:21 CDT(-0500)] <colinclark> oh this one

[12:23:22 CDT(-0500)] <colinclark> yes

[12:23:45 CDT(-0500)] <Bosmon> And the failure is in literally the exact part of the Reorderer's configuration that I quote here : P

[12:24:00 CDT(-0500)] <colinclark> Justin_o: I'm sorry for this, King.

[12:24:41 CDT(-0500)] <colinclark> Bosmon: You don't say specifically in FLUID-4733 how we might deal with this issue prior to tackling the much larger issue of FLUID-4392

[12:24:50 CDT(-0500)] <Bosmon> colinclark I didn't know

[12:24:55 CDT(-0500)] <Bosmon> er, I didn't, no

[12:24:57 CDT(-0500)] <Bosmon> hahaha

[12:24:59 CDT(-0500)] <colinclark>

[12:25:15 CDT(-0500)] <colinclark> Is it just a matter of rewriting the Reorderer's merge policy block somehow?

[12:25:15 CDT(-0500)] <Bosmon> But I guess also I didn't have a specific idea, beyond recognising that this code was inadequate

[12:25:30 CDT(-0500)] <Bosmon> Well, not really.... we need this policy to be able to work again

[12:25:38 CDT(-0500)] <Bosmon> And right now the mechanism for this is now broken

[12:25:40 CDT(-0500)] <colinclark> That's what I imagined, yes

[12:25:46 CDT(-0500)] <Bosmon> Just as well that anastasiac didn't yet take my advice on FLUID-4725

[12:26:09 CDT(-0500)] <Bosmon> This merge policy implementation was made right at the dawn of time

[12:26:16 CDT(-0500)] <Bosmon> Probably around the Infusion 0.6 mark

[12:26:46 CDT(-0500)] <Bosmon> Given that the only user of it is the Reorderer, and we have already decided that it is conceptually as well as implementationally broken, it might be a good time to rethink it

[12:27:30 CDT(-0500)] <Bosmon> Let's see for a start if we have ever documented it

[12:27:54 CDT(-0500)] <Bosmon> http://wiki.fluidproject.org/display/fluid/Options+Merging+for+Infusion+Components#OptionsMergingforInfusionComponents-StructureoftheMergePolicyObject

[12:27:56 CDT(-0500)] <Bosmon> Looks like we have

[12:28:02 CDT(-0500)] <Bosmon> It is listed under "any other string value"

[12:28:15 CDT(-0500)] <Bosmon> I guess this, for the time being, commits us to fixing it

[12:28:15 CDT(-0500)] <colinclark> To what extent can we fully rethink it without implementing FLUID-4392?

[12:28:29 CDT(-0500)] <colinclark> aha, backwards compatibility in this case

[12:28:44 CDT(-0500)] <Bosmon> Although it is rather crappy that this prevents people from using options with the names of "replace", "preserve" etc.

[12:28:53 CDT(-0500)] <Bosmon> They're unlikely to, but it is an egregrious fault

[12:29:03 CDT(-0500)] <colinclark> it's pretty clear that our contract is EL paths on the left

[12:29:08 CDT(-0500)] <colinclark> and the potential for EL paths on the right

[12:29:28 CDT(-0500)] <colinclark> alongside a few special names or a function

[12:30:14 CDT(-0500)] <Bosmon> I guess the KING would not permit us to reimplement this... but I guess we could implement an extension

[12:30:21 CDT(-0500)] <Bosmon> This stuff hugely predates model transformations, of course

[12:30:29 CDT(-0500)] <Bosmon> But it should really work in a way which is consistent with it

[12:30:46 CDT(-0500)] <Bosmon> The trouble is, the most frequently used merge policies are the ones which do NOT have EL paths on the RHS

[12:31:01 CDT(-0500)] <Bosmon> But being consistent with model transformations would imply it is those ones which have to become more verbose

[12:34:52 CDT(-0500)] <colinclark> yes, I see what you mean

[12:39:34 CDT(-0500)] <Bosmon> Justin_o, colinclark: http://issues.fluidproject.org/browse/FLUID-4736

[12:40:13 CDT(-0500)] <colinclark> Thanks, Bosmon

[12:40:19 CDT(-0500)] <colinclark> So what do you think our next step should be?

[12:40:35 CDT(-0500)] <Justin_o> Bosmon: thanks for filing that

[12:40:45 CDT(-0500)] <Bosmon> Justin_o, avtar - I'm wondering what the status of our testswarm installation is?

[12:40:56 CDT(-0500)] <Bosmon> It would be good to have a system that could alert us to problems like this earlier on

[12:41:01 CDT(-0500)] <colinclark> it really would

[12:41:07 CDT(-0500)] <Bosmon> colinclark - I will make a straightforward fix for the issue

[12:41:12 CDT(-0500)] <Bosmon> After thinking about it in the shower for a bit

[12:41:20 CDT(-0500)] <colinclark> Huge +1 for me on a reliable Testswarm configuration

[12:41:26 CDT(-0500)] <Justin_o> Bosmon: that's something that the jQuery testing team is working on.. there new strategy involves using jenkins to manage testswarm

[12:41:30 CDT(-0500)] <Bosmon> This last piece of mergeImpl probably just needs to be split off into a separate function

[12:41:32 CDT(-0500)] <colinclark> Bosmon: Do you know what the straightforward fix is?

[12:41:39 CDT(-0500)] <Bosmon> It was always a bit of an eyesore sitting there at the top level impl

[12:41:48 CDT(-0500)] <colinclark> Justin_o: I guess I'd like to get a better sense of what the needs are

[12:41:52 CDT(-0500)] <colinclark> So, put another way:

[12:42:00 CDT(-0500)] <colinclark> 1. What is the current status of our Testswarm instance?

[12:42:09 CDT(-0500)] <colinclark> 2. What prevents Testswarm from being used reliably?

[12:42:23 CDT(-0500)] <colinclark> 3. What sort of things do a) Avtar and b) we need to do to make it all happen?

[12:42:37 CDT(-0500)] <colinclark> I imagine you probably know the most about this issue, Justin_o

[12:43:01 CDT(-0500)] <colinclark> (and while you think about it, I'm going to sneak off quickly for a sandwich)

[12:43:10 CDT(-0500)] <Justin_o> colinclark: okay

[12:43:20 CDT(-0500)] <avtar> hi all

[12:44:07 CDT(-0500)] <Justin_o> colinclark: well we would need to have a consistent supply of machines/vms to run against it.. in the past i'd have to restart the browsers every so often as they'd start to choke after a while.. probably a memory issue.. but not sure..

[12:44:26 CDT(-0500)] <Justin_o> colinclark: we should probably also upgrade to the latest version and get an jenkins instance up and running

[12:44:41 CDT(-0500)] <avtar> Justin_o: how many VMs would you estimate are required?

[12:46:27 CDT(-0500)] <Justin_o> avtar: we'd need to be able to cover all of the current desktop browsers listed here

[12:46:28 CDT(-0500)] <Justin_o> http://wiki.fluidproject.org/display/fluid/Prior+Browser+Support

[12:47:10 CDT(-0500)] <Justin_o> although this chart would need to but updated for 1.5

[12:47:53 CDT(-0500)] <Justin_o> but anyways.. probably about 6 vm's/machines including something for mac os

[12:47:58 CDT(-0500)] <Justin_o> avtar: ^

[12:50:10 CDT(-0500)] <Justin_o> avtar: for jQuery they are using http://www.browserstack.com/ for their test environments.. not sure if there is something like that for us to use

[12:52:35 CDT(-0500)] <avtar> hrmm

[12:53:06 CDT(-0500)] <avtar> a os x vm running on kvm is something i'll have to look into

[12:53:57 CDT(-0500)] <Justin_o> avtar: okay, thanks

[12:55:22 CDT(-0500)] <avtar> brb, need to find food

[12:56:04 CDT(-0500)] <Justin_o> okay

[12:59:15 CDT(-0500)] <Bosmon> I guess it is actually illegal to automatically try to create new MacOS VMs : P

[13:02:18 CDT(-0500)] <Justin_o> Bosmon: they started to let you do this in Lion, provided both the host and VM were running Lion.. i suppose now that Mountain Lion is out this will carry forward

[13:02:33 CDT(-0500)] <Justin_o> Bosmon: by the way here's my pull request https://github.com/fluid-project/infusion/pull/228

[13:02:38 CDT(-0500)] <Bosmon> Thanks, Justin_o

[13:02:46 CDT(-0500)] <Justin_o> although I'm a bit unsure of the non-standard components

[13:03:55 CDT(-0500)] <Bosmon> Well, you need to verify 2 things

[13:04:03 CDT(-0500)] <Bosmon> It's not just enough to look at the initialisation function which is used

[13:04:08 CDT(-0500)] <Bosmon> The component also has to have the standard signature

[13:04:18 CDT(-0500)] <Bosmon> So, for example, "undoDecorator" doesn't count as a genuine littleComponent

[13:04:27 CDT(-0500)] <Bosmon> Since it has the options argument in the wrong place

[13:04:53 CDT(-0500)] <Bosmon> The main use we are making of the grade structure is actually to ensure that each component is supplied with an accurate "argMap"

[13:05:06 CDT(-0500)] <Bosmon> So actually that is more essential to check than which init function is used

[13:08:36 CDT(-0500)] <Justin_o> Bosmon: makes sense.. i was a bit confused by that one, because the function is called fluid.undoDecorator, but the defaults and init are against "undo"

[13:08:47 CDT(-0500)] <Bosmon> That is a bug

[13:09:27 CDT(-0500)] <Bosmon> Similar to the one raised against InlineEdit

[13:09:44 CDT(-0500)] <colinclark> avtar, Justin_o: Circling back to Testswarm now that I'm back, I guess realistically we need an OS X box serving as a "constant client" to Testswarm still.

[13:09:44 CDT(-0500)] <Justin_o> okay.. so i'll change that one up.. i think i looked at the signature for the rest, but i'll double check

[13:09:58 CDT(-0500)] <colinclark> At the moment, you have a box under your desk that sort of serves this purpose, is that right, Justin_o?

[13:11:11 CDT(-0500)] <Justin_o> colinclark: yep, that's correct.. although i only had a trial license for the virtualization software there.. i had been waiting for that site license to come through, but looks like that isn't possible anymore

[13:11:53 CDT(-0500)] <colinclark> Will VirtualBox work?

[13:24:04 CDT(-0500)] <Justin_o> colinclark: hard to tell.. i just upgraded my virutalbox and checked.. it only have options for mac os server, not sure if that will let you install the regular mac os or not… although there are a bunch of hits on google for how to get lion running on windows so i guess it should work one way or another… although i'd like to know if it was officially supported or not

[13:28:00 CDT(-0500)] <colinclark> Justin_o: Worst case, we'd be looking at 1 license of VMWare Fusion?

[13:28:14 CDT(-0500)] <Justin_o> colinclark: yep. that sounds about right

[13:28:22 CDT(-0500)] <colinclark> I think we can manage that, one way or another

[13:28:35 CDT(-0500)] <colinclark> Worst case, I'll give up my license for the good of the tests

[13:29:20 CDT(-0500)] <Justin_o> colinclark: okay.. so in general we should have the vm support / machines

[13:29:30 CDT(-0500)] <colinclark> cool

[13:46:43 CDT(-0500)] <Justin_o> Bosmon: i've updated the pull request, i've removed the change to undo.js

[14:18:22 CDT(-0500)] <Justin_o> Bosmon: i have a question about creating a component dynamically..

[14:18:37 CDT(-0500)] <Bosmon> Hi Justin_o - Just reviewing your request now

[14:18:44 CDT(-0500)] <Justin_o> Bosmon: thanks..

[14:18:45 CDT(-0500)] <Bosmon> How come it still only consists of one commit?

[14:18:52 CDT(-0500)] <Bosmon> Did you do some kind of github magic? : P

[14:19:59 CDT(-0500)] <Justin_o> Bosmon: yes.. i figured that it was a small enough change that i'd finally have a chance to try out using git reset to compact several commits down to one.. it was in that git article you sent out to the list a while ago

[14:20:14 CDT(-0500)] <Bosmon> fascinating

[14:20:20 CDT(-0500)] <Bosmon> But how did you fool the server?

[14:20:34 CDT(-0500)] <Bosmon> Given you had presumably already issued the pull request once with 1 commit

[14:21:08 CDT(-0500)] <Justin_o> Bosmon: yes.. well.. github is smart enough to not allow you to push that kind of thing back up.. since it will change what's there..

[14:21:35 CDT(-0500)] <Justin_o> Bosmon: but they let you delete those branches.. and when you put one back up with the same name.. the pull request doesn't care

[14:21:44 CDT(-0500)] <Bosmon> Oh, fascinating....

[14:22:00 CDT(-0500)] <Bosmon> I wonder what a pull request looks like that has had its branch deleted and not recreated

[14:22:13 CDT(-0500)] <Justin_o> Bosmon: i should have checked that

[14:22:37 CDT(-0500)] <Justin_o> i did the change pretty quick though.. since i had it all sorted out on my machine before changing it in github

[14:23:11 CDT(-0500)] <Bosmon> ok

[14:23:15 CDT(-0500)] <Bosmon> Your pull request looks good

[14:23:27 CDT(-0500)] <Bosmon> As far as I can see, you have not broken any more of the tests, in addition to the ones that are already broken : P

[14:24:33 CDT(-0500)] <Justin_o> Bosmon: that's good.. i tried them all too.. hopefully there's nothing hidden in those reorder ones

[14:25:31 CDT(-0500)] <Bosmon> Wow.... the pull request page updates by AJAX...

[14:25:37 CDT(-0500)] <Bosmon> It already knows that it is closed

[14:26:38 CDT(-0500)] <Justin_o> Bosmon: i think that was a pretty recent feature addition..

[14:27:19 CDT(-0500)] <Justin_o> Bosmon: the other thing i just noticed today, not sure how long it's been there, is that they make it easier for you to diff your branches.. new ui element there beside pull request

[14:27:36 CDT(-0500)] <Bosmon> Oh yes, I need to remember to try to use that

[14:27:41 CDT(-0500)] <Bosmon> You were going to ask about dynamic components?

[14:28:37 CDT(-0500)] <Justin_o> Bosmon: oh yes.. you might have some thoughts on this.. so what i need to do is add a tooltip that is basically an error message if a user enters something invalid into a text input… there are three of these in the form

[14:28:47 CDT(-0500)] <Justin_o> http://issues.fluidproject.org/secure/attachment/12577/Decapod+0.6+Export-14.png

[14:28:55 CDT(-0500)] <Justin_o> see the bottom

[14:29:00 CDT(-0500)] <Bosmon> Yes

[14:29:10 CDT(-0500)] <Bosmon> But I presume that no more than one of them may be visible at a time

[14:29:15 CDT(-0500)] <Bosmon> I suggest you use the same component for each one

[14:29:23 CDT(-0500)] <Bosmon> Tooltips are a classic "flyweight" use case

[14:29:48 CDT(-0500)] <Bosmon> If we could have our way, we would arrange it so that there is no more than one of them on an entire HTML page : P

[14:30:22 CDT(-0500)] <Justin_o> Bosmon: yes.. i think i remember you saying that when we were working on this for pager.. although in the end i think it creates a new one for each..

[14:30:27 CDT(-0500)] <Justin_o> could be wrong though…

[14:30:46 CDT(-0500)] <Bosmon> Yes... and a result of this, I suspect still creates a huge amount of DOM garbage

[14:30:52 CDT(-0500)] <Justin_o> yep

[14:30:58 CDT(-0500)] <Bosmon> As far as I'm aware, we never resolved the issue of it failing to clean up its DOM droppings

[14:31:29 CDT(-0500)] <Justin_o> Bosmon: we do destroy it on re-render, but don't know if that removes the dom elements it creates

[14:32:14 CDT(-0500)] <Justin_o> Bosmon: so what i was hoping to do would be to create the tooltip only when an invalid entry is made

[14:32:36 CDT(-0500)] <Bosmon> You can register it as a "createOnEvent" subcomponent

[14:33:03 CDT(-0500)] <Bosmon> But it might be simpler just to create it on startup

[14:33:07 CDT(-0500)] <Justin_o> Bosmon: also the tooltip should be removed if a valid entry is now made

[14:33:21 CDT(-0500)] <Bosmon> removed === hidden