fluid-work IRC Logs-2010-10-18

Owned by Fluid IRC Log Bot
Last updated: Oct 18, 2010Version comment
36 min read

[08:52:56 CDT(-0500)] <colinclark> mlam: I was just chatting offline with Justin_o about Inline Edit...
[08:53:01 CDT(-0500)] <colinclark> Should have been talking here in the channel
[08:53:11 CDT(-0500)] <mlam> ok
[08:53:19 CDT(-0500)] <colinclark> I was asking how close to completion we thought we were, and it sounds like it's looking pretty good
[08:54:15 CDT(-0500)] <mlam> Yah, we still need to find a resolution for long alt text
[08:54:27 CDT(-0500)] <colinclark> I'm thinking a next step is round up a few designers and have you and Justin do a walkthrough of the component
[08:54:38 CDT(-0500)] <colinclark> I'm hoping maybe jameswy and jhung have some time today, if you do
[08:54:55 CDT(-0500)] <colinclark> Hopefully we can do a walkthrough, double check our to-do list, and then check everything off
[08:54:55 CDT(-0500)] <mlam> Yes, I definitely have time today
[08:55:02 CDT(-0500)] <mlam> ok, sounds good
[08:55:07 CDT(-0500)] <colinclark> And then you can finally help me with Uploader!
[08:56:07 CDT(-0500)] <mlam> I took a look at the SWFUploadManagerTests.js, and I realized the reason why all the tests were failing was because a specific file didn't exist anymore. Aside from that, I didn't get very far with fixing the unit tests
[08:56:49 CDT(-0500)] <colinclark> mlam: Yep, that right
[08:57:06 CDT(-0500)] <colinclark> But it's not just a file... it's that there is no such thing as an "Upload Manager" anymore
[08:57:35 CDT(-0500)] <mlam> Ok, gotcha.
[08:57:46 CDT(-0500)] <colinclark> All of the really core logic related to both the demo and SWFUpload itself has been factored into a little object which, for lack of a name that doesn't suck, I simply called the Upload Engine
[08:58:17 CDT(-0500)] <colinclark> And it really just has a handful of the methods that you'd expect from something like SWFUpload (most are really just a wrapper around their horrible API), such as start(), stop(), and browseFiles()
[08:58:44 CDT(-0500)] <colinclark> The demo upload engine now basically just mocks up start() so that it doesn't actually invoke SWFUpload, but rather simulates all the events that SWFUpload would fire if it were talking to a server
[08:58:48 CDT(-0500)] <mlam> ahh ok, i'll take look
[08:58:59 CDT(-0500)] <colinclark> So those tests should be able to pass again fairly easily
[08:59:04 CDT(-0500)] <colinclark> One other thing I did, which is noteworthy
[08:59:30 CDT(-0500)] <colinclark> The demo upload manager used to have a very old-fashioned way of dealing with asynchronous testing, before QUnit really seemed to get much in the way of async support
[08:59:52 CDT(-0500)] <colinclark> I took that out of the code now that we know how to write those tests properly
[09:00:08 CDT(-0500)] <colinclark> I don't know if you've had a chance to look at asynchronous tests, but Golam
[09:00:13 CDT(-0500)] <colinclark> Golam's progress tests do it
[09:00:50 CDT(-0500)] <mlam> ok, i'll be sure to have golam show me his tests today
[09:00:55 CDT(-0500)] <colinclark> cool
[09:03:18 CDT(-0500)] <colinclark> jhung and jameswy: We're hoping you guys might have some time today to do a walkthrough with us of the recent Inline Edit changes
[09:03:38 CDT(-0500)] <jhung> colinclark: Sure. When?
[09:03:52 CDT(-0500)] <colinclark> I'm flexible--before 3 pm would be best for me
[09:04:01 CDT(-0500)] <jhung> I'm open as well.
[09:05:05 CDT(-0500)] <colinclark> justin_o, mlam: Do you guys have a preference for time?
[09:05:24 CDT(-0500)] <mlam> Any time is fine with me.
[09:05:25 CDT(-0500)] <justin_o> any time is fine
[09:05:47 CDT(-0500)] <colinclark> Okay, I vote sooner rather than later. We'll wait for jameswy to finish his meeting and then pick a time
[09:06:02 CDT(-0500)] <colinclark> mlam: Do you want to do a Skype code tour today of Uploader?
[09:06:20 CDT(-0500)] <colinclark> I'm going to work at home today to maximize my coding time, since I'll have to slip out at around 2:30 pm today
[09:08:02 CDT(-0500)] <mlam> Yah, for sure.
[09:08:35 CDT(-0500)] <mlam> I'm just looking through the uploader.js file right now
[09:08:45 CDT(-0500)] <mlam> would you want to do a quick 30 min tour right now?
[09:09:32 CDT(-0500)] <colinclark> mlam: Gimme twenty minutes or so?
[09:09:38 CDT(-0500)] <colinclark> jhung: The fruit returns!
[09:09:40 CDT(-0500)] <mlam> ok, for sure
[09:09:44 CDT(-0500)] <colinclark> Your image view demo looks great
[09:10:02 CDT(-0500)] <jhung> colinclark: we all need more servings of fruit.
[09:10:11 CDT(-0500)] <jhung> colinclark: thanks. Any feedback?
[09:10:17 CDT(-0500)] <colinclark> It should be quite straightforward to implement
[09:10:32 CDT(-0500)] <golam> colinclark: just saw your message..yes I will show mike our progress test cases that uses asyn test
[09:10:40 CDT(-0500)] <colinclark> great
[09:11:37 CDT(-0500)] <jhung> colinclark: cool. Will it be both you and anastasiac coding the demo?
[09:11:58 CDT(-0500)] <colinclark> jhung: Not likely to be me at this point, given the pressure of Uploader
[09:12:10 CDT(-0500)] <jhung> k
[09:12:16 CDT(-0500)] <colinclark> Quite possible michelled when she gets back from 'frisco
[09:13:20 CDT(-0500)] <colinclark> But I can certainly help out
[09:15:58 CDT(-0500)] <Bosmon> Hi there justin_o: There was a bit of cleanup work we had been talking about before, but didn't get around to making a JIRA for
[09:16:17 CDT(-0500)] <Bosmon> So, I was wondering whether you would think it is appropriate to do at this point in Bug Parade
[09:16:29 CDT(-0500)] <Bosmon> Some of the new functionality which we have put into the framework is poorly allocated between files
[09:16:53 CDT(-0500)] <Bosmon> There are some parts that have been thrown in to FluidIoC.js and others which got stuck in fluidParser.js, which relate to dealing with AJAX requests
[09:17:06 CDT(-0500)] <Bosmon> I think these would belong better consolidated into a single file, called "fluidRequests.js"
[09:18:12 CDT(-0500)] <colinclark> Bosmon: Are these all things that were added post-1.2?
[09:18:20 CDT(-0500)] <Bosmon> Some of them are
[09:18:23 CDT(-0500)] <Bosmon> Well, most of them
[09:18:53 CDT(-0500)] <Bosmon> The "old thing" is fluid.fetchResources, which whilst we had it before, has grown enormously during the 1.2 phase
[09:19:01 CDT(-0500)] <Bosmon> All of the other things, I think, are new
[09:19:40 CDT(-0500)] <colinclark> So this would require someone who was using fluid.fetchResources() previously to import a new file to have their code continue to work, right?
[09:19:45 CDT(-0500)] <Bosmon> That's correct
[09:20:40 CDT(-0500)] <Bosmon> Post-1.3, I guess this file would also make sense to put our "DataSource" stuff, once it had stabilised properly in CSpace
[09:21:06 CDT(-0500)] <justin_o> anastasiac: here is a start to the unit test page... needs a lot of work. I'm having a bit of trouble trying to think of how it should be structured... any thoughts http://wiki.fluidproject.org/display/docs/Writing+Unit+Tests
[09:21:43 CDT(-0500)] <justin_o> Bosmon: is fluidParser.js only used by the renderer at the moment?
[09:21:57 CDT(-0500)] <jhung> anastasiac: Do you have time today to talk about the keyboard a11y demo?
[09:22:02 CDT(-0500)] <Bosmon> Well... by the renderer, and anyone else who wants to use fetchResources (tongue)
[09:22:25 CDT(-0500)] <anastasiac> justin_o, your unit tests page looks like a great start - thanks!
[09:22:47 CDT(-0500)] <anastasiac> jhun, yes, let's talk about the demo this afternoon - anytime after 1:30?
[09:23:25 CDT(-0500)] <anastasiac> jhung: ^
[09:23:32 CDT(-0500)] <anastasiac> Bosmon, I was wondering about fetchResources - any thoughts on someday moving it into the framework proper? it seems quite useful even outside the context of the Renderer
[09:23:45 CDT(-0500)] <Bosmon> anastasiac: This is exactly what we are discussing, I think
[09:23:57 CDT(-0500)] <Bosmon> "fluidRequests.js" would be after this, considered part of the "framework proper"
[09:24:21 CDT(-0500)] * anastasiac should remember to catch up on the channel before chiming in
[09:24:39 CDT(-0500)] <Bosmon> also http://issues.fluidproject.org/browse/FLUID-3487 which is registered for Bug Parade
[09:24:48 CDT(-0500)] <Bosmon> I would like to address this by proposing a further framework file
[09:24:57 CDT(-0500)] <Bosmon> Which I can't think of a good name for off the top of my head
[09:25:12 CDT(-0500)] <Bosmon> But there is "some stuff" accumulating, currently in keyboard-a11y, which doesn't really belong there
[09:25:31 CDT(-0500)] <Bosmon> And deadMansBlur doesn't belong there either (tongue)
[09:25:48 CDT(-0500)] <Bosmon> This would be a file for "core framework things which require jQuery and a working DOM"
[09:26:01 CDT(-0500)] <jhung> anastasiac: sure. I'll ping you then.
[09:26:10 CDT(-0500)] <Bosmon> And I imagine we would also gradually start migrating things out of Fluid.js which didn't require a working DOM
[09:26:38 CDT(-0500)] <Bosmon> You may remember this was an annoyance that we met in the Kettle era, that the contents of Fluid.js are rather random with respect to this... but in fact are mostly DOM independent
[09:26:57 CDT(-0500)] <Bosmon> But deadMansBlur clearly falls into this category, and I think doesn't properly belong in Fluid.js
[09:28:11 CDT(-0500)] <Bosmon> So, other things of this kind in our keyboard-a11y "junkyard" are "fluid.enabled" and "fluid.getLastFocusedElement"
[09:30:57 CDT(-0500)] <Bosmon> Those 5 things in Fluid.js which are labelled "DOM Utilities" could also go in there... although we might well push that out to a future release
[09:31:23 CDT(-0500)] <jameswy> colinclark, jhung: Sorry for the late response! How about right after standup?
[09:32:10 CDT(-0500)] <justin_o> Bosmon: this is sounding a bit extensive
[09:32:28 CDT(-0500)] <Bosmon> Yes
[09:32:35 CDT(-0500)] <Bosmon> We needn't do it all now
[09:32:47 CDT(-0500)] <Bosmon> But I was trying to delineate the full extent of "file refactoring" that seemed to be pending to me
[09:32:55 CDT(-0500)] <justin_o> Bosmon: okay...
[09:34:15 CDT(-0500)] <justin_o> I'm not sure how much of a burden we want to place on our users with changing dependencies... is it better to do it all at once or gradually over time? And if it is better to do it all at once, should we be waiting for a major release...
[09:34:16 CDT(-0500)] <jhung> jameswy: Sure that's fine with me.
[09:34:35 CDT(-0500)] <justin_o> just to note we've made dependency changes in our last release
[09:34:54 CDT(-0500)] <Bosmon> What did we change?
[09:34:56 CDT(-0500)] <justin_o> jameswy, colinclark, mlam: after standup works for me as well
[09:35:04 CDT(-0500)] <mlam> same here
[09:35:07 CDT(-0500)] <justin_o> Bosmon: a bunch of jquery dependencies changed...
[09:35:24 CDT(-0500)] <Bosmon> I just removed the delegate plugin last night
[09:35:30 CDT(-0500)] <Bosmon> Which I guess counts as one for this release
[09:35:36 CDT(-0500)] <Bosmon> Which release version will be a major release?
[09:35:39 CDT(-0500)] <justin_o> ah ... that's a good point too
[09:37:34 CDT(-0500)] <justin_o> Bosmon: i suppose that would be 2.0, if we ever actually make one
[09:37:39 CDT(-0500)] <Bosmon> Oh, I see
[09:37:48 CDT(-0500)] <Bosmon> Well, I think we should definitely do all this stuff before then (tongue)
[09:37:53 CDT(-0500)] <justin_o> (smile)
[09:38:04 CDT(-0500)] <Bosmon> In that case there seems to be no reason to do it for any one release rather than any other
[09:38:37 CDT(-0500)] <justin_o> Bosmon: right, so my question would be then do we want to do it all at once or gradually....
[09:38:42 CDT(-0500)] <Bosmon> Right
[09:39:02 CDT(-0500)] <Bosmon> Well, I guess it is hard to plan for "all" this stuff at once, although I have tried to list everything I can think of
[09:39:07 CDT(-0500)] <justin_o> I think if I were a user I'd rather only have to make changes once, rather than every time I upgrade
[09:39:19 CDT(-0500)] <Bosmon> Things always happen over time as new functionality is invented
[09:39:36 CDT(-0500)] <justin_o> that's true
[09:39:42 CDT(-0500)] <Bosmon> Since "FluidIoC.js" will be totally new in this release anyway, you could say that that is what is causing it
[09:40:27 CDT(-0500)] <justin_o> Okay, but should we be moving production code because of sneak peek code
[09:40:59 CDT(-0500)] <Bosmon> That's a good point
[09:41:14 CDT(-0500)] <Bosmon> Although you could say that by the time the sneak peek code becomes production, it might be too late (tongue)
[09:41:30 CDT(-0500)] <Bosmon> People will have "got used to the old layout" whilst they were waiting
[09:43:26 CDT(-0500)] <justin_o> That's also a good point...
[09:43:41 CDT(-0500)] <justin_o> colinclark, anastasiac and others: any thoughts on this
[09:46:28 CDT(-0500)] <anastasiac> Justin_o, Bosmon: it's a difficult question. Moving a production function from one file to another will require users to modify their dependencies (unless they're using a concatenated file). It's not really a loss of backward compatibility, since their code will still work, but it is more work than we would like to impose on them
[09:46:59 CDT(-0500)] <anastasiac> Requiring such changes at a 2.0 release certainly seems much more reasonable
[09:47:41 CDT(-0500)] <Bosmon> yes - although I believe we can't forsee a 2.0 release any time within the next year?
[09:47:56 CDT(-0500)] <colinclark> I hope we don't get to a 2.0 release for quite awhile, ideally
[09:48:15 CDT(-0500)] <anastasiac> Bosmon, that's a good point - and between now and then I'm sure more such changes will come in - which will make the task quite large
[09:48:41 CDT(-0500)] <anastasiac> also, we're already introducing changes that we "shouldn't" be in a point release: api changes, etc.
[09:48:44 CDT(-0500)] <Bosmon> I would hope that most of our users are using our Builder
[09:48:50 CDT(-0500)] <Bosmon> Rather than assembling dependencies manually
[09:49:20 CDT(-0500)] <anastasiac> Does our downloadable bundle come with a FluidAll.js included?
[09:49:29 CDT(-0500)] <colinclark> yes
[09:49:45 CDT(-0500)] <colinclark> anastasiac: Can you give us an overview of the API changes we're making for 1.3?
[09:50:03 CDT(-0500)] <colinclark> That is, not additions--only API modifications or subtractions
[09:50:36 CDT(-0500)] <anastasiac> colinclark, that's on my to-do list already. I was going to hold off until I was sure no more changes were coming, but this does seem like a good time
[09:50:46 CDT(-0500)] <anastasiac> give me a few minutes to put it together in a readable form
[09:50:56 CDT(-0500)] <colinclark> Just off the top of your head is fine
[09:52:02 CDT(-0500)] <anastasiac> progress: existing string options moved into a strings bundle - I don't think any backward compatibility has been implemented (Justin_o can confirm)
[09:52:27 CDT(-0500)] <colinclark> jameswy, mlam, justin_o, jhung: after standup works for me
[09:52:31 CDT(-0500)] <colinclark> jessm: Do you want to join us as well?
[09:52:39 CDT(-0500)] <jessm> colinclark: yes!
[09:53:26 CDT(-0500)] <anastasiac> inline edit: new button renderer; new, but I
[09:53:46 CDT(-0500)] <anastasiac> I'm not sure whether or not that might break older versions - mlam, Justin_o - comments?
[09:54:49 CDT(-0500)] <Bosmon> You could say that some of my changes to the core framework would "break backwards compatibility" in some corner cases
[09:54:55 CDT(-0500)] <Bosmon> We found some of that in InlineEdit for example
[09:55:19 CDT(-0500)] <mlam> anastasiac: we shouldn't be breaking older versions of inline edit. only additions to the API were made... a couple new styles, selectors and strings
[09:55:26 CDT(-0500)] <Bosmon> It used to be that trying to create a View component with a nonexistent container would actually construct something
[09:55:30 CDT(-0500)] <Bosmon> Now it constructs nothing
[10:02:03 CDT(-0500)] <anastasiac> hm... progress isn't actually production yet. it's not sneak peek, but it's not production either, so I suppose the loss of backward compatibility isn't that bad...
[10:03:19 CDT(-0500)] <Bosmon> We discovered that "undo" was actually relying on this corner behaviour and broke... it believed that it could construct itself without a container and then put in the container afterwards
[10:03:53 CDT(-0500)] <Bosmon> It was a pretty crazy world we had before there was any IoC (tongue)
[10:04:55 CDT(-0500)] <justin_o> anastasiac: yes... since progress is not a production component i think it should be okay
[10:09:43 CDT(-0500)] <colinclark> Uploader will be in the same boat as Progress
[10:10:10 CDT(-0500)] <colinclark> Though I think we can "chew" its options for at least 90% backwards compatibility
[10:10:58 CDT(-0500)] <Bosmon> I guess "options chewing machinery" will be an important upcoming framework feature
[10:11:02 CDT(-0500)] <justin_o> colinclark, anastasiac, Bosmon: here's the component status definitions http://wiki.fluidproject.org/display/fluid/Component+Status
[10:11:14 CDT(-0500)] <Bosmon> I suspect we will use a "lensing syntax" very similar to the one you made during those last few days of Engage
[10:11:44 CDT(-0500)] <colinclark> Bosmon: That was my thinking as well
[10:12:48 CDT(-0500)] <colinclark> A set of declarative rules about how to map one model (in this case, the component's options) to another structure
[10:13:47 CDT(-0500)] <colinclark> mlam: Let's do Uploader code tour immediately after our meeting immediately after standup
[10:13:49 CDT(-0500)] <colinclark> (tongue)
[10:13:58 CDT(-0500)] <mlam> (smile)
[10:14:00 CDT(-0500)] <mlam> ok
[10:14:02 CDT(-0500)] <Bosmon> colinclark: What is in released uploaded that is new?
[10:14:10 CDT(-0500)] <Bosmon> I assume your IoC-ified version is still experimental?
[10:14:21 CDT(-0500)] <Bosmon> uploader
[10:14:22 CDT(-0500)] <colinclark> quite, but i'm optimistic that it will be baked by 1.3
[10:14:28 CDT(-0500)] <Bosmon> !
[10:14:28 CDT(-0500)] <colinclark> If this week goes well (wink)
[10:14:43 CDT(-0500)] <Bosmon> Doesn't code freeze come on Wednesday?
[10:14:51 CDT(-0500)] <Bosmon> ok, I will be excited to join your Tour
[10:14:51 CDT(-0500)] <colinclark> Is it that soon, justin_o
[10:14:53 CDT(-0500)] <colinclark> ?
[10:16:07 CDT(-0500)] <justin_o> colinclark: yep
[10:16:13 CDT(-0500)] <colinclark> WOWZA
[10:16:18 CDT(-0500)] <colinclark> I also do this (tongue)
[10:17:06 CDT(-0500)] <justin_o> colinclark: yes... it's warp speed on uploader and reorderer to make code freeze
[10:17:18 CDT(-0500)] <colinclark> When I say "also," I mean "always"
[10:17:23 CDT(-0500)] <colinclark> ok, warp speed it is
[10:17:35 CDT(-0500)] <Bosmon> I should be on hand to help out a bit
[10:17:46 CDT(-0500)] <Bosmon> So, did we get any consensus on our file reorganization issue?
[10:18:08 CDT(-0500)] <Bosmon> It sounds like I can read out of the discussion, that we should "do as much as possible, as soon as possible"? (tongue)
[10:18:09 CDT(-0500)] <justin_o> Bosmon: i don't think so...
[10:18:12 CDT(-0500)] <colinclark> Bosmon: I think the Reorderer crew, in particular, could use a hand. I figure we're not going to get it all done, but at least hard stops would be nice
[10:18:20 CDT(-0500)] <colinclark> Okay, so can we reiterate where we were at?
[10:18:37 CDT(-0500)] <colinclark> The question, largely, is if we feel okay doing file-level restructuring for a point release, is that right, justin_o?
[10:18:43 CDT(-0500)] <justin_o> Bosmon: my answer was to your previous question
[10:19:13 CDT(-0500)] <justin_o> colinclark: mostly... although we have done some for other point releases... so it may be more along the lines of what and how much
[10:19:18 CDT(-0500)] <colinclark> ok
[10:24:13 CDT(-0500)] <colinclark> Okay, so Bosmon2, can you just reiterate, really briefly, the extent of the changes you're proposing for this particular release?
[10:24:27 CDT(-0500)] <colinclark> As justin_o mentioned, your original list seemed extensive
[10:24:31 CDT(-0500)] <colinclark> because you were listing everything
[10:24:40 CDT(-0500)] <Bosmon2> Yes
[10:24:42 CDT(-0500)] <colinclark> Is there a more scoped set of changes that you think are a priority for this release?
[10:24:51 CDT(-0500)] <golam> anastasiac: We have deprecated callback property in hideAnimation and showAnimation objects and in the progress component API document where would you want me to comment?
[10:25:05 CDT(-0500)] <Bosmon2> Well, I think the parts that I mainly considered optional was the relocation of the 5 "DOM-dependent" functions within Fluid.js
[10:25:35 CDT(-0500)] <Bosmon2> So, my proposal was i) to create fluidRequests.js to accommodate fluid.fetchResources from fluidParser.js and the deferredFetchExpander from fluidIoC.js
[10:26:10 CDT(-0500)] <Bosmon2> ii) an as yet unnamed file to accommodate the deadMansBlur from InlineEdit.js as well as lastFocusedElement and fluid.enabled from keyboard-a11y.js
[10:26:17 CDT(-0500)] <golam> anastasiac: http://wiki.fluidproject.org/display/fluid/Progress+API
[10:26:24 CDT(-0500)] <anastasiac> golam, I'd say on in the documentation, put a "Deprecated in v1.3" comment on those properties. I think we have some other deprecated things, that we used a "strikethrough" style for...
[10:26:42 CDT(-0500)] <Bosmon2> And then I suggested that iii) the 5 functions in Fluid.js which are commented as DOM-related could also be moved into this new file
[10:27:21 CDT(-0500)] <golam> anastasiac: strikethrough style doesn't work when its inside the code block
[10:27:55 CDT(-0500)] <Bosmon2> anastasiac: has deadMansBlur ever been documented as part of the framework?
[10:50:58 CDT(-0500)] <colinclark> mlam, jameswy, jhung: Let's do our walkthrough in Connect, since we might want to do some screen sharing
[10:51:09 CDT(-0500)] <jhung> okay
[10:51:13 CDT(-0500)] <jameswy> colinclark: alrighty
[10:52:26 CDT(-0500)] <colinclark> Bosmon2: We'll be distracted for a few minutes with a design walkthrough of Inline Edit
[10:52:35 CDT(-0500)] <colinclark> But my first thought about file-level restructuring...
[10:53:03 CDT(-0500)] <colinclark> if harriswong and cindy are close to having a solid Builder release for 1.3, that takes away a lot of users' pain in regards to such restructuring
[10:53:16 CDT(-0500)] <Bosmon2> yes
[10:53:29 CDT(-0500)] <colinclark> Indeed, users of the Builder shouldn't even notice file-level changes at all
[10:54:46 CDT(-0500)] <anastasiac> Bosmon2: deadMansBlur was never documented as part of the framework because it is not part of the framework
[10:56:04 CDT(-0500)] <Bosmon2> So, if, for example, I changed its API completely, this wouldn't create too much of a problem? (tongue)
[10:56:16 CDT(-0500)] <colinclark> justin_o: Can we check in with harris and cindy today to make a list of next steps with the Builder and assess if we're as close to the release as it seems from the tasking page?
[10:56:19 CDT(-0500)] <anastasiac> golam, I see what you're saying about strikethrough in code blocks... I guess we can just make a particular note in the Values column, perhaps, about the deprecated values
[10:56:29 CDT(-0500)] <justin_o> colinclark: sure
[10:56:37 CDT(-0500)] <colinclark> Bosmon2: I believe it's essentially private at the moment, so it should be fine, assuming you can keep everything working
[10:56:41 CDT(-0500)] <golam> anastasiac: ok I will
[10:56:42 CDT(-0500)] <anastasiac> Bosmon2: :_)
[10:56:44 CDT(-0500)] <Bosmon2> ok, that's cool
[10:56:50 CDT(-0500)] <colinclark> Didn't yura_ have a deadMansBlur() patch in CSpace recently?
[10:56:54 CDT(-0500)] <colinclark> I don't know if it's related
[10:56:55 CDT(-0500)] <Bosmon2> yes
[10:56:58 CDT(-0500)] <Bosmon2> It is related
[10:57:10 CDT(-0500)] <colinclark> jessm, justin_o Walkthrough in Connect
[10:57:13 CDT(-0500)] <Bosmon2> but CSpace is currently in branch for release mode
[10:57:19 CDT(-0500)] <Bosmon2> So the work is "temporarily decoupled"
[10:57:25 CDT(-0500)] <justin_o> colinclark: i'm there
[10:57:38 CDT(-0500)] <Bosmon2> That is, they will not be in a position to take advantage of changes in Infusion for a little while
[10:58:22 CDT(-0500)] <Bosmon2> But its related, in that it has suggested to me what the new API for deadMansBlur should be
[10:59:38 CDT(-0500)] <colinclark> ok
[11:00:06 CDT(-0500)] <colinclark> anastasiac: So, we are correct in assuming that deadMansBlur() is currently undocumented and unsupported, and thus we are able to change it freely?
[11:00:16 CDT(-0500)] <colinclark> There's certainly a JIRA for it on bug parade (smile)
[11:01:02 CDT(-0500)] <golam> anastasiac: please let me know if you like the changes http://wiki.fluidproject.org/display/fluid/Progress+API
[12:32:05 CDT(-0500)] <Bosmon2> So, colinclark, anastasiac, justin_o... any ideas for this "new framework file" name?
[12:32:21 CDT(-0500)] <Bosmon2> Not that we've committed to making it, but I wanted to get the juices flowing on thinking...
[12:32:27 CDT(-0500)] <Bosmon2> I can't really think of a good name
[12:32:39 CDT(-0500)] <colinclark> justin_o: I'll send out a summary of our Inline Edit meeting to the list
[12:32:39 CDT(-0500)] <Bosmon2> Something like "fluidClient.js" or "fluidDOM.js"... "fluidDocument.js"
[12:32:44 CDT(-0500)] <colinclark> If you can help JIRAfy, that would be awesome
[12:32:46 CDT(-0500)] <Bosmon2> Unfortunately "fluidDOMUtilities.js" is taken already
[12:32:52 CDT(-0500)] <Bosmon2> And anyway we hate names with "Utilities" in (tongue)
[12:32:56 CDT(-0500)] <colinclark> Indeed
[12:32:59 CDT(-0500)] <jhung> ping anastasiac
[12:33:07 CDT(-0500)] <anastasiac> Bosmon2, how would this file differ from the current FluidDOMUtilities?
[12:33:13 CDT(-0500)] <anastasiac> jhung: polo
[12:33:27 CDT(-0500)] <Bosmon2> anastasiac: FluidDOMUtilities really are utilities.... for the DOM (tongue)
[12:33:29 CDT(-0500)] <jhung> (smile) Let me know when you're clear to chat.
[12:33:31 CDT(-0500)] <mlam> colinclark: is our uploader meeting off for now?
[12:33:38 CDT(-0500)] <colinclark> Although I was going to float the notion of putting all this stuff into the DOMUtilities file, even though I hate anything named "utilities," because it implies a lack of design consideration
[12:33:47 CDT(-0500)] <colinclark> mlam: Let me straighten out my calendar for a sec
[12:33:50 CDT(-0500)] <Bosmon2> That is, they assist with raw DOM manipulation and traversal, in cases where jQuery is either unperformant or incomplete
[12:33:56 CDT(-0500)] <mlam> ok
[12:33:58 CDT(-0500)] <colinclark> Another Jutta thingy came up, mlam
[12:34:04 CDT(-0500)] <colinclark> But we need to do this sometime today
[12:34:08 CDT(-0500)] <colinclark> i'll ping you
[12:34:11 CDT(-0500)] <Bosmon2> Whereas these things are properly semantic things in the DOM, using jQuery, and will be a required dependence for almost everyone
[12:34:17 CDT(-0500)] <mlam> ok, i'll eat really quickly
[12:34:20 CDT(-0500)] <justin_o> Bosmon2: how about DeadMansChest since it will be holding his blur (tongue)
[12:34:31 CDT(-0500)] <Bosmon2> FluidDOMUtilities consists of some fairly esoteric stuff that are used only in places like the Reorderer etc.
[12:34:32 CDT(-0500)] <anastasiac> Bosmon2, would this new file be dom related, but less 'utilitarian'?
[12:35:05 CDT(-0500)] <anastasiac> perhaps "FluidDOM.js" ?
[12:35:10 CDT(-0500)] <Bosmon2> anastasiac: The distinction I was trying to make is that this assists people primarily who are in browsers... as opposed to core "Fluid.js" which we imagine will generally fill up with stuff that would be useful on the server too
[12:35:30 CDT(-0500)] <anastasiac> hm...
[12:35:58 CDT(-0500)] <anastasiac> jhung, how about in a few minutes? boz has me thinking filenames right now (smile)
[12:36:05 CDT(-0500)] <jhung> sure
[12:36:13 CDT(-0500)] <jhung> anastasiac: let me know when.
[12:36:37 CDT(-0500)] <anastasiac> complete brainstorming:
[12:36:39 CDT(-0500)] <Bosmon2> Of course, if we were to do this 100% down the line, this would radically mean moving even fluid.initView into there
[12:36:50 CDT(-0500)] <Bosmon2> Which then suggests something like "fluidViews.js" (tongue)
[12:36:51 CDT(-0500)] <anastasiac> FluidClient, FluidFrontEnd
[12:36:53 CDT(-0500)] <Bosmon2> or "fluidView.js"
[12:37:11 CDT(-0500)] <colinclark> As a slight aside, this starts to point towards the need for us to properly name and namespace files
[12:37:28 CDT(-0500)] <colinclark> But I'd be willing to leave that one for 1.5
[12:37:33 CDT(-0500)] <anastasiac> or, could we move the 'server'-like stuff into something with a new name? keep Fluid.js for the client stuff?
[12:37:33 CDT(-0500)] <justin_o> Bosmon2: should that stuff in FluidDomUtilities be moved to the reorderer?
[12:37:38 CDT(-0500)] <colinclark> fluid-core.js, fluid-uploader.js, etc
[12:37:48 CDT(-0500)] <anastasiac> FluidServer, FluidBackEnd
[12:38:09 CDT(-0500)] <anastasiac> fluid-core, that's good
[12:38:11 CDT(-0500)] <colinclark> I don't think we'd want to call anything that lived in the client by the name "server"
[12:38:20 CDT(-0500)] <anastasiac> no, I know - just brainstorming
[12:38:22 CDT(-0500)] <colinclark> nor "backend," for similar considerations
[12:38:35 CDT(-0500)] <Bosmon2> "core" is promising but I think in the end ambiguous
[12:38:47 CDT(-0500)] <Bosmon2> If anything is "core" it is the existing contents of Fluid.js....
[12:38:53 CDT(-0500)] <anastasiac> it might be less ambiguous if we changed fluid.js to something more specific
[12:39:01 CDT(-0500)] <colinclark> yes, that's exactly what I was implying, Bosmon2
[12:39:29 CDT(-0500)] <Bosmon2> colinclark: anything special about 1.5?
[12:39:36 CDT(-0500)] <Bosmon2> What are we planning for 1.4?
[12:39:52 CDT(-0500)] <colinclark> Bosmon2: Check the wiki
[12:40:00 CDT(-0500)] <colinclark> lemme grab you the link
[12:40:13 CDT(-0500)] <colinclark> This is justin_o's last draft of the 1.3-1.5 roadmap
[12:40:13 CDT(-0500)] <colinclark> http://wiki.fluidproject.org/display/fluid/Infusion+1.3+-+1.5+Roadmap
[12:40:21 CDT(-0500)] <anastasiac> jhung, ok - I'm just reviewing your email, with the description of the demo...
[12:40:31 CDT(-0500)] <Bosmon2> thanks
[12:41:05 CDT(-0500)] <Bosmon2> ok, any reason you thought 1.5 would be a better time for naming and namespacing?
[12:41:30 CDT(-0500)] <colinclark> no, it was sort of random
[12:41:37 CDT(-0500)] <colinclark> seemed like a nice number for something big like that
[12:41:53 CDT(-0500)] <colinclark> plus i think we'll still be focussing on polishing new framework features + a11y for 1.4
[12:42:07 CDT(-0500)] <Bosmon2> My new TOASTER is pretty awesome and so far has not set fire to anything
[12:42:23 CDT(-0500)] <colinclark> (smile)
[12:43:08 CDT(-0500)] <colinclark> So far, FluidDOM.js is the only one that strikes me... but the implication that more will move in here, beyond just the scope of the DOM, is problematic
[12:43:20 CDT(-0500)] <colinclark> And then I keep cycling back to the notion that everything needs to be renamed
[12:43:24 CDT(-0500)] <colinclark> Which we really can't afford for this release
[12:43:26 CDT(-0500)] <Bosmon2> You don't like "fluidView.js"?
[12:44:05 CDT(-0500)] <colinclark> Well, I guess as a user I'd ask why things like fluid.initView() and all of that related code weren't in there, too
[12:44:13 CDT(-0500)] <anastasiac> jhung, shall we hop on skype?
[12:44:16 CDT(-0500)] <colinclark> But I'm not sure we want to do a complete reorg
[12:47:41 CDT(-0500)] <Bosmon2> Ok, so to create fluidDOM.js as a kind of temporary holding place, that we imagine will disappear within a release or two?
[12:47:49 CDT(-0500)] <Bosmon2> What more things do we fear might move in here?
[12:49:11 CDT(-0500)] <colinclark> Bosmon2: Give me a minute or two here
[12:49:18 CDT(-0500)] <colinclark> I'm triple tasking and it sucks
[12:49:35 CDT(-0500)] <colinclark> So, Bosmon2, is your idea to introduce FluidViews.js, but not put everything in it right away?
[12:50:04 CDT(-0500)] <colinclark> In other words, move the DOM-related stuff into it now, and eventually break off some of the client-side specific code related to views into it later?
[12:50:08 CDT(-0500)] <colinclark> Or move everything now?
[12:52:57 CDT(-0500)] <Bosmon2> Well, either, really
[12:53:12 CDT(-0500)] <colinclark> Do you have any preference?
[12:53:14 CDT(-0500)] <Bosmon2> I'm not sure I have a strong opinion about when exactly "very core" things get into FluidViews.js
[12:53:29 CDT(-0500)] <Bosmon2> But right now I need somewhere to put deadMansBlur and some various "not very core" things
[12:53:45 CDT(-0500)] <Bosmon2> Well, I guess my preference would just be to fix up everything we can think of as coming up right now
[12:53:57 CDT(-0500)] <Bosmon2> That is, to do the most aggressive factoring that we are sure makes sense
[12:54:31 CDT(-0500)] <colinclark> ok
[12:54:44 CDT(-0500)] <Bosmon2> But I guess I'm also ok with deferring stuff like moving initView if people aren't comfortable with that right now
[12:54:46 CDT(-0500)] <colinclark> So, in this category of stuff: "deadMansBlur and some various "not very core" things"
[12:54:58 CDT(-0500)] <colinclark> how much of this code is not optional for most components and users?
[12:55:22 CDT(-0500)] <Bosmon2> Let me get my thinking cap on.... "not optional for most"
[12:55:29 CDT(-0500)] <Bosmon2> I always have trouble parsing sentences like that (tongue)
[12:55:37 CDT(-0500)] <colinclark> Yes, it's poorly phrased
[12:55:41 CDT(-0500)] <colinclark> So, for example, initView is really a central piece of machinery
[12:55:44 CDT(-0500)] <colinclark> Without it, no component works
[12:56:11 CDT(-0500)] <colinclark> Whereas, I believe, deadMansBlur() is something that is not currently used by most components
[12:56:18 CDT(-0500)] <colinclark> This argues for them being in separate files, always
[12:56:19 CDT(-0500)] <Bosmon2> right
[12:56:50 CDT(-0500)] <Bosmon2> Although that argument if followed strongly would lead us to have many more files than we have now...
[12:57:03 CDT(-0500)] <colinclark> indeed, which isn't perhaps such a bad thing, particularly with the Builder
[12:57:09 CDT(-0500)] <colinclark> So, "core" will always need to be core, if you know what I mean
[12:57:13 CDT(-0500)] <colinclark> Even if there will be multiple cores
[12:57:20 CDT(-0500)] <colinclark> core core and view core
[12:57:27 CDT(-0500)] <colinclark> these are not names I'm proposing, for the record (tongue)
[12:58:17 CDT(-0500)] <colinclark> mlam: I resolved my scheduling dilemma this afternoon
[12:58:33 CDT(-0500)] <Bosmon2> Well, colinclark - let's pick a more tricky example, to muddy the waters a bit
[12:58:34 CDT(-0500)] <Bosmon2> "fluid.enabled"
[12:58:45 CDT(-0500)] <Bosmon2> Is currently defined in keyboard-a11y, which is really sort of inappropriate
[12:58:45 CDT(-0500)] <colinclark> I'm not leaving early to take the sail off the boat, which means I have time to Upload with you after my meeting with Jutta, probably at 3 pm if that works for you
[12:58:58 CDT(-0500)] <Bosmon2> BUT, at the time of writing, it is not used anywhere else in the framework except in keyboard-a11y
[12:59:07 CDT(-0500)] <Bosmon2> However, we expect this to change pretty quickly in future releases
[12:59:12 CDT(-0500)] <mlam> ok, works for me.
[12:59:19 CDT(-0500)] <colinclark> Bosmon2: yes, that's a good example
[12:59:34 CDT(-0500)] <Bosmon2> So... this is one of the other "junk things" that I want to put into this "new file"
[12:59:36 CDT(-0500)] <colinclark> And we certainly have the ability, with the builder, do define modules that include multiple files
[12:59:39 CDT(-0500)] <mlam> colinclark: i have to leave at 5 today. will 2 hrs be sufficient?
[12:59:46 CDT(-0500)] <colinclark> mlam: Definitely
[12:59:48 CDT(-0500)] <mlam> ok, cool
[13:00:14 CDT(-0500)] <colinclark> In so much as on can learn all about a big component in any reasonably finite amount of time, mlam (tongue)
[13:00:29 CDT(-0500)] <colinclark> Bosmon2: This is making my head spin
[13:00:31 CDT(-0500)] <mlam> (smile)
[13:00:34 CDT(-0500)] <colinclark> Next step
[13:00:42 CDT(-0500)] <colinclark> Make a list of things that you want to put into this file now
[13:00:56 CDT(-0500)] <Bosmon2> i) deadMans'Blur, ii) fluid.enabled, iii) fluid.getLastFocusedElement
[13:00:57 CDT(-0500)] <colinclark> And a separate list of other things that you think need to move around in the somewhat longer term
[13:01:12 CDT(-0500)] <Bosmon2> other things: iv) ALL contents of fluid.js that make reference to the DOM
[13:01:40 CDT(-0500)] <colinclark> okay, so we need to break iv) down
[13:01:47 CDT(-0500)] <colinclark> into things that reasonably are totally foundational
[13:01:56 CDT(-0500)] <colinclark> and things that are generally optional
[13:02:17 CDT(-0500)] <Bosmon2> Well... I believe that each single thing in iv) would make most of the framework break if it were not references
[13:02:22 CDT(-0500)] <Bosmon2> referenced
[13:02:29 CDT(-0500)] <Bosmon2> We already slimmed down FLuid.js pretty aggressively
[13:03:00 CDT(-0500)] <Bosmon2> To break it down, iv) consists of two categories, iv) a), 5 or so methods relating to finding things, like fluid.byId, fluid.jByID etc., and b) initView and dependent code
[13:03:32 CDT(-0500)] <Bosmon2> I don't think we have anything in Fluid.js any more that we could count as "generally optional"
[13:10:14 CDT(-0500)] <Bosmon2> I guess a subissue here was that we had this "historical idea" that all the contents of keyboard-a11y were things that we intended to contribute to jQuery
[13:10:25 CDT(-0500)] <Bosmon2> Which is why it is getting a little "full of junk"
[13:10:51 CDT(-0500)] <Bosmon2> I think the idea is that keyboard-a11y is intended to stay working even in the absence of any of the core framework, although I doubt we have tested this recently
[13:11:37 CDT(-0500)] <Bosmon2> Well, I guess our demos implicitly test it
[13:18:58 CDT(-0500)] <Bosmon2> I guess this policy of making dependencies of keyboard-a11y self-contained is getting pretty annoying
[13:19:24 CDT(-0500)] <Bosmon2> Anything that we put in there that might conceivably be depended on by anything else in the framework then really belongs in its own file
[13:19:32 CDT(-0500)] <Bosmon2> And this therefore implies we need THREE new files, not two
[13:20:59 CDT(-0500)] <Bosmon2> The unfortunate result of all of this seems to be implying that fluid.deadMansBlur belongs in its own file together with absolutely nothing else
[13:21:13 CDT(-0500)] <Bosmon2> Assuming we are going to be properly aggressive about locating dependencies in their own files
[13:27:38 CDT(-0500)] <jhung> justin_o: Added new issue for screen reader testing of Inline Edit. http://issues.fluidproject.org/browse/FLUID-3805
[13:32:19 CDT(-0500)] <justin_o> jhung: thanks
[14:02:40 CDT(-0500)] <jhung> justin_o, mlam: just a heads up. IE8 with simple edit has a few issues.
[14:03:07 CDT(-0500)] <mlam> what's wrong?
[14:04:44 CDT(-0500)] <jhung> So far: graphic not appearing for the buttons. Tooltip position for edit mode appears in a wrong location. Edit text is being cached - previous edits are appearing in Edit mode even if the demo was refreshed.
[14:07:27 CDT(-0500)] <justin_o> jhung: that's a lot
[14:07:28 CDT(-0500)] <jhung> also some weirdness in what's being read by by NVDA. i.e. after editing, NVDA would say "Inline edit document. Inline Edit document. <new edit text> edit blank."
[14:07:51 CDT(-0500)] <justin_o> jhung: that is wierd
[14:08:06 CDT(-0500)] <justin_o> jhung: can you try out the 1.2.1 demo and see if you get the same thing
[14:08:17 CDT(-0500)] <jhung> okay.
[14:09:48 CDT(-0500)] <justin_o> jhung: http://fluidproject.org/releases/1.2.1/demos/inlineEdit/simple/html/inlineEdit.html
[14:13:51 CDT(-0500)] <jhung> justin_o: not good. "The quick brown fox jumped button over the lazy dogs and then... edit undo edit redo edit."
[14:14:35 CDT(-0500)] <justin_o> jhung: okay... but it is different than what you saw with the current one... meaning different bugs
[14:14:59 CDT(-0500)] <jhung> after edit it reads: "CD Database Example <edited text> blank"
[14:15:07 CDT(-0500)] <justin_o> oh so that is the same
[14:15:42 CDT(-0500)] <jhung> yes. But appears to have different issues with respect to undo.redo buttons appearing.
[14:16:01 CDT(-0500)] <jhung> (known issue though?)
[14:22:54 CDT(-0500)] <anastasiac> Bosmon, do you have some time for questions about transactional listeners?
[14:22:59 CDT(-0500)] <Bosmon> yes
[14:23:18 CDT(-0500)] <anastasiac> so I'm trying to understand them enough to write instructions on when/how to use them
[14:23:52 CDT(-0500)] <anastasiac> I think I understand the basic idea: it allows you to queue up several changes, and get only one modelChanged event (eventually allowing roll-backs, etc)
[14:23:56 CDT(-0500)] <anastasiac> right so far?
[14:24:27 CDT(-0500)] <Bosmon> somewhat, yes
[14:25:00 CDT(-0500)] <anastasiac> how so 'somewhat'?
[14:25:08 CDT(-0500)] <Bosmon> Well, it does somewhat more than that
[14:25:33 CDT(-0500)] <Bosmon> In that it allows the changes to not be observable in the model, as well as not causing modelChanged events until committed
[14:25:57 CDT(-0500)] <anastasiac> well, let's start with the basics: not causing modelChanged events until committed
[14:26:22 CDT(-0500)] <anastasiac> what I'm not quite clear on is how to use this - what does someone have to do to queue up some changes and set them started?
[14:26:26 CDT(-0500)] <anastasiac> I looked at your tets
[14:26:28 CDT(-0500)] <anastasiac> tests
[14:26:47 CDT(-0500)] <anastasiac> and I think I must be misunderstanding, because what I see looks odd to me
[14:27:57 CDT(-0500)] <Bosmon> Urgh
[14:27:57 CDT(-0500)] <anastasiac> so, Bosmon, what does someone have to do to queue up some changes and set them started?
[14:28:08 CDT(-0500)] <Bosmon> It seems there are not tests for that particular functionality (sad)
[14:28:09 CDT(-0500)] <Bosmon> Awful....
[14:28:22 CDT(-0500)] <Bosmon> There are only tests for getting this done implicitly
[14:28:30 CDT(-0500)] <anastasiac> ah, interesting
[14:28:42 CDT(-0500)] <anastasiac> well, why don't you tell me how it's done, then?
[14:28:45 CDT(-0500)] <Bosmon> (smile)
[14:29:05 CDT(-0500)] <Bosmon> So, the transactional changeApplier causes a call to "initiate" at the start of a transaction
[14:29:28 CDT(-0500)] <Bosmon> Now, this can be done either manually by the user, or it is done implicitly by the implementation if the chanegApplier is configured to be "transactional"
[14:29:43 CDT(-0500)] <Bosmon> In that case, each applyChangeRequest implicitly creates a 1-element "transaction"
[14:30:07 CDT(-0500)] <anastasiac> question: how is a changeapplier configured to be transactional? is this an option?
[14:30:14 CDT(-0500)] <Bosmon> However, that transaction includes not only the 1 "external" request but also any further requests triggered by guards
[14:30:16 CDT(-0500)] <Bosmon> yes, it is
[14:30:24 CDT(-0500)] <Bosmon> These options you can see tests for
[14:31:10 CDT(-0500)] <anastasiac> I see options for making a listener transactional, but which tests make a transactional changeApplier?
[14:32:20 CDT(-0500)] <Bosmon> Ah, you're right
[14:32:30 CDT(-0500)] <Bosmon> All appliers are now automatically transaction-capable now
[14:32:42 CDT(-0500)] <Bosmon> It's just they decide from time to time whether to create transactions or not
[14:33:00 CDT(-0500)] <anastasiac> ok, so what does a user have to do to use the transactionality-ness?
[14:33:12 CDT(-0500)] <anastasiac> as mentioned, they can create a transactional listener
[14:33:22 CDT(-0500)] <anastasiac> but what is such a thing?
[14:33:45 CDT(-0500)] <Bosmon> A transactional listener is one that, if it is detected to be listening to an incoming change which has not already opened a transaction, will open one
[14:34:11 CDT(-0500)] <Bosmon> That transaction will then be applied to the action of the original change and any transactional listeners that were found relevant
[14:34:32 CDT(-0500)] <Bosmon> And then that transaction will either apply all of those changes as one operation, or roll them back, depending on what occurs within the listeners
[14:35:25 CDT(-0500)] <Bosmon> So... the user gets the transactionality-ness, implicitly, in these cases
[14:36:21 CDT(-0500)] <anastasiac> so the first trans-listener registered for a given change-path will open a transaction for that change-path
[14:36:57 CDT(-0500)] <Bosmon> yes
[14:37:02 CDT(-0500)] <anastasiac> any subsequent trans-listeners registered for the same change-path will be added to the list of trans-listeners for that path
[14:37:32 CDT(-0500)] <Bosmon> Well, they are actually all assessed up-front, before the actual change starts to apply
[14:37:45 CDT(-0500)] <anastasiac> the idea is that the various trans-listeners could cancel the entire transaction
[14:37:46 CDT(-0500)] <Bosmon> If there are 1 or more of them, the change, followed by the listeners, will execute in a transaction
[14:37:55 CDT(-0500)] <Bosmon> If there are 0 of them, the change will just apply immediately
[14:38:06 CDT(-0500)] <Bosmon> yes
[14:38:07 CDT(-0500)] <anastasiac> ok, now I'm a little bit confused
[14:38:29 CDT(-0500)] <anastasiac> I thought the idea was to queue up multiple changes, but this sounds like queuing up multiple listeners
[14:38:44 CDT(-0500)] <Bosmon> Well, the point is, that the listeners may cause further changes to apply
[14:39:13 CDT(-0500)] <anastasiac> is that the only way to cause further changes, though the listeners?
[14:39:25 CDT(-0500)] <anastasiac> I can't queue up 5 requestChange() calls?
[14:39:26 CDT(-0500)] <Bosmon> The main point of having them in a transaction is so that any changes which are requested by the listeners will occur seemingly as one operation
[14:39:35 CDT(-0500)] <Bosmon> Yes, that is where you need to use the "initiate" call
[14:39:52 CDT(-0500)] <anastasiac> so the initiate() call is something that users will use?
[14:39:54 CDT(-0500)] <Bosmon> If you want multiple operations applied "from the outside" in a transaction, you need to open the transaction yourself
[14:40:18 CDT(-0500)] <Bosmon> Yes
[14:40:23 CDT(-0500)] <Bosmon> Or, it could be used by a CATT
[14:40:58 CDT(-0500)] <anastasiac> so, two general scenarios: 1) framework users control the initiate/commit of a transaction themselves, and 2) changes carried out by trans-listeners are glumped into a single transaction
[14:41:21 CDT(-0500)] <Bosmon> Yes
[14:41:40 CDT(-0500)] <anastasiac> ok, this is making more sense. I was confused by not seeing anything like scenario 1) in the tests
[14:41:49 CDT(-0500)] <anastasiac> since that's what I was expecting (smile)
[14:41:52 CDT(-0500)] <Bosmon> yes, scenario 1 is currently not tested
[14:42:12 CDT(-0500)] <Bosmon> Although the code that operates it is implicitly tested since it is what is used to operate 2) (tongue)
[14:42:26 CDT(-0500)] <anastasiac> ok - are there any other 'general scenarios' that might want to be described in user-facing documentation?
[14:42:39 CDT(-0500)] <Bosmon> I guess you might want to talk about "thin" ness
[14:42:58 CDT(-0500)] <anastasiac> that was my next question (smile)
[14:43:03 CDT(-0500)] <Bosmon> but I can't think of other general scenarios (tongue)
[14:43:14 CDT(-0500)] <Bosmon> We may discover some though
[14:43:35 CDT(-0500)] <Bosmon> Before we started talking, I hadn't really remembered there was more than 1 general scenario...
[14:43:54 CDT(-0500)] <anastasiac> it looks to me like 'thin' controls whether or not the changes are truly actually queued up and carried out together, or carried out as received, but only the modelCHanged firing is postponed
[14:43:58 CDT(-0500)] <anastasiac> is that about right?
[14:44:22 CDT(-0500)] <Bosmon> Well, the changes are always applied to something, as they are received
[14:44:40 CDT(-0500)] <Bosmon> The question is whether they are applied to something that is visible or not
[14:44:52 CDT(-0500)] <anastasiac> what are the use cases that might advise a user whether they want thin or thick?
[14:44:57 CDT(-0500)] <Bosmon> In the "thin" model, there is only ever 1 copy of the model, and you see the changes as they are applied
[14:45:07 CDT(-0500)] <Bosmon> In the "thick" model, the model is copied, and the changes are applied to a private copy
[14:45:18 CDT(-0500)] <Bosmon> In both cases, the observed stream of modelChanged events is identical
[14:45:29 CDT(-0500)] <Bosmon> Well, it is largely a performance/integrity tradeoff
[14:45:36 CDT(-0500)] <Bosmon> You may have a very large model that you don't want copied
[14:46:37 CDT(-0500)] <anastasiac> I suppose that the thin method would also require an actual rollback, whereas with thick, you just scrap the process
[14:47:18 CDT(-0500)] <Bosmon> Well, in the thin model, a rollback is just impossible
[14:47:43 CDT(-0500)] <anastasiac> ah! good to know. what would happen, then, if a transactional listener wanted to cancel the transaction?
[14:47:43 CDT(-0500)] <jhung> jameswy, justin_o, mlam: do we expect to have mouse tooltip be read back by a screen reader?
[14:48:23 CDT(-0500)] <jameswy> jhung: At which point? On hover for presentation?
[14:48:31 CDT(-0500)] <Bosmon> Well, I guess nothing would happen
[14:48:45 CDT(-0500)] <anastasiac> by nothing, you mean they can't cancel the transaction?
[14:48:47 CDT(-0500)] <justin_o> jhung, jameswy: I'm pretty sure it doesn't read back at all
[14:48:49 CDT(-0500)] <Bosmon> Perhaps this feature hasn't really been fully thought through... but there is not really any way for the transaction to be cancelled
[14:48:54 CDT(-0500)] <Bosmon> Effectively they can't, no
[14:49:03 CDT(-0500)] <anastasiac> ok, that's very good to know (smile)
[14:49:05 CDT(-0500)] <Bosmon> For "thin" models, the only feature you get is batching of modelChanged events
[14:49:10 CDT(-0500)] <anastasiac> right
[14:49:23 CDT(-0500)] <jameswy> justin_o, jhung: Not at all seems like the right interaction for this particular case, since the screen reader should be reading instructions right off the button, not the tooltip, no?
[14:49:26 CDT(-0500)] <jhung> jameswy: on hover over editable text in presentation mode. A tooltip appears visually, but nothing is read back.
[14:49:31 CDT(-0500)] <Bosmon> Which still might be worthwhile to some people
[14:49:44 CDT(-0500)] <anastasiac> whereas with thick, you could actually cancel the transaction if you wanted to, since the changes haven't actually been applied to the original model
[14:49:59 CDT(-0500)] <Bosmon> "thin" models I imagine would be useful to people displaying some kind of very large UI in a table
[14:50:04 CDT(-0500)] <justin_o> jameswy: I believe so yes
[14:50:12 CDT(-0500)] <Bosmon> Like perhaps one of those big "stock ticker" apps (tongue)
[14:50:14 CDT(-0500)] <jhung> jameswy: right. Just wanted to double check that interaction before I filed a bug. (smile)
[14:50:26 CDT(-0500)] <Bosmon> A few hundred cells, with changes firing unpredictably across them
[14:50:38 CDT(-0500)] <anastasiac> ok, cool. this is great
[14:50:41 CDT(-0500)] <jameswy> jhung, justin_o: Yes, this is fine. Screen readers read it as a button, so the user knows it's interactable. no need to be too redundant with instructions on this one.
[14:50:43 CDT(-0500)] <Bosmon> You may want to collect a whole set of changes and then only update the UI in a batch
[14:50:52 CDT(-0500)] <anastasiac> is there anything else I should know about thin vs thick?
[14:50:59 CDT(-0500)] <Bosmon> But all of the changes are assumed to "apply", for a thin model
[14:51:03 CDT(-0500)] <Bosmon> That's about it
[14:51:11 CDT(-0500)] <anastasiac> ok, you mentioned above...
[14:51:17 CDT(-0500)] * anastasiac scrolls
[14:51:23 CDT(-0500)] <Bosmon> A thin model doesn't really give anything in the way of integrity guarantees
[14:51:43 CDT(-0500)] <anastasiac> "it allows the changes to not be observable in the model"
[14:51:48 CDT(-0500)] <Bosmon> Right
[14:51:49 CDT(-0500)] <anastasiac> what does that mean?
[14:52:06 CDT(-0500)] <anastasiac> basically a way to sneak in a change without firing modelChanged?
[14:52:08 CDT(-0500)] <Bosmon> For a thick model, the thing called "model" that you send in to the applier is not seen to be updated, until the transaction commits
[14:52:24 CDT(-0500)] <anastasiac> ah
[14:52:34 CDT(-0500)] <Bosmon> Someone actually looking at that object always sees either the state before any changes start, or the state after they are all committed
[14:52:41 CDT(-0500)] <jhung> jameswy, mlam, justin_o, jenC: you may be interested in some testing I did with NVDA 2010.1 and the v1.3 simple inline edit demo. Posted the results in this Jira: http://issues.fluidproject.org/browse/FLUID-3814
[14:53:11 CDT(-0500)] <anastasiac> so if they should happen to examine the model mid-transaction, after a few 'requestChanges' but before commit, they won't yet see any changes
[14:53:16 CDT(-0500)] <Bosmon> right
[14:53:23 CDT(-0500)] <anastasiac> ok, cool. got it
[14:53:51 CDT(-0500)] <anastasiac> so next question: the "cullUnchanged" option
[14:53:55 CDT(-0500)] <Bosmon> aha
[14:54:08 CDT(-0500)] <anastasiac> this is an option on the applier itself, not listeners, right?
[14:54:27 CDT(-0500)] <Bosmon> right
[14:54:37 CDT(-0500)] <anastasiac> and what does it do?
[14:55:01 CDT(-0500)] <Bosmon> In the case that a change to the model is determined to actually leave it unchanged, it "swallows" the change request and fires no event
[14:55:05 CDT(-0500)] <anastasiac> does it prevent modelChanged if the request happens to not have any effect?
[14:55:11 CDT(-0500)] <anastasiac> (smile)
[14:55:17 CDT(-0500)] <anastasiac> cool
[14:55:39 CDT(-0500)] <justin_o> jhung: which part do you think is the non-user friendly part?
[14:55:51 CDT(-0500)] <anastasiac> if a 'null' change is one of several in a transaction, there's no real effect in that case, right?
[14:56:00 CDT(-0500)] <anastasiac> you'd still get an event
[14:56:06 CDT(-0500)] <anastasiac> if the other changes were not null?
[14:56:27 CDT(-0500)] <Bosmon> yes
[14:56:32 CDT(-0500)] <anastasiac> cool
[14:56:35 CDT(-0500)] <Bosmon> Currently "culling" is only applied change-by-change
[14:56:42 CDT(-0500)] <anastasiac> anything else I should know about "cullUnchanged" ?
[14:56:42 CDT(-0500)] <Bosmon> We may one day be able to do something more sophisticated
[14:56:52 CDT(-0500)] <Bosmon> Well, mainly that
[14:57:00 CDT(-0500)] <anastasiac> ok, so next question:
[14:57:03 CDT(-0500)] <Bosmon> Currently there is a quite simple implementation that just looks at the change itself
[14:57:11 CDT(-0500)] <anastasiac> post guards
[14:57:17 CDT(-0500)] <jhung> justin_o: I think some of the redundancy like "Clickable edit text untitled button clickable" should be avoided. But it doesn't matter really what I think though since I'm not a typical user of NVDA.
[14:57:41 CDT(-0500)] <anastasiac> and priority on guards
[14:57:47 CDT(-0500)] <jhung> This may be normal / acceptable to a regular NVDA user.
[14:57:47 CDT(-0500)] <Bosmon> Ah yes
[14:57:49 CDT(-0500)] <Bosmon> postGuards
[14:57:53 CDT(-0500)] <Bosmon> I had forgotten about those (tongue)
[14:57:57 CDT(-0500)] <anastasiac> I'm not yet clear on how those work
[14:58:08 CDT(-0500)] <anastasiac> it looks like post guards have some special powers to nullify other guards
[14:58:15 CDT(-0500)] <Bosmon> So, "normal" guards fire in response to individual change requests
[14:58:20 CDT(-0500)] <Bosmon> And are allowed to operate on those changes
[14:58:23 CDT(-0500)] <justin_o> jhung: yah... it's hard to tell... I think the double use of clickable is from nvda to frame what the clickable element is
[14:58:46 CDT(-0500)] <Bosmon> So, a "normal" guard applies by guarding a particular path, and is invoked at the point a change is applied that matches that path
[14:58:55 CDT(-0500)] <justin_o> jhung: did you think the duplication of the text being read out was redundant?
[14:58:58 CDT(-0500)] <anastasiac> ok, gotcha so far...
[14:59:08 CDT(-0500)] <Bosmon> A "post" guard on the other hand, only executes at the end of a transaction, assuming it has not already been cancalled
[14:59:12 CDT(-0500)] <Bosmon> cancelled
[14:59:40 CDT(-0500)] <anastasiac> so it's like a full-transaction guard
[14:59:51 CDT(-0500)] <anastasiac> as opposed to a single-change guard
[14:59:54 CDT(-0500)] <Bosmon> right
[15:00:09 CDT(-0500)] <anastasiac> now, regular guards can actually prevent a change
[15:00:16 CDT(-0500)] <Bosmon> So, the postGuard gets a final attempt to assess the state of the pre-commit model, and if it doesn't like it, back out the transaction
[15:00:17 CDT(-0500)] <jhung> justin_o: I personally think so. A button is clickable by nature. To say that something is a button, and then say it's a link or clickable seems repetitive.
[15:00:30 CDT(-0500)] <anastasiac> but a postGuard with a thin model wouldn't be able to do that?
[15:00:34 CDT(-0500)] <Bosmon> Well, both kinds of guards can cause the transaction to back out
[15:00:59 CDT(-0500)] <Bosmon> Really its best not to think too had about cancelling transctions with thin models (tongue)
[15:01:06 CDT(-0500)] <anastasiac> LOL
[15:01:08 CDT(-0500)] <Bosmon> If anyone tries to do that, the model will just be corrupted
[15:01:18 CDT(-0500)] <Bosmon> There is not really anything you can do
[15:01:20 CDT(-0500)] <anastasiac> well, it's the job of the documentation to warn users about things like that (smile)
[15:01:29 CDT(-0500)] <Bosmon> Not with our current implementation, in any case
[15:01:30 CDT(-0500)] <anastasiac> so I need to know what to warn them about
[15:01:37 CDT(-0500)] <justin_o> jhung: that's a good point... i wonder what it would do for a disabled button though... have you tried that at all with the disabled button in the progress demo?
[15:01:41 CDT(-0500)] <Bosmon> It's possible a really sophisticated implementation could figure out how to "unapply" the changes
[15:01:52 CDT(-0500)] <Bosmon> In the way that "old-style undo" engines do
[15:01:53 CDT(-0500)] <anastasiac> ok, so: with the default thick-model implementation, post guard guard the whole transaction
[15:01:57 CDT(-0500)] <Bosmon> But we don't have one of those yet
[15:02:14 CDT(-0500)] <Bosmon> Right
[15:02:35 CDT(-0500)] <anastasiac> and users need to be warned that with thin model, that won't work
[15:02:38 CDT(-0500)] <Bosmon> post guards can still guard a path - but they don't act, until the end of a transaction in which that path has been modified
[15:02:48 CDT(-0500)] <anastasiac> right
[15:02:53 CDT(-0500)] <Bosmon> Well, "that won't work" in that they can't cancel
[15:03:02 CDT(-0500)] <Bosmon> They can still apply some of the functions of guarding, though
[15:03:16 CDT(-0500)] <Bosmon> For example, they could indeed do something like "unapplying" the change or some other thing
[15:03:30 CDT(-0500)] <anastasiac> ah, the guard itself could try to undo things
[15:03:35 CDT(-0500)] <jhung> justin_o: in Progress it just says "Submit button". When disabled, NVDA doesn't say anything at all.
[15:03:42 CDT(-0500)] <Bosmon> yes
[15:03:49 CDT(-0500)] <Bosmon> It just gets no framework assistance in trying to do this
[15:04:00 CDT(-0500)] <anastasiac> Bosmon, if a postGuard was unhappy with the transaction, would the modelChanged be thwarted?
[15:04:03 CDT(-0500)] <anastasiac> with thin
[15:04:09 CDT(-0500)] <Bosmon> I think it would, yes
[15:04:16 CDT(-0500)] <anastasiac> hm
[15:04:21 CDT(-0500)] <justin_o> jhung: really... so it never says clickable when it is enabled?
[15:04:21 CDT(-0500)] <anastasiac> ok, good to know
[15:04:48 CDT(-0500)] <jhung> justin_o: I lied. NVDA does say "unavailable", but only after it announces a few steps in the progress. Seems a bit out of context. lol
[15:04:57 CDT(-0500)] <anastasiac> so in general, we should recommend against using post guards in combination with the thin options (smile)
[15:05:04 CDT(-0500)] <jhung> justin_o: yeah, just says it's a button.
[15:05:19 CDT(-0500)] <Bosmon> I don't know... we should just explain to the users what they do (tongue)
[15:05:24 CDT(-0500)] <anastasiac> (smile)
[15:05:29 CDT(-0500)] <anastasiac> cool
[15:05:31 CDT(-0500)] <justin_o> jhung: ah yes, i remember that.... okay... so i think it may be because for inline edit it is actually a link that we put a role of button on
[15:05:34 CDT(-0500)] <Bosmon> Basically, no kind of "cancellation" is a good idea in this case
[15:05:55 CDT(-0500)] <anastasiac> right
[15:06:21 CDT(-0500)] <anastasiac> so, Bosmon, can you think of anything else users should know about?
[15:06:28 CDT(-0500)] <justin_o> jhung: which would lead me to believe that it is an NVDA bug, but we would probably need to make a small test case for this
[15:07:08 CDT(-0500)] <Bosmon> Well
[15:07:24 CDT(-0500)] <Bosmon> I guess we should warn them that our model for "subappliers" and "superappliers" is incredibly incomplete
[15:07:32 CDT(-0500)] <jhung> justin_o: okay. I'm putting all of these issues into jiras and will send out an email to list shortly. Not sure if any of these are blockers.
[15:07:41 CDT(-0500)] <anastasiac> has it changed since the last release?
[15:07:53 CDT(-0500)] <justin_o> jhung: thanks
[15:07:54 CDT(-0500)] <Bosmon> To be honest, if we're not yet at the point where any of us is happy using the transactional applier in any code we are working on yet, it's a bit much to imagine any of our users will be (tongue)
[15:08:02 CDT(-0500)] <Bosmon> But who knows, some of them may be enterprising
[15:08:07 CDT(-0500)] <Bosmon> No, it hasn't changed, which is the main problem
[15:08:35 CDT(-0500)] <anastasiac> well, the documentation for transactional appliers will be marked very prominently as "sneak peek" (smile)
[15:08:54 CDT(-0500)] <anastasiac> we do want potential users to tell us whether or not they'd find it useful
[15:08:58 CDT(-0500)] * jhung thinks Inline Edit is the gift that keeps on giving... even after you've asked it to stop.
[15:09:04 CDT(-0500)] <anastasiac> they can't do that if they don't know how to use it
[15:09:20 CDT(-0500)] <anastasiac> jhung: (smile)
[15:09:45 CDT(-0500)] <anastasiac> Bosmon, this conversation has been incredibly helpful - thanks so much!
[15:10:07 CDT(-0500)] <anastasiac> once I've got this written up, I'll appreciate a 'subject-matter-expert' review to make sure I don't screw it up
[15:12:11 CDT(-0500)] <Bosmon> No problem
[15:12:15 CDT(-0500)] <Bosmon> I look forward to seeing it
[15:12:30 CDT(-0500)] <anastasiac> Bosmon, just so you know: we're going to have a network outage at 4:30 (i.e. in about 15 minutes), so many of us will disappear from the channel, and lose access to email, etc
[15:12:39 CDT(-0500)] <Bosmon> Oh dear
[15:13:50 CDT(-0500)] <anastasiac> yeah. I'm not sure why they're not waiting until a little bit later...
[15:22:15 CDT(-0500)] <anastasiac> mpolizzotti, welcome! seeing you here reminds me that I neglected to respond to your email about an FSS call. I'm so sorry!
[15:22:36 CDT(-0500)] <mpolizzotti> No problem. I know you are very busy. (smile)
[15:23:17 CDT(-0500)] <mpolizzotti> Is the meeting something that interests Fluid?
[15:23:44 CDT(-0500)] <anastasiac> mpolizzotti, yes, this is definitely something that would be great!
[15:24:05 CDT(-0500)] <colinclark> I'd like to get Heidi in on that meeting when she gets back from her vacation
[15:24:08 CDT(-0500)] <anastasiac> we need to figure out who should attend (it would definitely be more than just me this time)
[15:24:14 CDT(-0500)] <colinclark> I wondered if jameswy was perhaps also interested in attending?
[15:24:20 CDT(-0500)] <anastasiac> colinclark, yes: heidi should be there
[15:24:54 CDT(-0500)] <mpolizzotti> Right. Do you have a particular week in mind? I could set up a conference call.
[15:24:56 CDT(-0500)] <anastasiac> michelled might like to attend, but she's out of town this week, and she thinks that if the right other people are there, we'd be ok
[15:25:46 CDT(-0500)] <jameswy> colinclark, mpolizzotti, anastasiac: I'd love to be there!
[15:25:52 CDT(-0500)] <mpolizzotti> What about the first week in November? Would that give you enough time?
[15:26:12 CDT(-0500)] <anastasiac> mpolizzotti, we're actually going to have a network outage in about 5 minutes (smile) so we might want to follow up on this scheduling via email over the next day or two
[15:26:24 CDT(-0500)] <anastasiac> but early November sounds good so far
[15:27:36 CDT(-0500)] <mpolizzotti> Okay. I can set up a tentative meeting. If you could email me a list of participants I can send out a request.
[15:27:50 CDT(-0500)] <mpolizzotti> Do you still have my email address?
[15:27:50 CDT(-0500)] <colinclark> I'll be out of town the first week in November, but I'm happy to have you guys go ahead if it works for everyone else.
[15:28:00 CDT(-0500)] <anastasiac> mpolizzotti, will do. yes, I have your email
[15:28:41 CDT(-0500)] <mpolizzotti> Okay. Sounds good. Colin, its not set in stone but I'd like to have you on the call as well.