fluid-work IRC Logs-2009-01-09

Owned by Fluid IRC Log Bot
Last updated: Jan 09, 2009Version comment
11 min read

[00:21:42 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[04:23:39 EST(-0500)] * sychare (n=sychare@mail.weblogik.biz) has joined #fluid-work
[04:25:46 EST(-0500)] <sychare> Hi, is anybody around? Just got a quick question: if I add something to a div that is Reorderable, how do I trigger a 'refresh' so that the new item is also reorderable?
[07:19:22 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[07:44:04 EST(-0500)] * laurelw (n=Laurel@142.150.154.178) has joined #fluid-work
[08:09:57 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[08:21:08 EST(-0500)] * Justin_o (n=Justin@142.150.154.101) has joined #fluid-work
[09:11:23 EST(-0500)] * colinclark (n=colin@bas2-toronto09-1176132254.dsl.bell.ca) has joined #fluid-work
[09:20:40 EST(-0500)] * anastasiac (n=stasia@142.150.154.235) has joined #fluid-work
[09:28:33 EST(-0500)] * michelled (n=michelle@142.150.154.197) has joined #fluid-work
[09:42:45 EST(-0500)] * clown (n=clown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[09:44:58 EST(-0500)] * clown (n=clown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[09:46:06 EST(-0500)] <colinclark> Justin_o: I've had a look at the FLUID-2073 patch, and have a very minor variant on it which I will post to JIRA.
[09:46:08 EST(-0500)] * fj40001 (n=Main@CPE00095bc35ea1-CM001692f5798c.cpe.net.cable.rogers.com) has joined #fluid-work
[09:46:16 EST(-0500)] <colinclark> Functionally, it's good.
[09:46:49 EST(-0500)] <colinclark> I was thinking of asking Eli if he'd like to take a crack at tidying up the gracefully degraded markup a bit so that it doesn't look so austere. (smile)
[09:46:55 EST(-0500)] <colinclark> (that was my doing)
[09:54:38 EST(-0500)] <Justin_o> colinclark: thanks...
[09:58:41 EST(-0500)] <Justin_o> clown: I have a question that you may be able to answer. I'm thinking about trying to make screen reader test plans for our components. Would happen to know a good site where I can find information about how the screen reader should be behaving? I'm going to start looking at this page right now http://www.w3.org/TR/wai-aria/.
[09:59:21 EST(-0500)] <clown> Justin_o: that's a good start, but a long row to hoe...
[09:59:41 EST(-0500)] <clown> ...that will give you the specs, and you could infer what a screen reader should do...
[09:59:47 EST(-0500)] <Justin_o> clown: yes... i was just noticing how long the page is
[10:00:00 EST(-0500)] <clown> ...but you should also check out code talks...
[10:00:07 EST(-0500)] * clown looking up the url.
[10:00:33 EST(-0500)] <clown> The main page is here: http://wiki.codetalks.org/wiki/index.php/Main_Page
[10:01:03 EST(-0500)] <clown> but, there is also a "test cases" page that might give you better insight into how SR's should behave.
[10:01:16 EST(-0500)] * clown looking up that url
[10:01:20 EST(-0500)] <Justin_o> i was looking a bit at this page http://wiki.codetalks.org/wiki/index.php/Set_of_ARIA_Test_Cases#Combobox
[10:01:25 EST(-0500)] <Justin_o> i think that's what you are talking about
[10:02:15 EST(-0500)] <clown> yup, that's it. Unfortunately (for you), that's categorized according to aria roles. E.g. "checkbox", or "menuitem"
[10:02:45 EST(-0500)] <clown> I say, "unfortunately", because you will have to do some mapping with respect to fluid components (they don't fall as neatly into the role categories).
[10:03:55 EST(-0500)] <clown> although, I just noticed that they have added a section on aria-properties (section 4). That's different than just roles.
[10:04:42 EST(-0500)] <Justin_o> oh i see
[10:05:09 EST(-0500)] <Justin_o> thanks...
[10:06:09 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:06:10 EST(-0500)] <clown> but, still, there are sections entitled "Expected AT behaviour". At least it should give you ideas.
[10:06:34 EST(-0500)] <Justin_o> clown: thanks... that should help....
[10:06:54 EST(-0500)] <Justin_o> also just to double check... is aria not supported in IE7
[10:07:08 EST(-0500)] <clown> FInally there is the best practices guide (BPG), which is another W3C aria doc, and a long one: http://www.w3.org/WAI/PF/aria-practices/
[10:08:31 EST(-0500)] <Justin_o> clown: thanks for the information... that should keep me busy for a while
[10:08:32 EST(-0500)] <clown> Technically, no: neither IE6 nor IE7 support ARIA. IE8 will be the first to do so. Nonetheless, a dijit widgets work fairly well with JAWS and IE6/7.
[10:09:29 EST(-0500)] <Justin_o> but they won't necesarily be presented the same by the screen reader as they would be in ie8?
[10:11:11 EST(-0500)] <clown> Dunno, partly because ie8 is still in beta. I'm assuming the experience will be better, and that it will be easier for DHTML coders to get the IE8/Screen Reader combo working properly (knowing that IE8 will expose the aria information to MSAA).
[10:13:09 EST(-0500)] <Justin_o> okay.... i think i get it...
[10:31:18 EST(-0500)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[11:01:44 EST(-0500)] * ecochran (n=ecochran@adsl-70-137-175-133.dsl.snfc21.sbcglobal.net) has joined #fluid-work
[11:03:21 EST(-0500)] * ecochran (n=ecochran@adsl-70-137-175-133.dsl.snfc21.sbcglobal.net) has joined #fluid-work
[11:11:15 EST(-0500)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[11:41:21 EST(-0500)] <Justin_o> I'm going to be rebuilding the daily build site... it should take less than a minute..
[11:55:02 EST(-0500)] <Justin_o> colinclark, ecochran: I'm testing FLUID-2073... so far the demo version looks good, but the server version still seems to display the flash version
[11:55:28 EST(-0500)] <colinclark> Justin_o: The server version is, unfortunately, unable to show off our progressive enhancement support.
[11:55:45 EST(-0500)] <colinclark> Justin_o: Well, wait. I could show part of it.
[11:55:59 EST(-0500)] <colinclark> Let me try to explain.
[11:56:03 EST(-0500)] <Justin_o> okay
[11:56:10 EST(-0500)] <colinclark> At the moment, there are two different ways to instantiate an uploader...
[11:56:19 EST(-0500)] <colinclark> I think this process will need to be addressed down the road.
[11:56:31 EST(-0500)] <colinclark> But for now, you can use one of two possible creator functions available for the uploader:
[11:56:48 EST(-0500)] <colinclark> fluid.uploader(...), which simply gives you an Uploader.
[11:57:16 EST(-0500)] <colinclark> fluid.progressiveEnhanceableUploader(...), which will degrade gracefully
[11:57:48 EST(-0500)] <colinclark> I'll have to check, but if I remember, the server version doesn't use progressiveEnhanceableUploader() because it loads most of the contents of the page via Ajax
[11:57:58 EST(-0500)] <colinclark> Thus making our initial stab at progressive enhancement unnecessary.
[11:58:16 EST(-0500)] <colinclark> But now that we've fleshed it out a bit, ecochran or I should make that change.
[11:58:47 EST(-0500)] <Justin_o> okay.. that sounds good... is it something that should happen as part of 2073 or will it come later
[11:59:39 EST(-0500)] <colinclark> Justin_o: It should be part of 2073
[12:00:11 EST(-0500)] <Justin_o> okay... i guess I'll reopen it with a comment about the server version needing to be updated as well
[12:00:15 EST(-0500)] <colinclark> Justin_o, ecochran: Hmm, no.
[12:00:17 EST(-0500)] <colinclark> https://source.fluidproject.org/svn/fluid/image-gallery/trunk/web/src/main/webapp/AddImages.html
[12:00:30 EST(-0500)] <colinclark> It is indeed using the progressive enhanceable creator.
[12:00:38 EST(-0500)] <colinclark> Sounds like it's a real bug.
[12:01:16 EST(-0500)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[12:01:19 EST(-0500)] <Justin_o> (sad)
[12:01:23 EST(-0500)] <ecochran> hmm
[12:01:35 EST(-0500)] <colinclark> Ah, I think I may know...
[12:01:36 EST(-0500)] <colinclark> one sec
[12:02:11 EST(-0500)] <ecochran> I just walked back in on this thread... reading back
[12:02:15 EST(-0500)] <colinclark> This is probably it:
[12:02:16 EST(-0500)] <colinclark> https://source.fluidproject.org/svn/fluid/image-gallery/trunk/web/pom.xml
[12:02:51 EST(-0500)] <colinclark> Note the version of fluid-components in the mvn build file there.
[12:03:01 EST(-0500)] <colinclark> 0.6-SNAPSHOT
[12:03:09 EST(-0500)] <ecochran> oh crap
[12:03:15 EST(-0500)] <colinclark> It's building against an older version.
[12:03:18 EST(-0500)] <colinclark> Easy fix, I'll commit.
[12:03:23 EST(-0500)] <ecochran> thx
[12:03:26 EST(-0500)] <Justin_o> thanks
[12:03:48 EST(-0500)] <ecochran> that may also explain my problems that I'm having
[12:04:25 EST(-0500)] <colinclark> ecochran: Yep, if you're experiencing staleness, that's it.
[12:04:48 EST(-0500)] <colinclark> Stupidly, I had fixed it in my local copy and forgotten to commit.
[12:04:51 EST(-0500)] <colinclark> (sad)
[12:04:52 EST(-0500)] <colinclark> Sorry, dudes.
[12:06:32 EST(-0500)] <colinclark> ecochran: I'm going to go ahead and commit a fully relative version of that image-gallery build script I sent you. It's been awfully useful for me.
[12:07:08 EST(-0500)] <ecochran> colinclark: where?
[12:07:25 EST(-0500)] <colinclark> To the top level of image-gallery trunk.
[12:08:12 EST(-0500)] <ecochran> colinclark: should we put it in the development support dir?
[12:08:32 EST(-0500)] <colinclark> ecochran: I had thought about it. It will just make it one step more annoying to run it. (wink)
[12:08:37 EST(-0500)] <colinclark> Your call, I don't really mind.
[12:09:41 EST(-0500)] <ecochran> colinclark: just don't want it to confuse anyone
[12:09:50 EST(-0500)] <colinclark> k, I'll put it in development support
[12:09:52 EST(-0500)] <ecochran> we should at least document it in the readme
[12:10:10 EST(-0500)] <colinclark> ecochran: It's too bad image-gallery isn't a supported app. (wink)
[12:10:31 EST(-0500)] <ecochran> it's our only real server example
[12:10:36 EST(-0500)] <ecochran> maybe it should be promoted!
[12:10:54 EST(-0500)] <ecochran> colinclark: Ray would be proud!
[12:10:56 EST(-0500)] <colinclark> promoted to what?
[12:11:24 EST(-0500)] <ecochran> colinclark: to part of the Fluid release
[12:11:32 EST(-0500)] <ecochran> as an example
[12:11:32 EST(-0500)] <colinclark> ecochran: ?!?
[12:12:19 EST(-0500)] <colinclark> ecochran: I'm pretty hesitant to promote a chunk of code that was dropped to a core part of the release.
[12:12:57 EST(-0500)] <ecochran> colinclark: sorry, I should have put a emoticon in my comment that indicated that I wasn't completely serious
[12:13:00 EST(-0500)] <colinclark> (tongue)
[12:13:51 EST(-0500)] <ecochran> colinclark: it's a fine bit of code though and I feel that a "blessed" server example would be a nice part of the Uploader example... but we'd need to put thought and a little work into it
[12:13:56 EST(-0500)] <colinclark> We have a long, gory trail of image galleries behind us.
[12:14:54 EST(-0500)] <ecochran> yes, I keep slipping the muck that they've left behind (although much of that is emotional muck)... OK, this diversion has to stop (tongue)
[12:15:00 EST(-0500)] <colinclark> lol
[12:15:07 EST(-0500)] <colinclark> no worries
[12:46:03 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[13:18:24 EST(-0500)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[13:27:21 EST(-0500)] <fj40001> hey guys, im trying to review fluid-1999
[13:27:30 EST(-0500)] <fj40001> and its telling me the patch might be outdated
[13:27:55 EST(-0500)] <fj40001> soooo, im wondering if its ok to just read the patch and apply the core changes manually?
[13:28:08 EST(-0500)] <fj40001> or should another patch be generated?
[13:29:48 EST(-0500)] <colinclark> fj40001: That's probably one to chat with michelled about. She's in a meeting at the moment, but should be done shortly.
[13:30:24 EST(-0500)] <fj40001> colinclark: thanks!
[13:30:26 EST(-0500)] <fj40001> will do
[13:32:40 EST(-0500)] <colinclark> Bosmon: Aha! I've got the 2059 bug showing now.
[13:32:53 EST(-0500)] <colinclark> I'll commit a test and you can tell me if it's a sane use case.
[13:41:45 EST(-0500)] <colinclark> anastasiac: For whatever reason, Bosmon and I are talking about this FLUID-2059 over IM instead of in the channel...
[13:41:59 EST(-0500)] <colinclark> but I will summarize what we have ascertained about the issue.
[13:42:04 EST(-0500)] <anastasiac> shoot
[13:42:07 EST(-0500)] <colinclark> Take a look real quick at FluidJSTests.js
[13:42:29 EST(-0500)] * anastasiac has it up
[13:42:46 EST(-0500)] <colinclark> Okay, the last test case, "initSubcomponents"
[13:42:56 EST(-0500)] <anastasiac> got it
[13:42:59 EST(-0500)] <colinclark> There's a function right above it where I define a component and a subcomponent.
[13:43:01 EST(-0500)] <colinclark> Check that out first
[13:43:13 EST(-0500)] <colinclark> sorry, two functions above
[13:43:17 EST(-0500)] <anastasiac> got it - was looking at that yesterday
[13:43:23 EST(-0500)] <colinclark> called, aptly, defineTestComponent()
[13:43:40 EST(-0500)] <colinclark> So I have a subcomponent of the parent component, which I have named "subcomponent."
[13:43:49 EST(-0500)] <colinclark> Take a look at how I've defined it in the test component's defaults.
[13:44:05 EST(-0500)] <anastasiac> yep
[13:44:23 EST(-0500)]

<colinclark> subcomponent:

Unknown macro: { type}

;


[13:44:39 EST(-0500)] <colinclark> For users who are overriding options, there's a convenient short hand...
[13:44:41 EST(-0500)] <colinclark> they can do this:
[13:45:06 EST(-0500)]

<colinclark> fluid.tests.testComponent(container,

Unknown macro: { subcomponent}

);


[13:45:33 EST(-0500)] <colinclark> It's just a convenience; they can specify the string directly, rather than having to create an extra little object and give it a "type" property.
[13:45:40 EST(-0500)] <colinclark> This seems to me to be very friendly.
[13:46:32 EST(-0500)] <anastasiac> ok
[13:47:00 EST(-0500)] <colinclark> Now, as a component developer, I assumed that this shorthand would be equally legitimate when defining the component's defaults.
[13:47:27 EST(-0500)] <colinclark> So if you check out that "initSubcomponents" test case, take a look at the code below the comment that says:
[13:47:29 EST(-0500)] <colinclark> // Now test with the default type defined in the shorthand format.
[13:48:49 EST(-0500)] <anastasiac> ok
[13:49:00 EST(-0500)] <colinclark> That's where I test if the shorthand syntax works or not.
[13:49:27 EST(-0500)] <colinclark> And, boom, it explodes.
[13:49:37 EST(-0500)] <anastasiac> wait
[13:49:43 EST(-0500)] <colinclark> k
[13:50:13 EST(-0500)] * anastasiac looks more closely
[13:50:50 EST(-0500)] <anastasiac> ok, so it seems you're saying that the bug still exists
[13:51:21 EST(-0500)] <anastasiac> is that correct, colinclark?
[13:51:48 EST(-0500)] <colinclark> anastasiac: Yes. The bug exists if the component developer attempts to define the type of their subcomponent using the shorthand format.
[13:51:58 EST(-0500)] <colinclark> subcomponent: "type"
[13:52:00 EST(-0500)] <colinclark> instead of
[13:52:06 EST(-0500)]

<colinclark> subcomponent:

Unknown macro: { type}

[13:52:09 EST(-0500)] <anastasiac> got it
[13:52:25 EST(-0500)] <colinclark> For various reasons, it appears that this is asking too much of the framework.
[13:52:31 EST(-0500)] <anastasiac> interesting
[13:52:36 EST(-0500)] <colinclark> And thus we're going to treat it as a user error.
[13:52:53 EST(-0500)] <colinclark> Meaning we've got a policy: you can't use the shorthand format for specifying types of subcomponents.
[13:53:02 EST(-0500)] <colinclark> When you are specifying a component's defaults.
[13:53:03 EST(-0500)] * Bosmon (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[13:53:18 EST(-0500)] <colinclark> Component users, when overriding types, are still free to use the shorthand.
[13:53:31 EST(-0500)] <colinclark> Component developers must use the long form when defining defaults.
[13:54:03 EST(-0500)] <anastasiac> ok
[13:54:12 EST(-0500)] <anastasiac> something resulting:
[13:54:33 EST(-0500)] <anastasiac> if a user uses the shorthand to customize an option for a subcomponent
[13:54:50 EST(-0500)] <anastasiac> things will go wrong if there are overlapping option names, won't they?
[13:55:00 EST(-0500)] <colinclark> how so?
[13:55:31 EST(-0500)] <anastasiac> well, if component has option name 'foo', and it's subcomponent1 has option name 'foo', and user sets 'foo' to 'bar', which foo do they mean?
[13:55:49 EST(-0500)] <colinclark> the shorthand only applies to subcomponent types
[13:56:01 EST(-0500)] <colinclark> So, if I'm understanding you, that shouldn't ever be a problem.
[13:56:13 EST(-0500)] <colinclark> You can see this by taking a peek at the implementation of initSubcomponents:
[13:56:15 EST(-0500)] <colinclark> var entryType = typeof(entry) === "string"? entry : entry.type;
[13:56:25 EST(-0500)] <colinclark> you can see, it does some simple type detection...
[13:56:30 EST(-0500)] <anastasiac> I think I'm not communicating something properly...
[13:56:54 EST(-0500)] <anastasiac> or not understanding what is meant by 'user shorthand'
[13:57:02 EST(-0500)] * anastasiac scrolls back and reviews
[13:57:36 EST(-0500)] <anastasiac> ah, ok
[13:57:41 EST(-0500)] <anastasiac> here's a better way to explain.
[13:57:46 EST(-0500)] <colinclark> (smile)
[13:57:46 EST(-0500)] <anastasiac> in your test code:
[13:58:14 EST(-0500)] <anastasiac> oh, wait
[13:58:30 EST(-0500)] <anastasiac> ok, the problem I was envisioning is not a problem, but another very similar one is (smile)
[13:58:46 EST(-0500)] <anastasiac> suppose there are two subcomponents - and they both have an option called foo...
[13:59:16 EST(-0500)] <colinclark> yep
[14:00:15 EST(-0500)] <anastasiac> so right now, it's a requirement that component developers ensure that subcomponents don't share option names
[14:00:45 EST(-0500)] <colinclark> no
[14:00:57 EST(-0500)] <anastasiac> ?
[14:01:10 EST(-0500)] <colinclark> there's no chance of options for different subcomponents conflicting.
[14:01:33 EST(-0500)] <anastasiac> so if I set foo to bar using the shorthand, do I mean subcomponent1.foo, or subcomponent2.foo?
[14:01:50 EST(-0500)] <colinclark> you can't use the shorthand to anything except specify the type of a subcomponent.
[14:02:46 EST(-0500)] <anastasiac> what about what's being done in componentWithOverridenSubcomponentOptions() ?
[14:03:06 EST(-0500)] <anastasiac> ugh, ok, "subcomponent" is right ther
[14:03:17 EST(-0500)] <colinclark> (smile)
[14:03:25 EST(-0500)] <colinclark> "subcomponent" is the name of the subcomponent
[14:03:28 EST(-0500)] <colinclark> dorky name
[14:03:29 EST(-0500)] <anastasiac> it's because the word is also conceptual, as well as the name
[14:03:32 EST(-0500)] <colinclark> but it's a unit test
[14:03:40 EST(-0500)] <colinclark> i could call it "mySubcomponent" if you think that would be clearer
[14:03:45 EST(-0500)] <anastasiac> I know, I know, but my brain is easily confused
[14:03:56 EST(-0500)] <anastasiac> I've been reviewing docs for too long
[14:03:59 EST(-0500)] <colinclark> lol
[14:05:25 EST(-0500)] <anastasiac> ok, I think I've got the picture now
[14:05:44 EST(-0500)] <anastasiac> documenting all of this subcomponent stuff and all of the related issues is tricky...
[14:06:17 EST(-0500)] <colinclark> So the reason I bring this up to you is that we should probably document somewhere-perhaps in an as-yet-nonexistant document about how to write a component-that you can't use the type shorthand when defining defaults.
[14:08:07 EST(-0500)] <anastasiac> yes, I'll definitely make a note of it somewhere... I'll figure out where
[14:08:12 EST(-0500)] <colinclark> ok, great
[14:28:15 EST(-0500)] <ecochran> colinclark: is colinclark in the building?
[14:31:01 EST(-0500)] * colinclark is in the building
[14:31:09 EST(-0500)] * colinclark was getting a sandwich
[15:31:00 EST(-0500)] * laurelw (n=Laurel@142.150.154.178) has left #fluid-work
[15:34:18 EST(-0500)] * fj40001 (n=Main@CPE00095bc35ea1-CM001692f5798c.cpe.net.cable.rogers.com) has joined #fluid-work
[16:17:23 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[16:55:10 EST(-0500)] * michelled (n=team@142.150.154.197) has left #fluid-work
[17:38:35 EST(-0500)] * clown (n=clown@guiseppi.atrc.utoronto.ca) has left #fluid-work
[18:44:50 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[20:50:30 EST(-0500)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work