fluid-work IRC Logs-2008-04-28

[03:49:28 EDT(-0400)] * slightlyoff (n=alex@204.14.154.209) has joined #fluid-work
[08:50:11 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[08:57:43 EDT(-0400)] * aaronlev (n=chatzill@nat/ibm/x-d7dac1d6cd3fe2ee) has joined #fluid-work
[09:54:59 EDT(-0400)] * theclown (n=theclown@142.150.154.101) has joined #fluid-work
[10:14:35 EDT(-0400)] * anastasiac (n=team@142.150.154.105) has joined #fluid-work
[10:18:38 EDT(-0400)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[10:19:26 EDT(-0400)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[10:25:19 EDT(-0400)] * colinclark (n=colin@12.20.36.16) has joined #fluid-work
[10:27:55 EDT(-0400)] <colinclark> anastasiac: Here's a PDF of the slides from yesterday's workshop.
[10:28:25 EDT(-0400)] <colinclark> There's a whole section on "How to Write Portal-Friendly UIs" which is essentially a step by step guide to building a Fluid component.
[10:28:57 EDT(-0400)] <colinclark> michelled: Have you seen our new little example component? https://source.fluidproject.org/svn/sandbox/javascript-workshop/trunk/examples/tabs/
[10:29:19 EDT(-0400)] <michelled> yes, it looks really nice!
[10:29:20 EDT(-0400)] <colinclark> And our sample code for supporting keynav and aria in jQuery? https://source.fluidproject.org/svn/sandbox/javascript-workshop/trunk/examples/a11y/
[10:29:28 EDT(-0400)] <michelled> yes
[10:30:16 EDT(-0400)] <michelled> Later this week we will tackle keynav in the upload component. Hoping to make it as pretty as the tabs
[10:30:20 EDT(-0400)] <colinclark> michelled, anastasiac: Hopefully it will help with writing documentation.
[10:30:46 EDT(-0400)] <colinclark> michelled: Cool. I think it will be interesting. Some of it will probably just be Tab key-based navigation.
[10:30:49 EDT(-0400)] <anastasiac> colinclark, I'm sure it will help!
[10:31:00 EDT(-0400)] <colinclark> Perhaps things like the list of files will need to be arrow key navigable.
[10:31:45 EDT(-0400)] <michelled> yes, I think that makes sense.
[10:33:10 EDT(-0400)] <colinclark> michelled, anastasiac: One of the interesting point that I think is emerging from having built enough components to see some patterns emerge...
[10:33:44 EDT(-0400)] <colinclark> Is the fact that it is a reasonable strategy to enable DOM agnosticism by parameterizing jQuery selectors.
[10:34:06 EDT(-0400)] <colinclark> So that when someone needs to change markup, they can also just give us a little map of selectors to tell us how to bind with the DOM.
[10:34:24 EDT(-0400)] <colinclark> I call these "interesting things" for lack of a better name.
[10:34:42 EDT(-0400)] <michelled> It's nice that we can do that now that we aren't trying to be toolkit agnostic anymore.
[10:35:10 EDT(-0400)] <colinclark> Now, this was michelled's innovation. We've just proved it works.
[10:35:27 EDT(-0400)] <colinclark> The only downside is that these "interesting thing" maps can get pretty big.
[10:35:55 EDT(-0400)] <colinclark> michelled: Yes, true. Although I don't think selectors are very toolkit-specific anymore.
[10:36:09 EDT(-0400)] <colinclark> Everyone has built a selector API at this point.
[10:36:41 EDT(-0400)] <colinclark> michelled, anastasiac: So the thin we'll want to put some thinking into is how we could make it easier to maintain these interesting thing maps.
[10:36:46 EDT(-0400)] <michelled> True. And the fact that jQuery's is just CSS selectors and not some new thing really helps.
[10:37:05 EDT(-0400)] <colinclark> In the List Builder, I provided a set of default selectors for the case when you only want one component instance on the page.
[10:37:24 EDT(-0400)] <colinclark> In that situation, you'd be able to initialize the component in one line.
[10:38:15 EDT(-0400)] <colinclark> In cases like the Uploader, it would help to break it up into several modules, each with its own smaller set of interesting things.
[10:38:41 EDT(-0400)] <colinclark> But I wonder what other strategies we might be able figure out for injecting dom bindings into a component.
[10:39:23 EDT(-0400)] <colinclark> michelled, anastasiac: Ironically, part of the solution will be to do CSS class-based searches.
[10:40:10 EDT(-0400)] <colinclark> Despite the fact that they're completely inappropriate for the Reorderer, they are reasonable for components that don't contain other instances of themselves.
[10:40:30 EDT(-0400)] <michelled> yes and the uploader is that type of component.
[10:40:43 EDT(-0400)] <colinclark> Tabs and List Builder also.
[10:41:50 EDT(-0400)] <colinclark> michelled: Bosmon doesn't agree with my component ontology where I make a distinction between Reorderer as a non-component and other components that do have a look-and-feel and that, generally, won't have these recursive requirements.
[10:41:52 EDT(-0400)] <michelled> We should probably mention that in the documentation for those components. Just to be clear.
[10:42:14 EDT(-0400)] <colinclark> But this is example of how the Reorderer makes for a very unusually complex component.
[10:44:25 EDT(-0400)] <michelled> I don't think it's the fact that there is a look and feel that makes other components simpler then the Reorderer. In your ontology, is Layout Customizer a component?
[10:45:41 EDT(-0400)] <colinclark> michelled: Good question.
[10:45:51 EDT(-0400)] <colinclark> My ontology is severely confused.
[10:46:38 EDT(-0400)] <colinclark> michelled: I will venture a guess of yes, but of course you'll then say that it has no real look and feel, nor does it avoid this consideration of recusive instantiation.
[10:46:57 EDT(-0400)] <michelled>
[10:47:07 EDT(-0400)] <colinclark> michelled: So then what is LayoutCustomizer?
[10:47:28 EDT(-0400)] <colinclark> A combination of a new way of data binding with the server for describing movable modules...
[10:47:37 EDT(-0400)] <colinclark> A new layout handler that takes this into account...
[10:47:45 EDT(-0400)] <michelled> I think it is a component but we have different types (granularity?) of components.
[10:47:50 EDT(-0400)] <colinclark> And some new interactions optimized for the layout context?
[10:48:11 EDT(-0400)] <colinclark> michelled: So what are the different types of components?
[10:49:19 EDT(-0400)] <michelled> I don't know. So far ones that might be nested and ones that can't be nested.
[10:50:18 EDT(-0400)] <michelled> I agree that the Reorderer isn't a component. It's the Lightbox and Layout Customizer that are components. They use the underlying functionality in the Reorderer.
[10:50:24 EDT(-0400)] <colinclark> michelled: Can we equate these with components that don't have a specific look and feel?
[10:50:53 EDT(-0400)] <michelled> But then you may ask what the other examples of using the Reorderer are and I don't have a satisfying answer.
[10:50:54 EDT(-0400)] <colinclark> michelled: Right. That's why I see Reorderer more as a service upon which components are built.
[10:50:57 EDT(-0400)] <colinclark> Bosmon disagrees.
[10:52:22 EDT(-0400)] <michelled> Do any components have a specific look and feel? I mean if we are allowing people to specify their DOM bindings then doesn't the look and feel depend on them?
[11:03:15 EDT(-0400)] * Bosmo1 (n=Bosmon@12.20.36.2) has joined #fluid-work
[11:03:19 EDT(-0400)] <Bosmo1> OK
[11:03:24 EDT(-0400)] <Bosmo1> It looks like I am really here
[11:03:34 EDT(-0400)] <michelled> hi!
[11:03:46 EDT(-0400)] <Bosmo1> Yes, it really is like the Sir Seretse Khama Airport in here
[11:05:27 EDT(-0400)] <michelled> Bosmo1: it might be useful to distinguish between things components are built out of and the components themselves. I think the Reorderer is the former.
[11:06:37 EDT(-0400)] <Bosmo1> Well
[11:06:40 EDT(-0400)] <Bosmo1> I don't agree
[11:06:46 EDT(-0400)] <Bosmo1> Everything is "stuff"....
[11:07:57 EDT(-0400)] <michelled> hard to disagree with that
[11:10:08 EDT(-0400)] <Bosmo1> hah
[11:10:58 EDT(-0400)] <Bosmo1> Yes, in terms of Colin's earlier discussion I/we are thinking about ways that the template parser/renderer itself could be driven by such "interesting thing maps"
[11:11:09 EDT(-0400)] <Bosmo1> With rsf:ids then appearing as just a "special case" of that
[11:11:25 EDT(-0400)] <Bosmo1> Of course as I mentioned earlier the necessary consequence of this is to IMPLEMENT OUR OWN SELECTOR ENGINE!!!
[11:13:03 EDT(-0400)] * colinclark (n=colin@12.20.36.16) has joined #fluid-work
[11:14:50 EDT(-0400)] <michelled> colinclark: I think you missed Bosmo1's last message:
[11:15:01 EDT(-0400)] <michelled> "Of course as I mentioned earlier the necessary consequence of this is to IMPLEMENT OUR OWN SELECTOR ENGINE!!!"
[11:15:23 EDT(-0400)] <colinclark> michelled: He's beginning to make sense in his argument about this point.
[11:15:31 EDT(-0400)] <colinclark> Shudder to think.
[11:15:32 EDT(-0400)] <colinclark>
[11:15:36 EDT(-0400)] <Bosmo1> hah
[11:15:46 EDT(-0400)] <Bosmo1> He only considers this because I promised him Scotch
[11:15:56 EDT(-0400)] <Bosmo1> Also, because I explained it to him in the lift
[11:15:58 EDT(-0400)] <colinclark> lol
[11:16:07 EDT(-0400)] <michelled>
[12:03:21 EDT(-0400)] * simonwang (n=chatzill@swang.itservices.ubc.ca) has joined #fluid-work
[12:25:55 EDT(-0400)] * colinclark (n=colin@12.20.36.16) has joined #fluid-work
[14:03:28 EDT(-0400)] * colinclark (n=colin@12.20.36.16) has joined #fluid-work
[14:29:51 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[15:06:48 EDT(-0400)] * colinclark (n=colin@12.20.36.16) has joined #fluid-work
[15:25:52 EDT(-0400)] * colinclark (n=colin@12.20.36.16) has joined #fluid-work
[16:01:37 EDT(-0400)] * aaronlev (n=chatzill@pD9E4E109.dip.t-dialin.net) has joined #fluid-work
[16:39:58 EDT(-0400)] * colinclark (n=colin@12.20.36.16) has joined #fluid-work
[17:45:26 EDT(-0400)] * colinclark (n=colin@12.20.36.16) has joined #fluid-work
[17:49:51 EDT(-0400)] * theclown_afk (n=theclown@142.150.154.101) has left #fluid-work
[17:55:02 EDT(-0400)] * colinclark (n=colin@12.20.36.16) has joined #fluid-work
[17:56:31 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[18:19:00 EDT(-0400)] * slightlyoff (n=alex@204.14.154.209) has left #fluid-work
[22:16:23 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[22:29:29 EDT(-0400)] * colinclark (n=colin@12.20.36.16) has joined #fluid-work