fluid-work IRC Logs-2011-02-10

Owned by Fluid IRC Log Bot
Last updated: Feb 10, 2011Version comment
19 min read

[08:09:26 CST(-0600)] <jhung> ping jameswy, justin_o: do any of you have time to do a card sort of the Fluid Infusion components?
[08:09:48 CST(-0600)] <Justin_o> jhung: what do you mean by card sort?
[08:10:15 CST(-0600)] <jhung> justin_o: taking the pile and sorting into categories / classifications.
[08:10:38 CST(-0600)] <jhung> I'm trying to figure out a good grouping of components to put onto the Builder.
[08:10:57 CST(-0600)] <jameswy> jhung: What would you say is the issue with the current sorting?
[08:12:24 CST(-0600)] <jhung> jameswy: just want to make sure it's fine. One controversy may be with the categorization of UI Options as "Presentation" rather than "Interaction"
[08:14:57 CST(-0600)] <jhung> So I currently have this categorization:
[08:15:07 CST(-0600)] <jhung> Core: Infusion Framework, Renderer, FSS, and Progressive Enhancement.
[08:15:21 CST(-0600)] <jhung> Presentation: Table of Contents, User Interface Options.
[08:15:29 CST(-0600)] <jhung> Interaction: Inline Edit, Pager, Progress, Reorderer, Uploader.
[08:15:37 CST(-0600)] <jhung> Supporting: Tooltip, Undo.
[08:15:43 CST(-0600)] <jhung> Third Party: All the rest...
[08:16:20 CST(-0600)] <jameswy> Hm...
[08:16:57 CST(-0600)] <jameswy> Justin_o: Thoughts on the current categorization?
[08:18:20 CST(-0600)] <Justin_o> jameswy: as for the organization that jhung just mentioned i'm not sure that UI Options isn't interactive for example.. it cuts across. I think presentation sounds more like FSS
[08:18:51 CST(-0600)] <Justin_o> I think the current layout out on builder.fluidproject.org is fine.. but i guess you could add subsections if you wanted to break up our widgets more
[08:19:03 CST(-0600)] <Justin_o> components
[08:19:53 CST(-0600)] <jameswy> I'm inclined to agree-TOC and UIO both have interactions within them-as does Undo.
[08:20:46 CST(-0600)] <jhung> Do you think users will be confused that UIO isn't interactive?
[08:21:17 CST(-0600)] <jameswy> I think I'm confused right now. UIO is interactive, no?
[08:21:52 CST(-0600)] <jhung> Yes, I agree. But do you think a user would be confused that it isn't by looking at the Builder?
[08:22:49 CST(-0600)] <jhung> *using the v2.0 builder categorization
[08:23:02 CST(-0600)] <jameswy> I think a developer would need to try and interpret what we mean by "presentation" and "interaction". It's not part of our core vocabulary anywhere else.
[08:23:24 CST(-0600)] <jameswy> So if we head in that direction, we'll certainly need to make a community shift toward it. It's a big question.
[08:23:51 CST(-0600)] <jameswy> Are our components indeed "presentation" vs "interaction"?
[08:24:33 CST(-0600)] <jhung> Or, is there a better way to categorize these components?
[08:26:26 CST(-0600)] <jameswy> Hm.
[08:28:16 CST(-0600)] <jameswy> Off the top my head, I'm not sure--let's chat about this with Justin in say an hour?
[08:29:30 CST(-0600)] <jhung> Sure.
[08:29:53 CST(-0600)] <jameswy> Justin_o: ^
[08:34:42 CST(-0600)] <Justin_o> jameswy, jhung: sure let me know when you guys are ready
[09:20:42 CST(-0600)] <heidi_> hey colinclark i was thinking about starting the rich dropdown component, but justin_o mentioned a similar filament group UI bit we might want to use?
[09:21:16 CST(-0600)] <colinclark> yep
[09:22:13 CST(-0600)] <colinclark> If I remember, this is the one: http://www.filamentgroup.com/lab/jquery_ipod_style_and_flyout_menus/
[09:22:22 CST(-0600)] <colinclark> I assume it's covered in the Filament Group's book
[09:22:22 CST(-0600)] <colinclark> the
[09:22:29 CST(-0600)] <colinclark> Progressive Enhancement one
[09:23:13 CST(-0600)] <heidi_> okay, thanks
[09:23:25 CST(-0600)] <heidi_> ill prob pick something else for tutorials... hm
[09:23:34 CST(-0600)] <colinclark> There's also this one: http://www.filamentgroup.com/lab/jquery_ui_selectmenu_an_aria_accessible_plugin_for_styling_a_html_select/
[09:23:41 CST(-0600)] <heidi_> putting jameswy's framework demo wireframes on wiki
[09:23:45 CST(-0600)] <colinclark> I think, actually, this is the one
[09:24:01 CST(-0600)] <colinclark> "We recently contributed a number of our own plugins to the jQuery UI labs repository, a new branch of the jQuery UI project dedicated to future plugin development. Our latest contribution to labs is the selectmenu plugin, which is designed to duplicate and extend the functionality of a native HTML select element, and lets you customize the look and feel, add icons, and create hierarchy within the options"
[09:24:31 CST(-0600)] <heidi_> ah cool
[09:26:09 CST(-0600)] <colinclark> I think one of the keys, heidi_, is to pick something that we don't necessarily want to put into production
[09:26:24 CST(-0600)] <heidi_> yeah, a 'hello world'
[09:26:33 CST(-0600)] <colinclark> As I say, all the little, subtle, complex details of making an awesome UX will end up being tons of work
[09:26:45 CST(-0600)] <colinclark> good work, but perhaps a distraction from learning the mechanics
[09:26:51 CST(-0600)] <heidi_> i hear ya
[09:27:17 CST(-0600)] <colinclark> Is there anything within James' demo wireframes that looks small, that you could start with?
[09:28:45 CST(-0600)] <colinclark> I really like this Filament Group selectmenu
[09:28:48 CST(-0600)] <colinclark> super cool
[09:29:07 CST(-0600)] <colinclark> I can imagine, Justin_o, that it will be pretty easy to integrate it into Inline Edit
[09:29:25 CST(-0600)] <heidi_> yeah me too - UIOptions will make good use of that
[09:29:31 CST(-0600)] <colinclark> for sure
[09:29:34 CST(-0600)] <heidi_> http://wiki.fluidproject.org/display/fluid/Framework+Demo+%28wireframes%29
[09:30:46 CST(-0600)] <colinclark> heidi_: It seems like the bar graph might be a fairly simple component to build
[09:31:16 CST(-0600)] <heidi_> yeah, cool. i lik bar graphs
[09:31:31 CST(-0600)] <Justin_o> colinclark: that's good.. then we can have a working implementation of drop down inline edit
[09:36:48 CST(-0600)] <heidi_> colinclark yeah i like bar graph too cos it can grow to show other parts of the framework... renderer etc
[09:37:14 CST(-0600)] <colinclark> (smile)
[09:37:40 CST(-0600)] <heidi_> okay cool rubs hands together , create component time...
[09:38:33 CST(-0600)] <Justin_o> michelled: you can do a git log for a specific svn commit by doing something like this
[09:38:54 CST(-0600)] <Justin_o> git log --grep=revision=10483 where 10483 is the revision you are interested in
[09:39:11 CST(-0600)] <jameswy> Justin_o, jhung: shall we chat about those component cats?
[09:39:23 CST(-0600)] <Justin_o> sure
[09:39:30 CST(-0600)] <colinclark> Cats, as components?!?
[09:39:49 CST(-0600)] <colinclark> their data models must be chicken
[09:40:02 CST(-0600)] <Justin_o> yummy data models
[09:40:08 CST(-0600)] <colinclark> lol
[09:40:15 CST(-0600)] <jameswy> Cats taste like chicken...?
[09:40:17 CST(-0600)] <jameswy> I'm confused.
[09:40:51 CST(-0600)] <jameswy> Ahh, cats eat chicken.
[09:40:52 CST(-0600)] <jhung> Some taste like frog legs.
[09:41:20 CST(-0600)] <jhung> ... from what I hear anyway. Honest.
[09:41:54 CST(-0600)] <jhung> jameswy, justin_o: yes, let's chat about component cats.
[09:45:43 CST(-0600)] <jhung> http://jqueryui.com/download
[10:24:06 CST(-0600)] <heidi_> michelled here's a branch (warning) for FLUID-3887 https://github.com/heidiv/infusion/tree/FLUID-3887
[10:25:57 CST(-0600)] <michelled> thx heidi_ - can you put a link to it on the JIRA if you haven't already?
[13:12:25 CST(-0600)] <harriswong> jhung: ping
[13:12:33 CST(-0600)] <jhung> harriswong: hey
[13:13:05 CST(-0600)] <harriswong> jhung: Do you have a few mins for a question on pager demo?
[13:13:14 CST(-0600)] <jhung> sure
[13:13:39 CST(-0600)] <harriswong> jhung: when I click on page 6, the pages show : 1 2 3 ... 5 6 7 ...
[13:13:55 CST(-0600)] <harriswong> jhung: I was wondering if the "4" should be showing in this case?
[13:14:57 CST(-0600)] <jhung> Yeah, that's a bit confusing when using the gapped strategy.
[13:15:22 CST(-0600)] <harriswong> jhung: based on the functional spec of the gappedStrategy, it is indeed correct to have 3 in front, and 1 before currentItem.
[13:15:42 CST(-0600)] <jhung> harriswong: yes. But it doesn't make much sense.
[13:15:48 CST(-0600)] <harriswong> jhung: yea.
[13:16:17 CST(-0600)] <jhung> I think this should be a special case where if only 1 page is being "gapped", then it should appear on the page navigation and not be replaced with "..."
[13:16:39 CST(-0600)] <michelled_> golam: I just commented on your commit on git hub: https://github.com/gchowdhury/infusion/commit/862489f6a2d412e2864c18c8c7b739c0c4d39628
[13:16:59 CST(-0600)] <michelled_> golam: if that wasn't the correct one to look at can you point me at the correct one?
[13:17:04 CST(-0600)] <golam> I just received your email
[13:17:20 CST(-0600)] <michelled_> ah, github is pinging you for me (smile)
[13:17:24 CST(-0600)] <harriswong> jhung: i agree.
[13:17:57 CST(-0600)] <harriswong> jhung: reason why I am asking is FLUID-4045 consistentGappedPageStrategy seems to have that exception
[13:17:59 CST(-0600)] <golam> michelled_: that was the correct branch
[13:19:04 CST(-0600)] <golam> michelled_: I did the test with IE and FF, both passed
[13:19:42 CST(-0600)] <jhung> harriswong: that's good. We should use it.
[13:20:04 CST(-0600)] <harriswong> Ok
[13:20:19 CST(-0600)] <jhung> jameswy: ping. Do you agree? ^
[13:20:29 CST(-0600)] <golam> michelled_: just one to get one thing clear, I shouldn't use the util object and expand the options object instead?
[13:37:35 CST(-0600)] <jhung> harriswong: looks like jameswy is in a meeting. I think it's safe to go ahead with adding the exception to the gapped strategy.
[13:38:17 CST(-0600)] <harriswong> jhung: should i fire a jira for htis?
[13:38:18 CST(-0600)] <harriswong> this*
[13:50:28 CST(-0600)] <michelled_> golam: are the things in the 'util' object required?
[13:51:44 CST(-0600)] <jhung> harriswong: there may be a jira already. Double-check. File one if not.
[13:53:16 CST(-0600)] <harriswong> k
[13:53:57 CST(-0600)] <golam> michelled_: some of them are required such as the counter
[13:54:37 CST(-0600)] <golam> michelled_: let me see if I can work with out them
[13:54:41 CST(-0600)] <michelled_> so, what does counter mean in terms of the function? it seems to me that it's the number of items
[13:54:54 CST(-0600)] <jameswy> harriswong, jhung: Yes, definitely go ahead with the exception.
[13:55:10 CST(-0600)] <jameswy> Both of you are right that it's entirely awkward otherwise.
[13:55:14 CST(-0600)] <golam> michelled_: number of items
[13:55:36 CST(-0600)] <michelled_> what I'm trying to get at, golam, is that the word 'util' isn't going to mean much to people. The things inside it, if they are required could become top level parameters
[13:56:09 CST(-0600)] <harriswong> jameswy: ok.
[13:57:01 CST(-0600)] <michelled_> if they are not required, they could go into options since that is a common strategy we use throughout fluid and a future maintainer of the code would know to look at what the possible values inside options are
[13:57:23 CST(-0600)] <michelled_> golam: does that make sense?
[13:58:06 CST(-0600)] <golam> michelled_: yes
[13:58:34 CST(-0600)] <michelled_> so perhaps a signature that looks like this: checkTabIndex(containerId, portletId, numPortlets, options)
[13:59:51 CST(-0600)] <golam> michelled_: I used the util object to store containerId, portletId, numPortlets.
[13:59:59 CST(-0600)] <michelled_> golam: also, can you please add the JIRA number to the beginning of your commit messages?
[14:00:32 CST(-0600)] <golam> michelled_: sure
[14:00:54 CST(-0600)] <justin_o> colinclark, michelled_ , Bosmon : here github's page on pull requests
[14:00:56 CST(-0600)] <justin_o> http://help.github.com/pull-requests/
[14:01:23 CST(-0600)] <justin_o> here's an interesting part about accepting the pull
[14:01:25 CST(-0600)] <justin_o> "The fetch and merge approach works great when you’re working on a team or repeatedly applying changes from the same small group of people. Another approach that’s a bit quicker in one-off cases is to use git-am.
[14:01:25 CST(-0600)] <justin_o> Every pull request has a .patch URL where you can grab a textual patch file to feed into the git-am command:"
[14:12:48 CST(-0600)] <Bosmon> am?!
[14:13:12 CST(-0600)] <michelled_> golam: it was actually colinclark that made me think pretty hard about some of my code years ago that I wanted to put under the name 'utilities'. His argument, which I eventually agreed with, is that if I want to call something 'utility' then maybe I don't quite know what it is yet
[14:13:34 CST(-0600)] <michelled_> golam: meaning that it become opaque to a future maintainer.
[14:13:48 CST(-0600)] <Bosmon> The same, btw, applies to anything named "manager", "service", or "object" (tongue)
[14:13:59 CST(-0600)] <michelled_> michelled_: as long as I'm working on the code base, I'm good, for that matter I can call it 'x' and be happy
[14:14:07 CST(-0600)] <michelled_> oops, talking to myself
[14:14:31 CST(-0600)] <golam> michelled_: got it, have to be specific so others can understand.
[14:14:39 CST(-0600)] <michelled_> yep (smile)
[14:15:25 CST(-0600)] <golam> michelled_: I am fetching the branch so I can make the changes and push it back in.
[14:15:56 CST(-0600)] <michelled_> thanks golam
[14:16:28 CST(-0600)] <Bosmon> justin_o: Would you like to talk about the 1.3.1 release?
[14:16:31 CST(-0600)] <golam> michelled_: This time I won't forget to add the jira name in the commit message.
[14:17:34 CST(-0600)] <justin_o> Bosmon: sure
[14:17:48 CST(-0600)] <justin_o> i guess we needed to chat about the change to get
[14:25:51 CST(-0600)] <Bosmon> yes
[14:26:13 CST(-0600)] <Bosmon> So, I had a chat with colinclark, where he suggested we have this chat (smile)
[14:26:22 CST(-0600)] <justin_o> chatting about chatting
[14:26:27 CST(-0600)] <Bosmon> Yes
[14:27:03 CST(-0600)] <Bosmon> He said you would not want to do a full QA cycle for this release, which I would like to convince you isn't necessary to verify this change (tongue)
[14:27:08 CST(-0600)] <Bosmon> Although these arguments are as always tricky
[14:27:56 CST(-0600)] <Bosmon> Given there is no alteration in behaviour for those clients who i) only use Strings as EL, and ii) don't use any resolvers or strategies, I argue that none of the components which don't use IoC need to be retested for this change
[14:28:11 CST(-0600)] <Bosmon> Which only leaves... the Reorderer, and the Uploader... which I believe are both being retested for this cycle anyway
[14:29:03 CST(-0600)] <justin_o> Bosmon: we were only going to do some minor testing on Layout Reorderer, but i guess we will actually have to thoroughly test the whole family...
[14:29:19 CST(-0600)] <justin_o> but back to the more direct topic
[14:29:56 CST(-0600)] <justin_o> there was a change to get, how is that change such that it cannot affect any other code using it
[14:32:01 CST(-0600)] <Bosmon> I argue, because after the change, the same code is executing in these cases
[14:32:16 CST(-0600)] <Bosmon> I didn't change any of the code or algorithms that cover the cases these users were executing
[14:32:52 CST(-0600)] <Bosmon> Also - the unit tests support the idea that this is so (tongue)
[14:42:50 CST(-0600)] <justin_o> (smile) unit tests are good, but you must have something in the code that directs the logic between strings vs object
[14:43:12 CST(-0600)] <justin_o> Bosmon: ^
[14:44:11 CST(-0600)] <justin_o> so i guess this trundle thing is what's new
[14:50:30 CST(-0600)] <Bosmon> Yes, the trundlers are new
[14:51:24 CST(-0600)] <heidi_> bosmon , justin_o does this sentence make sense: We use the word component to talk about our library of accessible user interfaces (Uploader, Progress Bar, Inline Edit), but in reality a 'component' can refer to any specifically structured, configurable chunk of related functionality.
[14:51:26 CST(-0600)] <justin_o> Bosmon: are they a whole new code path though, that anything using get would have to go through
[14:52:27 CST(-0600)] <heidi_> or i guess, how would you define 'component'
[14:55:06 CST(-0600)] <heidi_> justin_o is explaining there are currently 3 types of components, so defining it by its structure isn't necessarily right
[14:55:41 CST(-0600)] <Bosmon> justin_o: Currently all code paths use "trundlers" yes, but they simply repackage the same implementation that we had before
[14:56:24 CST(-0600)] <Bosmon> heidi_: A lot depends on who you are trying to inform, and about what (tongue)
[14:56:32 CST(-0600)] <Bosmon> We use the word "component" in a lot of senses in Fluid, unfortunately
[14:56:54 CST(-0600)] <heidi_> yeah there are many connotations - so no general definition?
[14:57:39 CST(-0600)] <justin_o> Bosmon: in regards to the trundlers, isn't it possible that this new packaging could have bugs... ones that the unit tests may have missed.. i'm guessing you are saying thought that all of the unit tests are passing without you having to change them
[14:58:36 CST(-0600)] <Bosmon> justin_o: It is possible yes - but the unit tests for that functionality are "quite complete"
[14:58:43 CST(-0600)] <Bosmon> I guess one can never know (tongue)
[14:58:59 CST(-0600)] <Bosmon> But to me it seems very unlikely there are "new bugs" because there isn't any "new implementation"
[14:59:23 CST(-0600)] <colinclark> heidi_, Bosmon: Let me have a look on the wiki to see how we've defined components in the past
[14:59:43 CST(-0600)] <justin_o> Bosmon: okay.. so what is get used for across all the components
[14:59:50 CST(-0600)] <colinclark> There is an increasing ambiguity with this name over time, as the flavours of components we build become more varied
[14:59:50 CST(-0600)] <justin_o> if you happen to know off hand (smile)
[15:00:01 CST(-0600)] <colinclark> But I can take a stab at trying to define it for you, heidi_
[15:00:03 CST(-0600)] <colinclark> just gimme one sec
[15:00:10 CST(-0600)] <heidi_> Components are reusable chunks of UI real estate that can be plugged into compatible web applications.
[15:00:18 CST(-0600)] <Bosmon> Well, it is used by any of them to access their models.... it is used within the framework during options merging.... it is used in the ChangeApplier
[15:00:21 CST(-0600)] <Bosmon> Any number of places
[15:00:30 CST(-0600)] <justin_o> colinclark: i was just thinking aloud that the commonality between all our component types is the options merging
[15:00:43 CST(-0600)] <Bosmon> All of these places, however, except for the one in IoC, use the "flat" model for accessing state that we had before
[15:00:47 CST(-0600)] <heidi_> i think of them as highly configurable building blocks/legos
[15:00:49 CST(-0600)] <colinclark> heidi_: I can tell I wrote something like that once, years ago (tongue)
[15:01:06 CST(-0600)] <heidi_> yeah its from the wiki http://wiki.fluidproject.org/display/fluid/Components#Components-whatiscomponent
[15:01:29 CST(-0600)] <justin_o> Bosmon: right... so if we had to test everything... if it wasn't working.. would everything just explode
[15:01:40 CST(-0600)] <justin_o> or would there likely be subtle failures that may be hard to notice
[15:01:46 CST(-0600)] <colinclark> justin_o's right that, in some basic sense (at the moment), components are objects that support options...
[15:02:00 CST(-0600)] <colinclark> But this might be sort of a symptom rather than the underlying pathology (smile)
[15:02:08 CST(-0600)] <heidi_> Bosmon i'm just trying to explain to someone coming newly to Infusion wanting to "create a component" what that means, and how it's reasonable to expect it'll be made of components
[15:02:20 CST(-0600)] <heidi_> and why that makes sense
[15:02:46 CST(-0600)] <colinclark> yep
[15:02:54 CST(-0600)] <colinclark> okay, let's start from scratch here, and see what we can figure out
[15:02:55 CST(-0600)] <Bosmon> Yes - certainly our "top-level components" are something more definable than others
[15:03:03 CST(-0600)] <colinclark> So, we've been using some terminology a bit loosely
[15:03:17 CST(-0600)] <Bosmon> Things like the Reorderer, the Uploader, the Pager, are things you can "whack your knuckles on" and see them do something (tongue)
[15:03:18 CST(-0600)] <colinclark> We refer to things as "thats," which is a term I have always hated
[15:03:26 CST(-0600)] <Bosmon> Although more specifically these are what we refer to as "View Components"
[15:03:35 CST(-0600)] <colinclark> ah, i'll shut up
[15:03:38 CST(-0600)] <Bosmon> They occupy a definite piece of the DOM and have some kind of definite behaviour and markup
[15:03:39 CST(-0600)] <Bosmon> Sorry
[15:03:43 CST(-0600)] <Bosmon> Didn't mean to talk over you, carry on (smile)
[15:03:43 CST(-0600)] <colinclark> both of us talking from different directions will be exceedingly confusing
[15:03:45 CST(-0600)] <colinclark> keep going, Bosmon
[15:03:49 CST(-0600)] <colinclark> it's totally fine (smile)
[15:03:55 CST(-0600)] <heidi_> colinclark don't shut up!
[15:04:34 CST(-0600)] <heidi_> Bosmon "view components" is sorta helpful in separating the diff connotations...
[15:04:53 CST(-0600)] <heidi_> justin_o says we have view, little, and renderer components so far
[15:05:10 CST(-0600)] <heidi_> which all are things with options
[15:05:20 CST(-0600)] <Bosmon> Yes - renderer components are kinds of view components which use the renderer in a particularly packaged way
[15:05:35 CST(-0600)] <Bosmon> To our users, they will typically only be interested in "view components" since they are mostly interested in things they can see and use (tongue)
[15:05:49 CST(-0600)] <Bosmon> But all the same there are many other different kinds of "components" in our framework
[15:05:58 CST(-0600)] <heidi_> Bosmon but what about creators
[15:06:09 CST(-0600)] <Bosmon> creators are the functions which return components
[15:06:20 CST(-0600)] <heidi_> sorry I meant people creators... of new components
[15:06:21 CST(-0600)] <Bosmon> In the previous, "object-oriented" terminology these used to be called "constructors"
[15:06:25 CST(-0600)] <Bosmon> Oh, I see (smile)
[15:06:53 CST(-0600)] <Bosmon> People creators might want to create all kinds of components (tongue)
[15:07:02 CST(-0600)] <heidi_> indeed!
[15:07:17 CST(-0600)] <heidi_> so how to explain what a component actually is...
[15:07:37 CST(-0600)] <Bosmon> The way we deal with "components" in Fluid is somewhat different to other communities,in that we except that essentially EVERYTHING about the component might need to change
[15:07:49 CST(-0600)] <Bosmon> It is a way of building things that is still a bit unfamiliar
[15:07:53 CST(-0600)] <Bosmon> So consider the "Reorderer", for example
[15:08:08 CST(-0600)] <Bosmon> This could "look like anything", and "behave like anything".... within certain bounds
[15:08:27 CST(-0600)] <heidi_> that helps, keep going
[15:08:28 CST(-0600)] <Bosmon> But there is a certain core of "Reorderiness" to it that is captured by the component that we call the Reorderer
[15:08:39 CST(-0600)] <Bosmon> To our users, this might actually appear as half a dozen "real components"
[15:08:44 CST(-0600)] <heidi_> what defines that core?
[15:08:52 CST(-0600)] <Bosmon> For example, we tell our users that there is a component called the "Layout Reorderer" and the "Image Reorderer"
[15:08:55 CST(-0600)] <Bosmon> But really, there isn't
[15:09:08 CST(-0600)] <Bosmon> Well, there is an entry point, a "creator function" called "fluid.reorderer"
[15:09:19 CST(-0600)] <Bosmon> It is given a block of configuration that tells it what kind of reorderer to make
[15:09:33 CST(-0600)] <Bosmon> And depending on that configuration, it makes "any one of a number of quite different things"
[15:09:55 CST(-0600)] <heidi_> so it's
[15:09:59 CST(-0600)] <heidi_> a malleable shell of a thing
[15:10:10 CST(-0600)] <Bosmon> But to help our users out to understand better what they are getting, we "pre-roll" various packages of the reorderer
[15:10:12 CST(-0600)] <heidi_> or a malleable shell period
[15:10:19 CST(-0600)] <Bosmon> And give them their own names, and give them their own entry points
[15:10:26 CST(-0600)] <heidi_> right, a filled in shell
[15:10:29 CST(-0600)] <colinclark> I guess that gets us close to a baseline for the question "what is a component?"
[15:10:29 CST(-0600)] <Bosmon> So for example, we claim there really IS a thing by the name of "fluid.imageReorderer"
[15:10:38 CST(-0600)] <Bosmon> And as far as our users know, there really is
[15:10:44 CST(-0600)] <colinclark> It's an object that, by design, is capable of being configured by the user
[15:10:44 CST(-0600)] <Bosmon> They can call that function and get an Image Reorderer
[15:11:05 CST(-0600)] <Bosmon> This is how "traditional component frameworks" work - and it is a useful way of talking about things, to a certain audience
[15:11:23 CST(-0600)] <Bosmon> But we understand that it is not a sensible way to meet the needs of a very wide audience of different users
[15:11:39 CST(-0600)] <Bosmon> We can't actually IMPLEMENT a fresh component for every possible combination of users needs
[15:11:47 CST(-0600)] <Bosmon> So.... we arrange them in these "families"
[15:12:12 CST(-0600)] <heidi_> and what defines the relation is...
[15:12:23 CST(-0600)] <Bosmon> And if you look at what you find in one of these "families" more closely, you find it looks more like a "build your own kit" of parts, that you can put together in many different orders
[15:12:43 CST(-0600)] <Bosmon> Like the legendary SIR CLIVE SINCLAIR, we deliver things to our users BOTH in kit form, AND in ready-assembled form
[15:12:46 CST(-0600)] <heidi_> reminding me of fractals
[15:12:49 CST(-0600)] <Bosmon> So that we can cater for different audiences (tongue)
[15:13:29 CST(-0600)] <heidi_> assembled vs kit - that's a super helpful analogy
[15:13:34 CST(-0600)] <Bosmon> So yes, this is the sense in which the word "component" has some different meanings
[15:13:47 CST(-0600)] <Bosmon> The difference is... with our "assembled kits", you can still see all the joins - if you want to
[15:13:54 CST(-0600)] <Bosmon> Or you can decide not to see them, if you don't want
[15:14:10 CST(-0600)] <Bosmon> With a "traditional component framework", you just get the one component, perhaps with a few twiddlable knobs on it
[15:14:33 CST(-0600)] <Bosmon> Looking at "autocomplete widgets" is a good illustration of this
[15:14:40 CST(-0600)] <Bosmon> We needed a widget like this, for CollectionSpace
[15:14:45 CST(-0600)] <colinclark> heidi_: Clive Sinclair, by the way, was they guy who created the Sinclair ZX-81, Antranig's and my first computer. He's probably only famous in Britian.
[15:14:52 CST(-0600)] <colinclark> Or in certain basements in Colorado
[15:14:53 CST(-0600)] <Bosmon> We can dig up the wireframes the designers gave us if you are interested
[15:15:07 CST(-0600)] <heidi_> haha colinclark , thanks
[15:15:08 CST(-0600)] <Bosmon> But the designers specified an autocomplete widget that looks NOTHING like autocomplete widgets that people normally build
[15:15:20 CST(-0600)] <Bosmon> It had several extra controls on it, and various extra pieces to the workflow
[15:15:42 CST(-0600)] <Bosmon> YOU WOULD THINK..... that starting from some existing autocomplete widget would be a good starting point to implement this "improved widget"
[15:16:09 CST(-0600)] <Bosmon> but in fact, all of the existing ones were almost worst than starting from nothing at all - since - the "kit had already been assembled"
[15:16:21 CST(-0600)] <Bosmon> There was no way to see the "component parts" that the component was built with, to connect them up in a different way
[15:17:24 CST(-0600)] <Bosmon> http://wiki.collectionspace.org/display/collectionspace/Wireframes+-+Predictive+Text
[15:17:26 CST(-0600)] <Bosmon> Here it is
[15:17:47 CST(-0600)] <Bosmon> This is the design that Erin created....
[15:18:59 CST(-0600)] <Bosmon> So.... "is the CollectionSpace Autocomplete widget a component?" (tongue)
[15:19:05 CST(-0600)] <Bosmon> Clearly, to the users of CollectionSpace, it is....
[15:20:00 CST(-0600)] <heidi_> yeah i getcha
[15:20:28 CST(-0600)] <heidi_> hmm hmm and hmm
[15:20:30 CST(-0600)] <Bosmon> But if we just "implemented a component that is the CollectionSpace Autocomplete Widget", we would be doing our users, and our community, a disservice.....
[15:20:34 CST(-0600)] <colinclark> So, to summarize what I think we've covered:
[15:20:43 CST(-0600)] <colinclark> 1. Components are objects
[15:20:44 CST(-0600)] <heidi_> right
[15:21:09 CST(-0600)] <colinclark> 2. Components are designed to be configurable. They typically have default settings and can be overridden by user-specified options.
[15:21:20 CST(-0600)] <colinclark> 3. The framework does #2 for free for all components
[15:21:35 CST(-0600)] <colinclark> 4. Components are typically composed from a whole bunch of other, smaller components
[15:22:16 CST(-0600)] <colinclark> 5. Components aren't black boxes. They're things our users can easily disassemble, alter, and adapt (typically through the above-mentioned options)
[15:22:19 CST(-0600)] <colinclark> Does that seem about right?
[15:22:22 CST(-0600)] <heidi_> that sounds good colinclark
[15:22:51 CST(-0600)] <heidi_> and i might throw in the kit analogy: assembled or build-your-own, i like that..
[15:22:58 CST(-0600)] <colinclark> I guess the other point to make is that components are objects, but they might have a few special characteristics that distinguish them from how someone might typically make an object in Java or PHP or other languages
[15:23:17 CST(-0600)] <colinclark> They generally have public methods--functions you can call to do something interesting with the component
[15:23:24 CST(-0600)] <colinclark> the also typically have a model
[15:23:59 CST(-0600)] <colinclark> The difference between components and models in most other frameworks is that the model-the data and state of the component-is in a plain data structure and is visible to the outside world
[15:24:10 CST(-0600)] <colinclark> "Transparent state programming," as we've come to refer to it
[15:24:41 CST(-0600)] <colinclark> In ordinary frameworks, as Antranig said, authors go to great lengths to hide away ("encapsulate") all of the useful, interesting, interoperable parts of an object
[15:24:54 CST(-0600)] <colinclark> Hopefully that all seems about right
[15:25:01 CST(-0600)] <Bosmon> The key point in the "build your own" analogy... is that the SAME STRUCTURE can be seen as both the kit form, and the fully-assembled form, depending on how you look at it
[15:25:19 CST(-0600)] <colinclark> That's a nice way to think about it
[15:25:20 CST(-0600)] <Bosmon> We don't ship "different things" to our users depending on which they want to see.... there is just one structure
[15:25:21 CST(-0600)] <heidi_> yeah, the shell idea
[15:25:39 CST(-0600)] <colinclark> It's both a do it yourself kit AND a polished end-user product, at the same time!
[15:25:50 CST(-0600)] <Bosmon> This means, that at any stage the users decide that they want to break open the package, they can, without changing the thing they are dealing with
[15:25:58 CST(-0600)] <Bosmon> They don't need to ship it back to us for us to disassemble it (tongue)
[15:26:12 CST(-0600)] <colinclark> If we've done our job, that is (smile)
[15:26:19 CST(-0600)] <Bosmon> But they can carry on treating it as a package, for as long as they like
[15:26:58 CST(-0600)] <Bosmon> Yes... clearly the edges of this stuff are still a bit rickety, given it represents a formerly unrecognisable style of programming (tongue)
[15:27:56 CST(-0600)] <heidi_> Bosmon colinclark thanks so much for helping clarify this tricky little word
[15:28:02 CST(-0600)] <Bosmon> Not to say, something which in the real world is generally physically impossible
[15:28:04 CST(-0600)] <colinclark> hope it actually helps
[15:28:10 CST(-0600)] <colinclark> the other thing to be clear about is what a "that" is
[15:28:13 CST(-0600)] <colinclark> even though I hate the terminology
[15:28:14 CST(-0600)] <heidi_> clear as mud
[15:28:18 CST(-0600)] <colinclark> that should be documented in the wiki
[15:28:21 CST(-0600)] <Bosmon> If you ship people stuff which can disassemble into a kit, usually it would be something that would just fall to pieces in their hands (smile)
[15:28:44 CST(-0600)] <colinclark> in other words, "that-ism" will explain the characteristics of an object in Crockford's subset of JavaScript
[15:29:02 CST(-0600)] <heidi_> i saw this post: http://fluidproject.org/blog/2008/07/21/about-this-and-that/
[15:29:12 CST(-0600)] <colinclark> that is quite a post (smile)
[15:29:22 CST(-0600)] <colinclark> there should be some wiki-level documentation, too
[15:30:02 CST(-0600)] <heidi_> colinclark yes a little here http://wiki.fluidproject.org/display/fluid/Framework+Concepts
[15:31:13 CST(-0600)] <colinclark> cool
[15:31:29 CST(-0600)] <heidi_> "combinations of pure data and pure functions"
[15:31:41 CST(-0600)] <colinclark> nerdy!
[15:31:45 CST(-0600)] <Bosmon> Yes.... "and some other things" (tongue)
[15:31:49 CST(-0600)] <colinclark> but so true!
[15:32:33 CST(-0600)] <heidi_> hehe
[16:13:52 CST(-0600)] <justin_o> colinclark, Bosmon: i'm heading out.. wondering who's going to be reviewing the work that harris is doing to try to get eric's code in. I'm wondering if you will do it Bosmon since it has to do with pager.
[16:13:57 CST(-0600)] <justin_o> we can talk more about it tomorrow
[16:36:34 CST(-0600)] <golam> michelled_: Ran into some issues with git while working with two different branches. Here is my patch https://github.com/gchowdhury/infusion/blob/FLUID-3946
[16:38:01 CST(-0600)] <golam> michelled_: This is the file I have changed https://github.com/gchowdhury/infusion/blob/FLUID-3946/src/webapp/tests/component-tests/reorderer/js/LayoutReordererTests.js
[16:41:09 CST(-0600)] <michelled_> thanks golam - I'll have a look tomorrow
[16:41:41 CST(-0600)] <golam> michelled_: ok thanks