fluid-work IRC Logs-2009-03-31

[08:29:53 EDT(-0400)] * Justin_o (n=Justin@142.150.154.171) has joined #fluid-work
[08:33:37 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-69-153.dsl.mdsnwi.sbcglobal.net) has joined #fluid-work
[08:34:33 EDT(-0400)] * laurelw (n=Laurel@142.150.154.178) has joined #fluid-work
[08:42:22 EDT(-0400)] * anastasiac (n=stasia@142.150.154.189) has joined #fluid-work
[08:42:24 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176131209.dsl.bell.ca) has joined #fluid-work
[08:56:50 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-69-153.dsl.mdsnwi.sbcglobal.net) has joined #fluid-work
[09:08:46 EDT(-0400)] <Justin_o> anastasiac: when you have a chance, could you please review my commits for the pager class name changes...
[09:08:58 EDT(-0400)] <Justin_o> i'm going to start linting the js files now
[09:09:11 EDT(-0400)] <anastasiac> will do
[09:09:17 EDT(-0400)] <Justin_o> thanks
[09:15:28 EDT(-0400)] * athena (n=athena@dhcp128036158215.central.yale.edu) has joined #fluid-work
[09:20:08 EDT(-0400)] * athena (n=athena@dhcp128036158215.central.yale.edu) has joined #fluid-work
[09:32:35 EDT(-0400)] <athena> EricDalquist: does uPortal currently have any spring webmvc controllers?
[09:38:01 EDT(-0400)] * fj4000 (n=Jacob@142.150.154.106) has joined #fluid-work
[09:41:32 EDT(-0400)] <EricDalquist> athena: um ... maybe?
[09:41:59 EDT(-0400)] <athena> lol ok
[09:42:08 EDT(-0400)] <athena> and oops, wrong channel
[09:45:24 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176131209.dsl.bell.ca) has joined #fluid-work
[09:51:39 EDT(-0400)] * clown (n=clown@142.150.154.101) has joined #fluid-work
[09:59:36 EDT(-0400)] * clown (n=clown@142.150.154.101) has joined #fluid-work
[10:10:55 EDT(-0400)] * jessm (n=Jess@c-71-232-3-4.hsd1.ma.comcast.net) has joined #fluid-work
[10:29:08 EDT(-0400)] <Justin_o> Bosmon, fj4000, anastasiac: just a reminder that today is the last day for clean up, so we have to make sure that we get all of the tasks on the clean up parade done by the end business today.
[10:29:41 EDT(-0400)] <anastasiac> Jusin_o, thanks for the reminder!
[10:29:54 EDT(-0400)] <Justin_o> np
[10:49:37 EDT(-0400)] * michelled (n=team@142.150.154.193) has joined #fluid-work
[11:06:37 EDT(-0400)] * apetro (n=apetro@ip68-3-207-51.ph.ph.cox.net) has joined #fluid-work
[11:07:41 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176131209.dsl.bell.ca) has joined #fluid-work
[11:24:27 EDT(-0400)] <anastasiac> Justin_o, fj4000, Bosmon: I've updated the UIOptions/UIEnhancer classes and committed the changes
[11:24:39 EDT(-0400)] <Justin_o> anastasiac: thanks
[11:24:48 EDT(-0400)] <anastasiac> Justin_o: Should I be resolving the JIRA?
[11:24:55 EDT(-0400)] <fj4000> anastasiac, Justin_o, fj4000, Bosmon: i've updated Inline Edit too
[11:25:31 EDT(-0400)] <Justin_o> anastasiac: thanks sure
[11:27:05 EDT(-0400)] <anastasiac> I will look at the integration demos that are using flc- names for styling - they should probably be changed to use fl- names
[11:28:04 EDT(-0400)] <anastasiac> or their own classes...
[11:28:12 EDT(-0400)] <anastasiac> if no fl- names are appropriate
[11:35:13 EDT(-0400)] <anastasiac> fj4000: fss-states.css has a style for flc-reorderer-dropWarning
[11:35:27 EDT(-0400)] <fj4000> ach
[11:35:30 EDT(-0400)] <anastasiac> will/should that be moved into Reorderer.css and changed to fl-reorderer-dropWarning
[11:35:33 EDT(-0400)] <anastasiac> ?
[11:35:37 EDT(-0400)] <fj4000> ok, I should get to refactoring reorderer then
[11:35:52 EDT(-0400)] <anastasiac> Bosmon worked on Reorderer last night, so there shouldn't be much to do
[11:36:16 EDT(-0400)] <fj4000> ok
[12:04:58 EDT(-0400)] <anastasiac> Justin_o, the Undo subcomponent uses some classes that are not yet under the new naming scheme - can I create a JIRA for fixing that, as a sub-task of the 'renaming classes' JIRA?
[12:05:12 EDT(-0400)] <Justin_o> yes please do... thanks
[12:10:56 EDT(-0400)] <jessm> how is the DARApplier different from UIEnhancer in function y'all?
[12:13:11 EDT(-0400)] <jessm> DARApplier smells bigger
[12:14:05 EDT(-0400)] <jessm> is UIEnhancer DARApplier's baby?
[12:16:49 EDT(-0400)] <Justin_o> anastasiac: I think i have all of pager's class names changed, do you mind taking a look at it when you have a chance
[12:17:20 EDT(-0400)] <anastasiac> Justin_o, sure
[12:17:35 EDT(-0400)] <Justin_o> thanks, hopefully this time i didn't miss half of them
[12:17:44 EDT(-0400)] <anastasiac> jessm, the DARApplier and UIEnhancer are on completely different planets
[12:18:03 EDT(-0400)] <anastasiac> UIEnhancer applies a set of UI preferences to the interface, through styling, etc
[12:18:09 EDT(-0400)] <jessm> DARApplier lives close to the sun, UIEnhancer to the user?
[12:18:24 EDT(-0400)] <anastasiac> the DARApplier is an internal thing that controls access to an internal model
[12:18:49 EDT(-0400)] <anastasiac> yes, and they do different things
[12:18:56 EDT(-0400)] <jessm> model > system that makes data changes, propagates them, and notifies about it?
[12:19:22 EDT(-0400)] <anastasiac> that's about right
[12:21:20 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-69.LIPS.Berkeley.EDU) has joined #fluid-work
[12:23:12 EDT(-0400)] <ecochran> fj4000: do we need to talk about Progress?
[12:23:33 EDT(-0400)] <fj4000> if you dont mind, yes
[12:23:52 EDT(-0400)] <fj4000> i had some ideas from a while back, and I would like to harmonize them with what you already have
[12:25:06 EDT(-0400)] <ecochran> I have to run to a meeting in 6 minutes... shall we jump on Skype or Breeze
[12:25:49 EDT(-0400)] <fj4000> should we talk when you have more time?
[12:26:13 EDT(-0400)] <ecochran> OK, I'll be back in 1 to 1.5 hours
[12:26:26 EDT(-0400)] <ecochran> I'll be online during the meeting though... just won't be able to talk
[12:29:48 EDT(-0400)] <fj4000> ok
[12:31:23 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[12:33:04 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[12:35:25 EDT(-0400)] * ecochran_ (n=ecochran@dwin-wlan-342.AirBears.Berkeley.EDU) has joined #fluid-work
[12:50:36 EDT(-0400)] * jessm (n=Jess@c-71-232-3-4.hsd1.ma.comcast.net) has joined #fluid-work
[12:55:56 EDT(-0400)] <anastasiac> Justin_o, fj4000, ecochran, Bosmon: I've updated the Undo class names
[12:56:09 EDT(-0400)] <fj4000> ok
[12:56:18 EDT(-0400)] <Justin_o> anastasiac: thanks
[12:56:52 EDT(-0400)] <anastasiac> jessm: sorry to miss your question: No: UIEnhancer is not DARApplier's baby. The two are quite independent
[12:57:19 EDT(-0400)] <jessm> anastasiac: no worries – that quex was part of my question blob – i think you answered it
[12:57:27 EDT(-0400)] <anastasiac> ok, good
[13:20:10 EDT(-0400)] * apetro (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[13:23:53 EDT(-0400)] <anastasiac> Bosmon, do you have a moment for a Pager question?
[13:24:22 EDT(-0400)] <anastasiac> do you remember what the purpose of the "headerSortStylisticOffset" selector was?
[13:25:30 EDT(-0400)] <anastasiac> Justin_o, other than the headerSortStylisticOffset, the Pager styles look pretty good to me
[13:26:16 EDT(-0400)] <Justin_o> i'm not 100% sure... i'm guessing it has to do with using the header to adjust the sort of the contents that are paged
[13:26:38 EDT(-0400)] <anastasiac> yes, but the question is, why can't we use a flc- class name for it?
[13:26:48 EDT(-0400)] <anastasiac> maybe we can, but without truly understanding it...
[13:26:55 EDT(-0400)] <anastasiac> hence the Q for Bosmon
[13:26:55 EDT(-0400)] <Justin_o> ah yes... i see what you are saying...
[13:27:37 EDT(-0400)] <Justin_o> i didn't discover the answer to that
[13:27:46 EDT(-0400)] <anastasiac>
[13:28:16 EDT(-0400)] <Justin_o> anastasiac: by the way, i'm linting pager as we speak... I haven't finished yet but let me know if I'm interfering with any of your changes
[13:28:39 EDT(-0400)] <anastasiac> ok - no changes yet, but I was considering trying a class name...
[13:28:45 EDT(-0400)] <anastasiac> go ahead, don't mind me
[13:33:22 EDT(-0400)] * athena (n=athena@dhcp128036007132.central.yale.edu) has joined #fluid-work
[13:35:52 EDT(-0400)] * ecochran (n=ecochran@dwin-wlan-342.AirBears.Berkeley.EDU) has joined #fluid-work
[13:36:16 EDT(-0400)] * ecochran_ (n=ecochran@dhcp-169-229-212-56.LIPS.Berkeley.EDU) has joined #fluid-work
[13:37:24 EDT(-0400)] <ecochran_> fj4000: O
[13:37:29 EDT(-0400)] <ecochran_> ,I'm back
[13:37:33 EDT(-0400)] <ecochran_> odd typo
[13:38:20 EDT(-0400)] <fj4000> ok, skype?
[13:39:18 EDT(-0400)] <ecochran_> sure
[14:01:35 EDT(-0400)] <Bosmon> Hi
[14:02:30 EDT(-0400)] <Bosmon> This is a selector which will bind to the part of the header whose style must be changed when the sort order is toggled
[14:02:37 EDT(-0400)] <Bosmon> As such, I guess it is an flc-type selector
[14:03:48 EDT(-0400)] <Bosmon> It is an "offset" selector since there is already a base selector which used for rendering the header in the first place
[14:03:51 EDT(-0400)] <Bosmon> SO the slector is relative to that one
[14:04:21 EDT(-0400)] <Bosmon> I think it is actually an "inverse offset".... that is, there will be a search upwards from the existing table header rendering selector
[14:05:42 EDT(-0400)] <Justin_o> Bosmon: so it would be okay to simply add a flc class in the markup and replace th with that in the options
[14:06:10 EDT(-0400)] <Bosmon> I suppose so
[14:06:20 EDT(-0400)] <Justin_o> okay... thanks...
[14:06:43 EDT(-0400)] <Justin_o> Bosmon: also I'm in the process of doing some linting on the pager and noticed that there is a var "i" which is not defined
[14:07:53 EDT(-0400)] <Bosmon> !!
[14:07:56 EDT(-0400)] <anastasiac> Bosmon: regarding the 'offset' nature of the selector
[14:08:17 EDT(-0400)] <anastasiac> lots of selectors are for things nested inside other things
[14:08:37 EDT(-0400)] <Bosmon> Yes
[14:08:44 EDT(-0400)] <anastasiac> if we replace the specific "th" with a classname, is it relevant that it's 'offset'
[14:08:44 EDT(-0400)] <Bosmon> But this is for something nested outside another thing
[14:09:21 EDT(-0400)] <anastasiac> if it's no longer "th" but is intead a class, is it still "offset" ?
[14:10:21 EDT(-0400)] <anastasiac> Bosmon, what is the base selector used for rendering the header? what is it called?
[14:10:30 EDT(-0400)] <anastasiac> I don't see it in the default selectors...
[14:15:42 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[14:16:41 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[14:16:46 EDT(-0400)] <Justin_o> anastasiac: do css files have copyrights or just js files
[14:16:54 EDT(-0400)] <Bosmon> Well, it is configured in the options for "selfRender"
[14:16:56 EDT(-0400)] <anastasiac> Justin_o, just js files
[14:17:04 EDT(-0400)] <Bosmon> if you see, there is a renderer id "header:"
[14:17:15 EDT(-0400)] <Bosmon> Which might be bound using an rsf:id, or else using a selector
[14:17:32 EDT(-0400)] <Bosmon> The sortHeaderOffset is relative to whatever that part of selfRender configuration identifies
[14:17:37 EDT(-0400)] <anastasiac> I don't see the selector defined in any default selectors in the js, though
[14:17:41 EDT(-0400)] <anastasiac> is there no default?
[14:21:16 EDT(-0400)] <anastasiac> Bosmon? ^
[14:21:21 EDT(-0400)] <Bosmon> Well, the default represnts the node with rsf:id= "header:"
[14:21:27 EDT(-0400)] <Bosmon> That is the default
[14:21:50 EDT(-0400)] <Bosmon> There will be no specific selector for it unless you set up an explicit cutpoint in the renderer options....
[14:21:50 EDT(-0400)] <anastasiac> Bosmon: should the default not be specified in the component's defaults?
[14:22:18 EDT(-0400)] <anastasiac> ecochran_: You're working on the classname updated for uploader, right?
[14:22:29 EDT(-0400)] <Bosmon> I don't know
[14:22:29 EDT(-0400)] <ecochran_> anastasiac: I am, almost done
[14:22:36 EDT(-0400)] <anastasiac> excellent
[14:22:38 EDT(-0400)] <Bosmon> There is no established practice for setting defaults for the renderer
[14:22:56 EDT(-0400)] <anastasiac> ah, ok - I'm getting this, I think, Bosmon
[14:23:08 EDT(-0400)] <anastasiac> it's not a default component selector, the way others are
[14:23:10 EDT(-0400)] <anastasiac> is that right
[14:23:10 EDT(-0400)] <ecochran_> anastasiac: Just got off Skype with fj4000, very helpful in thinking through the style renaming!
[14:23:14 EDT(-0400)] <Bosmon> Perhaps we need a new defaults structure
[14:23:19 EDT(-0400)] <Bosmon> But there is no time to make one now
[14:23:25 EDT(-0400)] <anastasiac> no, not now
[14:23:33 EDT(-0400)] <anastasiac> that's ok, I wasn't asking for one
[14:23:36 EDT(-0400)] <anastasiac> just trying to understand
[14:23:54 EDT(-0400)] <Bosmon> I guess it has the "moral effect" of being a default selector
[14:23:56 EDT(-0400)] <anastasiac> the name headerSortStylisticOffset is a bit confusing
[14:24:03 EDT(-0400)] <anastasiac> I'm wondering if we can change it
[14:24:13 EDT(-0400)] <anastasiac> is it necessary to have the word offset, for example?
[14:24:35 EDT(-0400)] <anastasiac> and why is it call "styleistic" ?
[14:24:38 EDT(-0400)] <Bosmon> Well, as I argued before, I think the fact it works by "inverse containment" will probably be highly relevant to its users
[14:24:53 EDT(-0400)] <Bosmon> Well, it is "Stylistic" because it is a selector.... that part is much more arguable
[14:25:14 EDT(-0400)] <Bosmon> There is another thing somewhere called "stylisticOffset" which seemed reminiscent to me....
[14:25:23 EDT(-0400)] <anastasiac> none of our selectors are called "stylistic"
[14:25:27 EDT(-0400)] <Bosmon>
[14:25:52 EDT(-0400)] <fj4000> ecochran: to be sure - are you doing the moving of the progress css and images folders?
[14:25:58 EDT(-0400)] <Bosmon> Yes
[14:25:59 EDT(-0400)] <anastasiac> so what might a better name be?
[14:26:05 EDT(-0400)] <Bosmon> There is a "stylisticOffset" in the Reorderer
[14:26:07 EDT(-0400)] <ecochran_> fj4000: yes
[14:26:10 EDT(-0400)] <Bosmon> This is what suggested this to me...
[14:26:10 EDT(-0400)] <anastasiac> it's the selector for the column that is being "sorted on"
[14:26:16 EDT(-0400)] <fj4000> Thanks
[14:26:16 EDT(-0400)] <ecochran_> fj4000: thanks for you're help just now
[14:26:24 EDT(-0400)] <fj4000> no, thank you!
[14:26:26 EDT(-0400)] <anastasiac> how about "sortKeyHeader"?
[14:26:27 EDT(-0400)] <Bosmon> Ah, it is stylistic, because it is used for applying a style
[14:26:29 EDT(-0400)] <Bosmon> Now I remember
[14:26:29 EDT(-0400)] <fj4000> Im pumped about Progress
[14:26:46 EDT(-0400)] <Bosmon> The whole purpose of this selector is to identify a piece of markup which will have its CSS class manipulated
[14:26:50 EDT(-0400)] <ecochran_> fj4000: I'm pumped that you're pumped about Progress!
[14:26:50 EDT(-0400)] <anastasiac> oh! it's for styling only? then it would be a fl- selector, not a flc- selector
[14:26:59 EDT(-0400)] <Bosmon> No... you see, it is programmatic
[14:27:25 EDT(-0400)] <anastasiac> is it programmatically applied, so that it can be visually styled?
[14:27:28 EDT(-0400)] <Bosmon> Yes
[14:27:40 EDT(-0400)] <anastasiac> but not so that it can be otherwise manipulated?
[14:27:44 EDT(-0400)] <Bosmon> So, it is a proper selector
[14:27:58 EDT(-0400)] <anastasiac> ok, if it's visual styling only, it's fl- and not flc-
[14:28:05 EDT(-0400)] <anastasiac> even if it's programmatically applied
[14:28:13 EDT(-0400)] <Bosmon> .....
[14:28:18 EDT(-0400)] <Bosmon> I don't remember that being what we agreed
[14:28:26 EDT(-0400)] <Bosmon> On this basis, I made "flc-reorderer-dropWarning"
[14:28:58 EDT(-0400)] <anastasiac> http://issues.fluidproject.org/browse/FLUID-2372
[14:29:20 EDT(-0400)] <anastasiac> I guess it's not hard to mis-interpret the guidelines..
[14:29:28 EDT(-0400)] <Bosmon> "DOM-selection prefix: flc-"
[14:29:39 EDT(-0400)] <Bosmon> This to me clearly represents that the selector is to be used for DOM selection
[14:29:53 EDT(-0400)] <anastasiac> ugh, ok, you're right, I'm confused
[14:29:56 EDT(-0400)] <Bosmon> I mean, by "visual styling" I understand, "The browser operates this selector"
[14:30:01 EDT(-0400)] <anastasiac> no, I was confused
[14:30:05 EDT(-0400)] <anastasiac> sorry
[14:30:08 EDT(-0400)] <Bosmon> Whereas for "DOM selection" I understand "jQuery operates this selector"
[14:30:28 EDT(-0400)] <anastasiac> you're right, you're right, I was just confused
[14:30:35 EDT(-0400)] <Bosmon> The effect, once this selector has bit, is to apply a further class
[14:30:40 EDT(-0400)] <anastasiac> right
[14:30:42 EDT(-0400)] <Bosmon> Now, this further class, could have fl in front of it...
[14:31:03 EDT(-0400)] <anastasiac> right
[14:31:13 EDT(-0400)] <Bosmon> Which, it seems we do
[14:31:15 EDT(-0400)] <Bosmon> Miraculously....
[14:31:22 EDT(-0400)] <Bosmon> fl-pager-asc and fl-pager-desc...
[14:31:44 EDT(-0400)] <anastasiac> so, back to "headerSortStylisticOffset"
[14:31:56 EDT(-0400)] <anastasiac> this is referencing the header of the column that the data is sorted on, right?
[14:32:02 EDT(-0400)] <Bosmon> Yes
[14:32:12 EDT(-0400)] <anastasiac> how about renaming it "sortKeyHeader" ?
[14:32:32 EDT(-0400)] <anastasiac> or "sortColumnHeader"
[14:32:40 EDT(-0400)] <Bosmon> OK... but this might become confused with the other thing, which is the "header"
[14:32:57 EDT(-0400)] <anastasiac> what is the name of that selector, again?
[14:33:01 EDT(-0400)] <anastasiac> I can't find it...
[14:33:06 EDT(-0400)] <Bosmon> The thing identified by "header:"
[14:33:13 EDT(-0400)] <Bosmon> Which may, or may not, be the same as this one
[14:33:24 EDT(-0400)] <anastasiac> ok, but the string I'm looking for is the name of the selector, i.e. the string passed to locate()
[14:33:27 EDT(-0400)] <Bosmon> For example, if you made "headerSortStylisticOffset" = "*", then they would become the same
[14:33:44 EDT(-0400)] <Bosmon> ?
[14:33:48 EDT(-0400)] <Bosmon> That is the name of the selector
[14:33:50 EDT(-0400)] <Bosmon> "headerSortStylisticOffset"
[14:33:58 EDT(-0400)] <anastasiac> yes, but "header:" has no 'name'
[14:34:07 EDT(-0400)] <anastasiac> rigth?
[14:34:28 EDT(-0400)] <fj4000> Bosmon: im reviewing the changes done in the Reorderer family, and I have some questions for you
[14:34:37 EDT(-0400)] <Bosmon> Yes, that's right
[14:34:40 EDT(-0400)] <Bosmon> "header:" has no name
[14:34:40 EDT(-0400)] <anastasiac> fj4000, he's busy right now
[14:34:43 EDT(-0400)] <fj4000>
[14:34:46 EDT(-0400)] <Bosmon> fj4000: Ask away
[14:34:47 EDT(-0400)] <fj4000> i was just going to ask
[14:35:02 EDT(-0400)] <Bosmon> I can answer you, though 9 attacks are incoming on my village
[14:35:10 EDT(-0400)] <fj4000> so your ok with me tag-teaming with anastasiac? you seem busy
[14:35:14 EDT(-0400)] <fj4000> lol
[14:35:16 EDT(-0400)] <Bosmon> It is fine
[14:35:23 EDT(-0400)] <Bosmon> I am very good at these interleaved conversations
[14:35:23 EDT(-0400)] <anastasiac> yes, it's fine
[14:35:58 EDT(-0400)] <fj4000> ok - there are a lot of class names left untouched in the ImageReorderer.css file
[14:36:08 EDT(-0400)] <Bosmon> Ah
[14:36:18 EDT(-0400)] <fj4000> are they unchanged b/c they are not specific to the component, b/c they seem like they are....
[14:36:20 EDT(-0400)] <Bosmon> You're right
[14:36:23 EDT(-0400)] <Bosmon> Sorry
[14:36:26 EDT(-0400)] <fj4000> its cool
[14:36:30 EDT(-0400)] <Bosmon> No, they are unchanged, because I am a bonehead fascist
[14:36:33 EDT(-0400)] <fj4000> i was just going to change them
[14:36:36 EDT(-0400)] <fj4000> whoa
[14:36:40 EDT(-0400)] <Bosmon> I started only by changing styles I saw referenced in a js file
[14:36:41 EDT(-0400)] <fj4000> wouldnt say that, but ok
[14:36:53 EDT(-0400)] <Bosmon> And in fact, went quite a long way before I realised that I would actually need to update the CSS files at all
[14:37:04 EDT(-0400)] <fj4000> np - I will commence then
[14:37:07 EDT(-0400)] <fj4000> thanks
[14:37:09 EDT(-0400)] <Bosmon> But still, in doing so, it didn't occur to me that there might be class names which only appeared in CSS files....
[14:37:33 EDT(-0400)] <fj4000> ? like what?
[14:37:52 EDT(-0400)] <Bosmon> Well, like all of these ones
[14:38:00 EDT(-0400)] <Bosmon> These ones I missed...
[14:38:07 EDT(-0400)] <fj4000> oh
[14:38:14 EDT(-0400)] <fj4000> anything fl-* you mean?
[14:38:30 EDT(-0400)] <fj4000> which is what all those will change to
[14:38:34 EDT(-0400)] <fj4000> unless you object
[14:38:38 EDT(-0400)] <Bosmon> No, do go ahead
[14:38:41 EDT(-0400)] <Bosmon> I am sorry I missed them
[14:39:14 EDT(-0400)] <fj4000> okilee dokileee
[14:40:14 EDT(-0400)] <fj4000> thanks a bunch.... anastasiac - please continue to pummel Bosmon's village
[14:40:19 EDT(-0400)] <fj4000> I have plundered all I need
[14:40:38 EDT(-0400)] <anastasiac> let the ransacking continue!
[14:52:36 EDT(-0400)] <anastasiac> Bosmon:
[14:53:34 EDT(-0400)] <anastasiac> ...never mind...
[14:56:48 EDT(-0400)] <Bosmon>
[14:56:57 EDT(-0400)] <Bosmon> Anything I can do?
[15:00:32 EDT(-0400)] <Justin_o> Bosmon: I'll take a look
[15:01:45 EDT(-0400)] <ecochran_> fj4000: you're OK with my just nuking that Progress.js file? Yes?
[15:01:58 EDT(-0400)] <ecochran_> sorry Progress.css
[15:02:06 EDT(-0400)] <fj4000> ah, ok
[15:02:10 EDT(-0400)] <fj4000> i got nervous for a second
[15:02:14 EDT(-0400)] <ecochran_> me too
[15:02:17 EDT(-0400)] <fj4000> pls dont nuke it though
[15:02:33 EDT(-0400)] <fj4000> if you could prep a folder in the stand alone demos for it, maybe
[15:02:36 EDT(-0400)] <Justin_o> Bosmon: we're going to need help wit the API name changes soon... we still have to figure out some names though... did you have any more thoughts on the DARApplier
[15:02:48 EDT(-0400)] <fj4000> or
[15:02:51 EDT(-0400)] <ecochran_> fj4000: hmm
[15:02:53 EDT(-0400)] <fj4000> actually ecochran
[15:03:00 EDT(-0400)] <fj4000> I made a jira ticket for it
[15:03:10 EDT(-0400)] <fj4000> so you could just make it a patch and save it there
[15:03:12 EDT(-0400)] <fj4000> right?
[15:03:15 EDT(-0400)] <ecochran_> great. I'll make a patch
[15:03:19 EDT(-0400)] <ecochran_> yes
[15:03:26 EDT(-0400)] <ecochran_> whats the JIRA?
[15:03:26 EDT(-0400)] <fj4000> ok, let me get it
[15:04:01 EDT(-0400)] <ecochran_> fj4000: there isn't a difference to "patch", what I'll do is just copy the contents into the JIRA because it's only 2 lines
[15:04:14 EDT(-0400)] <fj4000> ok
[15:04:20 EDT(-0400)] <fj4000> i need to make a new ticket
[15:04:23 EDT(-0400)] <fj4000> 1 sec
[15:05:53 EDT(-0400)] <fj4000> FLUID-2430
[15:06:46 EDT(-0400)] <Justin_o> anastasiac: do all of the third party js files need to have a copyright comment
[15:06:54 EDT(-0400)] <ecochran_> fj4000: thanks!
[15:07:23 EDT(-0400)] <anastasiac> Justin_o, as far as I know, they would have whatever they have
[15:07:29 EDT(-0400)] <anastasiac> that part is not up to us
[15:07:47 EDT(-0400)] <Justin_o> okay... so i don't have to worry about them... as long as there is a licence file in the directory that's all we need
[15:10:08 EDT(-0400)] <fj4000> Ok, everyone pls update
[15:10:20 EDT(-0400)] <fj4000> I made a <head> change in a several files
[15:10:29 EDT(-0400)] <fj4000> Bosmon, Justin_o, anastasiac : ^
[15:14:59 EDT(-0400)] <fj4000> ecochran: can I rename fluid.components.uploader.css to Uploader.css to comply with all the other components css files?
[15:15:16 EDT(-0400)] <ecochran_> anastasiac, Justin_o, fj4000, colinclark: I'm done with the selector/style changes for Uploader. It was a strange combination of interesting and mind numbing at the same time (as I'm sure that each of you who are doing this have found). I feel about 98% good about it.
[15:15:22 EDT(-0400)] <ecochran_> fj4000: I'll do it
[15:15:25 EDT(-0400)] <fj4000> ok
[15:15:38 EDT(-0400)] <ecochran_> fj4000: what JIRA is that one under? I'll find it.
[15:16:11 EDT(-0400)] <ecochran_> fj4000: thanks for the reminder, I was waiting to do it until I could check in the style/selector names
[15:16:17 EDT(-0400)] <fj4000>
[15:16:41 EDT(-0400)] <Justin_o> ecochran_: i think we have been filing those under the svn restructuring FLUID-2401
[15:16:53 EDT(-0400)] <ecochran_> Justin_o: thanks!
[15:17:10 EDT(-0400)] <Justin_o> np
[15:17:30 EDT(-0400)] <fj4000> after all this time, I just noticed the underscore in your nick ecochran_
[15:17:49 EDT(-0400)] <ecochran_> fj4000: no idea where that came from
[15:18:04 EDT(-0400)] <ecochran_> fj4000: and I can't figure out where to get rid of it
[15:18:47 EDT(-0400)] <fj4000> maybe quit, and then relaunch your chat program and re-join the room?
[15:22:14 EDT(-0400)] <ecochran_> colinclark: I'm running off to lunch... when I get back I will get the Image Gallery working again
[15:31:46 EDT(-0400)] <colinclark> ecochran_: great
[15:35:29 EDT(-0400)] <Justin_o> colinclark, ecochran_, fj4000, Bosmon, anastasiac, michelled , et al: any thoughts on those api name changes
[15:35:42 EDT(-0400)] <colinclark> Justin_o: Yep, one sec.
[15:36:03 EDT(-0400)] <Justin_o> colinclark: thanks
[15:47:03 EDT(-0400)] <anastasiac> ecochran_: Just reviewing the Uploader class name changes
[15:47:05 EDT(-0400)] <anastasiac> one question:
[15:47:13 EDT(-0400)] <anastasiac> any reason not to rename "fluid-templates"?
[15:49:07 EDT(-0400)] <colinclark> anastasiac: As far as I know, it should be an fl- class name.
[15:49:23 EDT(-0400)] <anastasiac> fl-uploader-hidden-templates, likely
[15:53:59 EDT(-0400)] <anastasiac> ok, I've update the hiddenTemplates class in Uploader
[16:19:39 EDT(-0400)] * jessm (n=Jess@c-71-232-3-4.hsd1.ma.comcast.net) has joined #fluid-work
[16:20:03 EDT(-0400)] <jessm> Justin_o: http://wiki.fluidproject.org/display/fluid/Release+Testing+Tasks doesn't have any available tasks [16:20:06 EDT(-0400)] <jessm> did i miss something? [16:20:20 EDT(-0400)] <Justin_o> you might have to refresh [16:20:40 EDT(-0400)] <Justin_o> i just updated the names of some of the tasks [16:21:06 EDT(-0400)] <ecochran_> anastasiac: just got back from lunch [16:21:10 EDT(-0400)] <ecochran_> catching up [16:21:16 EDT(-0400)] <jessm> Justin_o: oh my, lots! [16:21:26 EDT(-0400)] <Justin_o> yes.... i think there are more than 200 [16:22:16 EDT(-0400)] <ecochran_> anastasiac: that's fine. I was going back and forth on that one with name and forgot to go back once more and go forth [16:30:43 EDT(-0400)] * Bosmo1 (n=Bosmon@cpc2-cmbg10-0-0-cust386.cmbg.cable.ntl.com) has joined #fluid-work [16:31:00 EDT(-0400)] <Bosmo1> Hi guys... sorrry to be so late.... is anyone still here? [16:32:03 EDT(-0400)] <Justin_o> Bosmo1: hello [16:34:42 EDT(-0400)] <Bosmo1> ? [16:38:22 EDT(-0400)] <Justin_o> did you have any thoughts on that renaming [16:38:37 EDT(-0400)] <Bosmo1> I have just got here, unfortunately [16:41:12 EDT(-0400)] <Justin_o> okay [16:41:22 EDT(-0400)] <Justin_o> let us know when you are ready [16:43:34 EDT(-0400)] <ecochran_> colinclark: got a sec to talk about the infusion pom file? [16:44:19 EDT(-0400)] <Bosmo1> Well, i am ready [16:44:25 EDT(-0400)] <Bosmo1> I guess I just need to find the bot for the history... [16:44:49 EDT(-0400)] <Justin_o> we've been waiting for you to talk about it [16:44:54 EDT(-0400)] <Bosmo1> oh, ok [16:44:56 EDT(-0400)] <Bosmo1> Well, I am ready [16:45:16 EDT(-0400)] <Justin_o> colinclark unfortunately is in a meeting right now [16:45:23 EDT(-0400)] <Bosmo1> ok [16:45:26 EDT(-0400)] <Bosmo1> Well, I will be here [16:45:34 EDT(-0400)] <ecochran_> bummer [16:45:54 EDT(-0400)] <Justin_o> we can probably start, he's usually quick to get caught up [16:46:00 EDT(-0400)] <Justin_o> if everyone else is available [16:46:10 EDT(-0400)] <Justin_o> anastasiac, michelled ^ [16:47:48 EDT(-0400)] <anastasiac> Justin_o, colinclark, michelled, Bosmo1, ecochran_, fj4000: The hourly and nightly builds of the components has been reinstated with the new structure, and the build site links have been updated [16:47:58 EDT(-0400)] <anastasiac> let me know if I missed anything! [16:48:10 EDT(-0400)] <anastasiac> Justin_o: can I help with updating the links in the test protocols? [16:48:20 EDT(-0400)] <ecochran_> anastasiac: that's great news... I'm in the process of working on the image gallery. My understanding is that it's broken [16:48:37 EDT(-0400)] <anastasiac> ugh [16:48:51 EDT(-0400)] <ecochran_> anastasiac: I was wondering if the name of the build infusion was going to stay fluid-components or become fluid-infusion [16:49:04 EDT(-0400)] <ecochran_> the pom.xml file still says fluid-components [16:49:33 EDT(-0400)] <anastasiac> ah - right - we're not going to rename that right now, because that would break any dependencies on it [16:49:42 EDT(-0400)] <anastasiac> I was about to email the list asking if anyone objects [16:49:48 EDT(-0400)] <anastasiac> but until we check, no renaming [16:50:09 EDT(-0400)] <Justin_o> anastasiac: sure... the test plans are on this page http://wiki.fluidproject.org/display/fluid/Testing+Fluid+Components [16:50:15 EDT(-0400)] <Justin_o> whenever you are ready [16:50:53 EDT(-0400)] <ecochran_> anastasiac: OK, I can work with that! [16:52:00 EDT(-0400)] <michelled> Bosmo1: I was just linting the Geometric manager. There are two spots that use '==' and I was wondering if it was intentional. line 193 and line 562 (you'll need to update for my line number to make sense) [16:53:14 EDT(-0400)] <Bosmo1> ok [16:53:47 EDT(-0400)] <Bosmo1> Just firing up eclipse now [16:53:55 EDT(-0400)] <Bosmo1> I am on the nano-portable [16:54:06 EDT(-0400)] <Bosmo1> In TJHIEN's kitchen... [16:54:58 EDT(-0400)] <anastasiac> Justin_o: I'll start at the bottom of the list, since you're probably starting at the top... [17:13:45 EDT(-0400)] <michelled> when it's applying the preferences [17:14:51 EDT(-0400)] <Bosmo1> Well, I mean, in what situation... [17:15:29 EDT(-0400)] <colinclark> When existing classes are in conflict with the user's preferences. [17:15:45 EDT(-0400)] <colinclark> Ok, so we have three options now: [17:15:48 EDT(-0400)] <Bosmo1> ah [17:15:53 EDT(-0400)] <Bosmo1> UIAdjuster? [17:15:57 EDT(-0400)] <Bosmo1> UIConformer? [17:16:02 EDT(-0400)] <Bosmo1> UIApplier [17:16:06 EDT(-0400)] <colinclark> [17:16:13 EDT(-0400)] <Justin_o> UIUpdater? [17:16:22 EDT(-0400)] <colinclark> UILipstickApplier [17:16:26 EDT(-0400)] <Bosmo1> ..... [17:16:28 EDT(-0400)] <michelled> glarg [17:16:32 EDT(-0400)] <Bosmo1> But it also takes it away [17:16:38 EDT(-0400)] <Bosmo1> We already established that [17:16:43 EDT(-0400)] <colinclark> Ok, I will be behave. [17:16:46 EDT(-0400)] <colinclark> fish is glarging at me [17:17:06 EDT(-0400)] <michelled> I could see UIAdjuster [17:17:14 EDT(-0400)] <colinclark> I still like UITransformer best. [17:17:20 EDT(-0400)] <Bosmo1> Well [17:17:27 EDT(-0400)] <Bosmo1> You still cling to this Old Faith [17:17:28 EDT(-0400)] <colinclark> But again, I'm willing to hear the argument that we shouldn't bother renaming. [17:17:29 EDT(-0400)] <colinclark> lol [17:17:35 EDT(-0400)] <Bosmo1> But I don't feel we are yet ready for Transformation [17:17:42 EDT(-0400)] <colinclark> ecochran_: Any ideas? [17:17:43 EDT(-0400)] <Bosmo1> One day, CATTs will fly in the clouds [17:17:50 EDT(-0400)] <Bosmo1> Like small aeroplanes [17:17:50 EDT(-0400)] <colinclark> Well, they already do. [17:17:56 EDT(-0400)] <colinclark> One day, we will all fly in the clouds. [17:18:11 EDT(-0400)] <ecochran_> I like the current name [17:18:30 EDT(-0400)] <colinclark> ecochran_: So you don't think there'll be any confusion with progressive enhancement later on if we have such features? [17:18:35 EDT(-0400)] <ecochran_> UIs need enhancement! [17:18:39 EDT(-0400)] <colinclark> very true [17:18:56 EDT(-0400)] <ecochran_> progressive enhancement is a very particular kind of enhancement [17:19:02 EDT(-0400)] <ecochran_> not general [17:19:11 EDT(-0400)] <Bosmo1> ok [17:19:17 EDT(-0400)] <ecochran_> so there may be very minor confusion [17:19:26 EDT(-0400)] <Bosmo1> But is it an example of enhancing something, to make it more basic? [17:19:27 EDT(-0400)] <ecochran_> but only minor [17:19:30 EDT(-0400)] <Bosmo1> UIRightSizer.... [17:19:38 EDT(-0400)] <anastasiac> UIStyler [17:19:38 EDT(-0400)] <ecochran_> Bosmo1: yes [17:19:54 EDT(-0400)] <Bosmo1> UIStylingEngine [17:20:00 EDT(-0400)] <colinclark> UIEngine? [17:20:02 EDT(-0400)] <ecochran_> making something more basic is an enhancement for the person who needs a more basic UI [17:20:06 EDT(-0400)] <Bosmo1> UIEngine, also [17:20:10 EDT(-0400)] <Bosmo1> I like Enginous things [17:20:18 EDT(-0400)] <michelled> if we keep the name UIEnhancer then I think we'd have to preface our future 'enhance' with 'progressive' or 'prog' [17:20:25 EDT(-0400)] <ecochran_> UIen-genius [17:21:09 EDT(-0400)] <anastasiac> UIEngine is not very clear [17:21:14 EDT(-0400)] <anastasiac> what does that mean? what does it do? [17:21:44 EDT(-0400)] <Justin_o> UIMutator [17:21:49 EDT(-0400)] <Justin_o> UIManipulator [17:22:05 EDT(-0400)] <colinclark> sounds shady to me [17:22:06 EDT(-0400)] <colinclark> [17:22:24 EDT(-0400)] <colinclark> I still liked StyleAble best. [17:22:26 EDT(-0400)] <colinclark> [17:22:54 EDT(-0400)] <Bosmo1> glarg [17:23:01 EDT(-0400)] <colinclark> EverythingAble [17:23:06 EDT(-0400)] <colinclark> GlargAble [17:23:11 EDT(-0400)] <Bosmo1> EverythingImaginAble [17:23:15 EDT(-0400)] <colinclark> lol [17:23:31 EDT(-0400)] <colinclark> Ok, let's let this one sit for a few minutes and see if there are any other easy ones. [17:23:42 EDT(-0400)] <colinclark> fluid.assembleSuperModel() [17:23:51 EDT(-0400)] <colinclark> what about just assembleModels() [17:23:53 EDT(-0400)] <colinclark> ? [17:23:59 EDT(-0400)] <michelled> I like that much better [17:24:29 EDT(-0400)] <anastasiac> +1 [17:25:11 EDT(-0400)] <colinclark> Bosmo1, ecochran_, Justin_o: Thoughts? [17:25:33 EDT(-0400)] <ecochran_> +1 [17:25:36 EDT(-0400)] <Justin_o> +1 for assembleModels() [17:26:04 EDT(-0400)] <colinclark> Bosmo1: Stop us if you think it doesn't convey things clearly enough. [17:26:07 EDT(-0400)] <colinclark> You know this code best. [17:26:20 EDT(-0400)] <Bosmo1> hm [17:26:27 EDT(-0400)] <Bosmo1> Well, it does more than assembling the Model [17:26:38 EDT(-0400)] <Bosmo1> I mean, the "Superness" was something palpable [17:26:44 EDT(-0400)] <colinclark> Because it also assembles the appliers? [17:26:46 EDT(-0400)] <Bosmo1> In that what it forms is a kind of composite, "super" model [17:26:47 EDT(-0400)] <Bosmo1> Yes [17:26:55 EDT(-0400)] <michelled> assembleModelAndApplier? [17:27:11 EDT(-0400)] <colinclark> Well, I'd argue that the applier is a key aspect of our components' experience of the model. [17:27:13 EDT(-0400)] <colinclark> If you know what I mean. [17:27:19 EDT(-0400)] <Bosmo1> Yes [17:27:24 EDT(-0400)] <Bosmo1> Or rather, it will be [17:27:28 EDT(-0400)] <colinclark> yes, exactly [17:27:34 EDT(-0400)] <colinclark> like how we had assumed that appliers would be initialized through a call to initModel() [17:27:47 EDT(-0400)] <Bosmo1> Yes, I guess in some sense we do imagine that [17:28:03 EDT(-0400)] <Bosmo1> Although I realised when I came to try to reform the Pager that I had not got it right yet [17:28:14 EDT(-0400)] <Bosmo1> We will actually need different "varieties" or "thicknesses" of appliers [17:28:39 EDT(-0400)] <colinclark> dealing with different chunks of the overall model? [17:30:15 EDT(-0400)] <colinclark> Bosmo1: ^ [17:31:22 EDT(-0400)] * clown (n=clown@142.150.154.101) has left #fluid-work [17:31:35 EDT(-0400)] <colinclark> Looks like we lost him. [17:31:45 EDT(-0400)] <colinclark> ecochran_: Any ideas for uploader.repairFromUploader()? [17:32:02 EDT(-0400)] <ecochran_> sorry, tuned out for a second [17:32:30 EDT(-0400)] <colinclark> ecochran_: no worries. we had been waiting to hear from Bosmo1, but we can move on for now. [17:32:38 EDT(-0400)] <ecochran_> well, that one was kind of a pun... [17:33:00 EDT(-0400)] <ecochran_> let me look at the code for a minute and see if anything comes to me [17:33:14 EDT(-0400)] <colinclark> It sets up the UI after an upload has completed. [17:33:26 EDT(-0400)] <ecochran_> exactly [17:33:46 EDT(-0400)] <colinclark> So, during upload, file rows get grayed out to show that they can't be interacted with [17:33:52 EDT(-0400)] <ecochran_> it's actually "repairFromUpload" [17:33:58 EDT(-0400)] <ecochran_> goes with prepareForUpload [17:33:59 EDT(-0400)] <colinclark> and the Upload button is obviously disabled [17:34:01 EDT(-0400)] <colinclark> yes sorry [17:34:07 EDT(-0400)] <colinclark> uploader.repairFromUpload() [17:34:13 EDT(-0400)] <michelled> updateAfterUpload? [17:34:21 EDT(-0400)] <colinclark> michelled: Just what I was about to suggest! [17:34:22 EDT(-0400)] <colinclark> [17:34:36 EDT(-0400)] <colinclark> refreshAfterUpload()? [17:34:46 EDT(-0400)] <michelled> isn't this actually a refreshView? [17:34:56 EDT(-0400)] * anastasiac was wondering that [17:35:06 EDT(-0400)] <ecochran_> refreshAfterUpload is good [17:35:12 EDT(-0400)] <colinclark> michelled: Not at the moment, no. [17:35:48 EDT(-0400)] <colinclark> It probably ultimately needs to be refactored so that refreshView covers it, but for now, it's just a method bound to the afterUploadComplete() event [17:36:00 EDT(-0400)] <ecochran_> we have some other methods like setStateUploading and setStateLoaded [17:36:01 EDT(-0400)] <colinclark> It's public, in that it's a basic thing you want to do with a FileQueueView... [17:36:14 EDT(-0400)] <colinclark> tell it to go into it's "uploading" mode, and into it's "complete" mode, and so on. [17:36:23 EDT(-0400)] <ecochran_> those are in uploader not in fileQueueView [17:36:30 EDT(-0400)] <michelled> in that case I like refreshAfterUploade [17:36:33 EDT(-0400)] <michelled> without the e [17:36:41 EDT(-0400)] <ecochran_> such a nice e [17:36:43 EDT(-0400)] <colinclark> it's interesting... most of the public methods in FileQueueView are file-related [17:36:45 EDT(-0400)] <michelled> it tells me that it has something to do with refreshView [17:37:01 EDT(-0400)] <michelled> even if it's a future refactoring [17:37:03 EDT(-0400)] <colinclark> only prepareForUpload() and repairFromUpload() are more general [17:37:09 EDT(-0400)] <ecochran_> this one is for the whole queue not file by file [17:37:31 EDT(-0400)] <anastasiac> the word "repair" implies recovery from some damage [17:37:48 EDT(-0400)] <colinclark> Just for reference, these are the event bindings for the FileQueueView, all of which just bind straight to public methods: [17:37:48 EDT(-0400)] <colinclark> http://www.pastie.org/433119 [17:38:01 EDT(-0400)] <ecochran_> ah, I was using repair as in repair to your lare [17:38:20 EDT(-0400)] <michelled> hee hee [17:38:24 EDT(-0400)] <colinclark> [17:38:30 EDT(-0400)] <colinclark> ecochran_: So two suggestions so far... [17:38:39 EDT(-0400)] <colinclark> updateAfterUpload() or refreshAfterUpload() [17:38:40 EDT(-0400)] <ecochran_> would we change prepareForUpload to ? [17:38:55 EDT(-0400)] <colinclark> ecochran_: We certainly could [17:38:59 EDT(-0400)] <michelled> I think prepareForUpload tells me what it's going to do [17:39:03 EDT(-0400)] <michelled> is there a better name? [17:39:11 EDT(-0400)] <ecochran_> I don't thinks so [17:39:16 EDT(-0400)] <colinclark> i guess they don't need to rhyme [17:39:21 EDT(-0400)] <ecochran_> refreshAfterUpload [17:39:33 EDT(-0400)] <ecochran_> +1 [17:39:50 EDT(-0400)] <colinclark> ecochran_: And we'll leave prepareForUpload()? [17:39:50 EDT(-0400)] <ecochran_> no wait, I might be changing my mind [17:39:56 EDT(-0400)] <colinclark> [17:40:10 EDT(-0400)] <ecochran_> we use refresh to usually mean that we're refreshing based on a change to the model [17:40:17 EDT(-0400)] <ecochran_> which we're not really doing here [17:41:02 EDT(-0400)] <ecochran_> this is "dim everything cause we're uploading" and "undim everything cause we're done" [17:41:04 EDT(-0400)] <michelled> well, refreshView is more general I think [17:41:10 EDT(-0400)] <ecochran_> OK [17:41:11 EDT(-0400)] <michelled> at least the way I'm using it. [17:41:18 EDT(-0400)] <ecochran_> I didn't think of it that way [17:41:24 EDT(-0400)] <ecochran_> but I'm fine if it is [17:42:00 EDT(-0400)] <ecochran_> so I'm still good with refreshAfterUpload [17:42:14 EDT(-0400)] <colinclark> ecochran_: You like it better than updateAfterUpload? [17:42:38 EDT(-0400)] <anastasiac> would "restore" be an alternative? [17:42:41 EDT(-0400)] <Bosmo1> Sorry, it was dinner [17:42:47 EDT(-0400)] <ecochran_> I like the word "refresh", it's "refreshing!" [17:42:49 EDT(-0400)] <Bosmo1> I was going to talk about "thick" appliers and "thin" appliers [17:42:57 EDT(-0400)] <michelled> dinner is important! [17:42:59 EDT(-0400)] <ecochran_> restore is good [17:43:01 EDT(-0400)] <colinclark> Bosmo1: Yep. Hang on one sec. [17:43:04 EDT(-0400)] <ecochran_> restoreAfterUpload [17:43:10 EDT(-0400)] <Bosmo1> "thick" appliers, which have the possibility to be "transactional" are not appropriate for "really big models" [17:43:33 EDT(-0400)] <Bosmo1> Like the Pager's data model is too big to be cloned [17:43:38 EDT(-0400)] <ecochran_> restore is more like what's happening... at least in my mind [17:43:43 EDT(-0400)] <ecochran_> any votes? [17:43:50 EDT(-0400)] <Bosmo1> But the Pager's own model, that of the paging state, is fine - it just consists of 5 numbers [17:44:12 EDT(-0400)] <colinclark> ecochran_: I'm good with restoreAfterUpload() [17:44:42 EDT(-0400)] <colinclark> I think I still like refreshAfterUpload() [17:44:45 EDT(-0400)] <colinclark> that's really what we're doing here... [17:44:46 EDT(-0400)] <michelled> I'm happier with refresh or update [17:44:52 EDT(-0400)] <colinclark> refreshing the UI based on a state change in the model [17:45:19 EDT(-0400)] <anastasiac> if it's based on changes to the 'model', then refresh seems more appropriate than restore [17:45:40 EDT(-0400)] <colinclark> And really, that's what these events express... [17:45:46 EDT(-0400)] <colinclark> hey, all the files in your queue are now done uploading [17:46:11 EDT(-0400)] <ecochran_> it doesn't really care about the model [17:46:25 EDT(-0400)] <colinclark> ecochran_: Well, it does care about the event. That's my point. [17:46:30 EDT(-0400)] <ecochran_> that it does [17:46:45 EDT(-0400)] <anastasiac> +1 for refreshAfterUpload [17:47:05 EDT(-0400)] <ecochran_> I'll buy that [17:47:10 EDT(-0400)] <michelled> me too [17:47:10 EDT(-0400)] <colinclark> ok [17:47:13 EDT(-0400)] <colinclark> ecochran_: Sold? [17:47:15 EDT(-0400)] <ecochran_> done [17:47:16 EDT(-0400)] <ecochran_> sold [17:47:20 EDT(-0400)] <ecochran_> purchased [17:47:25 EDT(-0400)] <colinclark> Do you have time to implement that one? [17:47:32 EDT(-0400)] <ecochran_> yep, doing so now [17:47:56 EDT(-0400)] <ecochran_> OK, back to the man in the tweed coat in row six, your item sir? [17:48:22 EDT(-0400)] <colinclark> Bosmo1: Your model point in Pager made sense to me. [17:48:35 EDT(-0400)] <colinclark> Do you think it impacts on the assembleSuperModel() name? [17:50:39 EDT(-0400)] <colinclark> i guess he is eating carbonara at the moment [17:50:59 EDT(-0400)] <colinclark> Most of the other names are things Bosmo1 should be in the loop on. [17:51:19 EDT(-0400)] <colinclark> assembleSuperModel(), DARApplier, and bindFossils() [17:51:41 EDT(-0400)] <ecochran_> bindFossils? [17:51:43 EDT(-0400)] <colinclark> I quite like the name Fossil, since it's a good metaphor. [17:51:53 EDT(-0400)] <ecochran_> whoa I missed that one [17:51:55 EDT(-0400)] <colinclark> But I'd rather have Antranig briefly explain what fossils are in the renderer. [17:52:01 EDT(-0400)] <ecochran_> please do! [17:53:16 EDT(-0400)] <anastasiac> fossils: little bundles of information [17:53:28 EDT(-0400)] <colinclark> lol [17:53:40 EDT(-0400)] <anastasiac> the renderer attaches them to nodes [17:54:09 EDT(-0400)] <colinclark> They're a way of embedding a binding between the renderer and the model in the DOM... a way of tracing back the relationship between the view of something in the DOM and the paths they correspond to in the model. [17:54:14 EDT(-0400)] * anastasiac tries to refresh her memory [17:54:17 EDT(-0400)] <ecochran_> why are they "fossilized" [17:54:31 EDT(-0400)] <anastasiac> they provide a record of things [17:54:40 EDT(-0400)] <Bosmo1> OK [17:54:41 EDT(-0400)] <Bosmo1> I am back [17:54:45 EDT(-0400)] <anastasiac> I guess is the 'bolus' that's the little bundle [17:55:13 EDT(-0400)] <colinclark> Bosmo1: Ok, we're on two subjects. [17:55:29 EDT(-0400)] <colinclark> First, your comment about the model in Pager made sense to me. [17:55:33 EDT(-0400)] <ecochran_> sorry, my fault for asking [17:55:54 EDT(-0400)] <colinclark> I asked whether you thought it impacted on the name assembleSuperModel()? [17:56:02 EDT(-0400)] <Bosmo1> No, they are separate [17:56:07 EDT(-0400)] <Bosmo1> These three things are separate [17:56:08 EDT(-0400)] <colinclark> ecochran_: It's a good question to ask. We'll get Bosmo1 to explain it more clearly in a sec. [17:56:17 EDT(-0400)] <ecochran_> no rush [17:56:26 EDT(-0400)] <colinclark> Bosmo1: So do you think assembleModels() is sufficient, or should we keep fishing? [17:57:07 EDT(-0400)] <Bosmo1> They are "fossils", of the way the model once was [17:57:28 EDT(-0400)] <Bosmo1> I mean, it is actually possible, if we think about this harder, that this will end up more integrated with the DARApplier [17:57:39 EDT(-0400)] <colinclark> Bosmo1: data binding will, you mean? [17:57:42 EDT(-0400)] <Bosmo1> Since now I think about it, they are not quite so separate after all [17:57:43 EDT(-0400)] <Bosmo1> Yes [17:57:45 EDT(-0400)] <colinclark> including the notion of fossils [17:57:45 EDT(-0400)] <colinclark> ok [17:57:59 EDT(-0400)] <Bosmo1> Since this idea behind "thick" and "thin" appliers is directly related to this issue of "fossilization" [17:58:03 EDT(-0400)] <colinclark> we can certainly change APIs later, so we don't have to rename all of these things [17:58:21 EDT(-0400)] <Bosmo1> Even our standard API, updateModel(newModel, oldModel) depends on this concept, that one has a complete "replica" of the old model [17:58:23 EDT(-0400)] <colinclark> I liked this notion of fossils because it is a nice analogy for these "traces" of data left in the DOM. [17:58:38 EDT(-0400)] <Bosmo1> Which, I think for something as big as the Pager's data model might not be appropriate [17:58:39 EDT(-0400)] <colinclark> anastasiac: Did you just find the term too oblique or confusing? [17:58:54 EDT(-0400)] <Bosmo1> But in any case, the "fossils" are there - the fossils are different from "old model", because they are attached to CONTROLS [17:59:04 EDT(-0400)] <Bosmo1> Each individual control individually fossilizes its own "old model state" [17:59:06 EDT(-0400)] <anastasiac> well, I wonder that it would take some deeper understanding of things to not be confused by it [17:59:17 EDT(-0400)] <Bosmo1> But, this is the way it is, largely because it was a straight port of the original RSF idiom [17:59:22 EDT(-0400)] <anastasiac> I understand the use of the word, but will newcomers? [17:59:30 EDT(-0400)] <colinclark> Can we think of any plainer words to use? [17:59:43 EDT(-0400)] <Bosmo1> Once we can keep around "macroscopic old models" we don't specifically need to fossilize individual controls [17:59:50 EDT(-0400)] <colinclark> interesting [18:00:02 EDT(-0400)] <colinclark> Ok, so it's clear that there's more change coming in this area in the future. [18:00:15 EDT(-0400)] <colinclark> Let's punt the renaming of bindFossils() until we know what it all looks like. [18:00:17 EDT(-0400)] <Bosmo1> Although, if the fossilized control has an EL binding attached to it, the overhead of an additional piece of model state is not very significant [18:00:18 EDT(-0400)] <colinclark> And we're sure it's a bad name. [18:00:24 EDT(-0400)] <Bosmo1> Are we? [18:00:32 EDT(-0400)] <colinclark> I don't really think it is... [18:00:41 EDT(-0400)] <colinclark> There's a fine line between choosing good evocative names, and adding too many confusing, proprietary concepts. [18:00:55 EDT(-0400)] <colinclark> Sorry, that didn't quite make sense... [18:01:11 EDT(-0400)] <colinclark> "Let's punt the renaming... until we know what it looks like and are actually sure it's a bad name." [18:01:23 EDT(-0400)] <Bosmo1> oh, ye [18:01:25 EDT(-0400)] <Bosmo1> I understand now [18:01:26 EDT(-0400)] <colinclark> Fossils seems like a fairly coherent metaphor to me. [18:01:32 EDT(-0400)] <anastasiac> I'm ok with fossils [18:01:39 EDT(-0400)] <Bosmo1> There is a whole lot of change, and integration, coming in this area [18:01:41 EDT(-0400)] <colinclark> But if they may go away later, we can easily punt. [18:01:42 EDT(-0400)] <colinclark> Ok. [18:01:50 EDT(-0400)] <colinclark> Back to assembleSuperModel() [18:02:06 EDT(-0400)] <colinclark> The term "bolus," on the other hand, is a whole other issue. [18:02:12 EDT(-0400)] <colinclark> We'll leave that one for now. [18:02:36 EDT(-0400)] <Bosmo1> Right... but "bolus" doesn't appear in any API name, right? [18:02:47 EDT(-0400)] <colinclark> yes, exaclty [18:03:16 EDT(-0400)] <colinclark> Bosmo1: Any further thoughts on what we should do with assembleSuperModel() [18:03:25 EDT(-0400)] <colinclark> I really don't think we should stick with the "super model" terminology. [18:03:32 EDT(-0400)] <colinclark> I mean, you're getting at something important with this term. [18:04:49 EDT(-0400)] <Bosmo1> Yes [18:05:01 EDT(-0400)] <colinclark> Can we think of other ways to express this? [18:05:06 EDT(-0400)] <colinclark> Do you want to talk through it a bit? [18:05:08 EDT(-0400)] <Bosmo1> I guess it is more than simply "super" [18:05:19 EDT(-0400)] <Bosmo1> I mean it is "composite" in some way [18:05:21 EDT(-0400)] <Bosmo1> "routed" [18:05:34 EDT(-0400)] <anastasiac> brainstorming: aggregate, group, [18:05:42 EDT(-0400)] <colinclark> I mean, my understanding of the notion of a super model was simply that it was effective to treat models as a whole: as a deep graph of related things... not unlike how Fish has treated the model in UIOptions. [18:05:47 EDT(-0400)] <colinclark> Bosmo1: Routed how? [18:06:05 EDT(-0400)] * colinclark wonders why he has taken to saying "I mean" before every statement. [18:06:08 EDT(-0400)] <Bosmo1> Well, the "superApplier" is a kind of "router" [18:06:16 EDT(-0400)] <colinclark> Router for change requests? [18:06:31 EDT(-0400)] <Bosmo1> When a DAR request is incoming at top level, it needs to decode it, to discover which of the "subAppliers" it has attached to it is the correct next hop [18:06:43 EDT(-0400)] <colinclark> ok, right [18:06:45 EDT(-0400)] <colinclark> assembleModelHierarchy()? [18:06:53 EDT(-0400)] <colinclark> So tell us a bit about why you've structured a hierarchy of appliers. [18:07:11 EDT(-0400)] <Bosmo1> Well... the "original applier" somehow needs to retain its "identity" [18:07:20 EDT(-0400)] <Bosmo1> Sorry for the constant scare quotes, it is just how it is [18:07:24 EDT(-0400)] <colinclark> that's cool [18:07:28 EDT(-0400)] <colinclark> keep going [18:07:31 EDT(-0400)] <Bosmo1> Since the "base" applier is the one that has event listeners etc. attached to it [18:07:40 EDT(-0400)] <Bosmo1> So you cannot simply "glom" a whole set of appliers together [18:08:03 EDT(-0400)] <Bosmo1> Also, the assemblage might not be "permanent" - in the same way that the renderer model for UIOptions is not "necessarily permanenet" [18:08:06 EDT(-0400)] <Bosmo1> permanent [18:08:45 EDT(-0400)] <Bosmo1> So it seems important, in the same way that model assemblages can be almost "ad hoc", so can the assemblages of their respective appliers [18:08:58 EDT(-0400)] <Bosmo1> They get together, for a particular embedding, in a particular relationship [18:09:01 EDT(-0400)] <Bosmo1> But may take part in others [18:09:10 EDT(-0400)] <Bosmo1> The "subapplier" and "submodel" never become aware that they are submodels [18:09:14 EDT(-0400)] <colinclark> right, ok [18:09:14 EDT(-0400)] <Bosmo1> They never know that they are a CATT [18:09:18 EDT(-0400)] <colinclark> [18:09:41 EDT(-0400)] <colinclark> so walk us through what assembleSuperModel() does [18:10:23 EDT(-0400)] <Bosmo1> Well, assembleSuperModel makes one of these "contingent aggregates" [18:10:40 EDT(-0400)] <colinclark> an aggregation of appliers [18:10:43 EDT(-0400)] <colinclark> with their associated models [18:10:44 EDT(-0400)] <Bosmo1> Firstly, it makes a model, which looks like the superModel containing all the submodels - which is fairly straightforward, since that is how our models work [18:10:59 EDT(-0400)] <Bosmo1> And at the same time, it assembles the respective superApplier, which also reflects and reacts to this relationship [18:11:13 EDT(-0400)] <Bosmo1> It works on these pairs of things, (model, applier) which are all attached at particular paths [18:11:34 EDT(-0400)] <Bosmo1> Since DAR objects are perfectly transparent, as are the models themselves, it is always clear how to manipulate them to "forward them down the chain" [18:11:51 EDT(-0400)] <colinclark> ok [18:12:03 EDT(-0400)] <Bosmo1> The superApplier decodes the dependent paths in the DAR objects, looks up the route, and then "chews" the DAR so the path has now become shorter, and then routes it on [18:12:33 EDT(-0400)] <colinclark> So far, I'm still coming up with assembleModels() or assembleModelHierarchy() as being fairly descriptive for this. [18:12:55 EDT(-0400)] <colinclark> We clearly will need a section of documentation that talks about how models and appliers both can potentially have this sort of hierarchical structure. [18:13:01 EDT(-0400)] <Bosmo1> Yes [18:13:08 EDT(-0400)] <Bosmo1> I have been meaning to write a lot of applier stuff.. [18:13:45 EDT(-0400)] <anastasiac> excellent! [18:13:51 EDT(-0400)] * athena (n=athena@99.129.100.66) has joined #fluid-work [18:15:58 EDT(-0400)] <colinclark> Bosmo1: I'm just chatting with anastasiac and michelled, and we're giving examples of this in practice... [18:16:09 EDT(-0400)] <colinclark> the notion that you might have a piece of a larger model that is interesting to some things... [18:16:30 EDT(-0400)] <colinclark> as you said, the pager example... the model is this giant chunk of json data from the server, and it's also the immediate state of the pager itself. [18:16:33 EDT(-0400)] <colinclark> or UI options. [18:16:41 EDT(-0400)] <Bosmo1> Yes [18:16:43 EDT(-0400)] <colinclark> michelled: What was your example again, real quick? [18:17:08 EDT(-0400)] <colinclark> The point being that these need to be parceled off into chunks in some contexts (the model and its applier), but in other contexts seen as a whole. [18:17:14 EDT(-0400)] <colinclark> Hence the hierarchy of appliers. [18:17:32 EDT(-0400)] <michelled> my example was the textfield slider in uioptions. it has a very simple tiny model - the textfield value. but it exists as part of a larger model - the ui options [18:17:55 EDT(-0400)] <Bosmo1> Yes [18:18:17 EDT(-0400)] <colinclark> So I'd vote for either assembleModelHierarchy() or assemble[Applier]Hierarchy() [18:18:24 EDT(-0400)] <Bosmo1> Although since that is just a leaf model, it's not really worth "assembling".... but.... perhaps it is [18:18:44 EDT(-0400)] <colinclark> assembleModelTree()? [18:18:56 EDT(-0400)] <michelled> I like that [18:19:02 EDT(-0400)] <michelled> and it's shorter [18:19:20 EDT(-0400)] <colinclark> assembleModelGraph()? I guess the point that Bosmo1 and I talked earlier about off-channel was that it is truly a hierarchy [18:19:21 EDT(-0400)] <anastasiac> Tree - any relation to a component tree? [18:19:25 EDT(-0400)] <colinclark> anastasiac: [18:19:27 EDT(-0400)] <colinclark> no [18:19:31 EDT(-0400)] * anastasiac knows that [18:19:33 EDT(-0400)] <colinclark> or a Tree component [18:19:35 EDT(-0400)] <colinclark> [18:19:50 EDT(-0400)] <colinclark> ok, no assembleModelTree() [18:19:51 EDT(-0400)] <colinclark> [18:19:56 EDT(-0400)] <colinclark> Bosmo1: Any thoughts so far? [18:20:00 EDT(-0400)] <Bosmo1> Well [18:20:09 EDT(-0400)] <Bosmo1> I guess I don't really like this sense of "tree" or "hierarchy" [18:20:14 EDT(-0400)] <Bosmo1> Since the aggregation here is just for one step [18:20:18 EDT(-0400)] <Bosmo1> It is like a "cons" for models... [18:20:28 EDT(-0400)] <colinclark> [18:20:37 EDT(-0400)] * colinclark loves lisp references. [18:20:54 EDT(-0400)] <colinclark> ok [18:20:57 EDT(-0400)] <colinclark> assembleModels()? [18:21:03 EDT(-0400)] <colinclark> assemble[Appliers]()? [18:21:53 EDT(-0400)] <colinclark> Bosmo1: ? [18:22:25 EDT(-0400)] <Bosmo1> I guess assembleModels is the only option that isn't unacceptable so far [18:22:43 EDT(-0400)] <michelled> even shorter [18:22:55 EDT(-0400)] <colinclark> Bosmo1: Ok. Is it unacceptable enough to punt, and just warn our users that it will be renamed later? [18:23:06 EDT(-0400)] <colinclark> Or is it acceptable enough to change it and feel that it is tolerable? [18:23:48 EDT(-0400)] <michelled> I'd really like to rename it [18:23:53 EDT(-0400)] <Bosmo1> ha [18:24:01 EDT(-0400)] <Bosmo1> michelled fears the nerd basement stigma [18:24:22 EDT(-0400)] * michelled actually fears giving the wrong impression about our progressive community [18:24:26 EDT(-0400)] <colinclark> [18:24:47 EDT(-0400)] <colinclark> having watched the sixth season of buffy, the nerd in the basement image is rather clear to me. [18:25:01 EDT(-0400)] <colinclark> wait, or was that the fourth season? [18:25:02 EDT(-0400)] <colinclark> ecochran_: ? [18:25:05 EDT(-0400)] <colinclark> [18:25:19 EDT(-0400)] <Bosmo1> aha [18:25:36 EDT(-0400)] <Bosmo1> I think I saw a couple of episodes from that [18:25:45 EDT(-0400)] <colinclark> I quite like assembleModels(). I don't think a huge amount of detail is lost. [18:26:03 EDT(-0400)] <anastasiac> +1 for assembleModels() [18:26:06 EDT(-0400)] <colinclark> I don't want to push this particular name, but there is a general sense of discomfort at evoking BuffyBots. [18:26:08 EDT(-0400)] <michelled> +1 [18:26:21 EDT(-0400)] <Bosmo1> hah! [18:26:45 EDT(-0400)] * michelled was trying to +1 assembleModels not BuffyBots [18:27:06 EDT(-0400)] <Bosmo1> You are all nitwits [18:27:18 EDT(-0400)] <colinclark> http://en.wikipedia.org/wiki/List_of_minor_Buffy_the_Vampire_Slayer_characters [18:27:23 EDT(-0400)] <Bosmo1> Yes [18:27:28 EDT(-0400)] <colinclark> lol [18:27:36 EDT(-0400)] <Bosmo1> Is this the one with the line, "Is this some kind of girlfriend test"? [18:27:47 EDT(-0400)] <colinclark> yes, that was the proto-BuffyBot. [18:28:10 EDT(-0400)] <colinclark> I forget her name, but yes. [18:28:12 EDT(-0400)] <colinclark> Anyway, [18:28:17 EDT(-0400)] <colinclark> Any other ideas for a name? [18:28:28 EDT(-0400)] <colinclark> Should we think about it for a second and move on to DARApplier? [18:28:29 EDT(-0400)] <colinclark> [18:28:36 EDT(-0400)] <colinclark> Since that one will go so easily. [18:28:41 EDT(-0400)] <Bosmo1> Right [18:28:49 EDT(-0400)] <Bosmo1> I mean, I can't quite imagine what you object to about DARApplier [18:28:54 EDT(-0400)] <Bosmo1> It is clear, and descriptive [18:29:01 EDT(-0400)] <Bosmo1> And has no unnatural connotations whatever [18:29:21 EDT(-0400)] <colinclark> DAR is hardly descriptive. [18:29:34 EDT(-0400)] <colinclark> I wondered about the name "Change Applier" [18:29:37 EDT(-0400)] <anastasiac> DAR sounds like a bot name [18:29:46 EDT(-0400)] <Bosmo1> "Data Alteration Request".... [18:29:52 EDT(-0400)] <Bosmo1> The fundamental unit of all decency [18:30:04 EDT(-0400)] <colinclark> "Change Request" [18:30:22 EDT(-0400)] <Bosmo1> Change Request sounds like something out of "Brazil" [18:30:44 EDT(-0400)] <anastasiac> http://www.imdb.com/title/tt0088846/ [18:30:47 EDT(-0400)] <ecochran_> colinclark: sorry, this nerd was talking to Daphne [18:31:05 EDT(-0400)] <colinclark> Bosmo1: At least it's plain English. [18:31:13 EDT(-0400)] <colinclark> Anyway, no need to trade barbs. [18:31:29 EDT(-0400)] <colinclark> I think DARApplier is confusing like many acronyms tend to be. [18:31:35 EDT(-0400)] <ecochran_> oh please no references to Brazil... one of my favorite and least favorite movies of all time [18:31:41 EDT(-0400)] <Bosmo1> !!! [18:31:44 EDT(-0400)] <colinclark> Unlike say, Fossil, it's not even evocative. [18:31:57 EDT(-0400)] <colinclark> There were a ton of ideas on the list... [18:32:09 EDT(-0400)] <Bosmo1> Such as? [18:32:14 EDT(-0400)] <colinclark> It's hard one to name because it is very abstract, in the most excellent sense of the word. [18:32:24 EDT(-0400)] <Bosmo1> Again, "ChangeApplier" fails to be unacceptable [18:32:31 EDT(-0400)] <colinclark> It's also go a bit of the same problem that EventFirers do... [18:32:32 EDT(-0400)] <Bosmo1> But it isn't really very suggestive [18:32:43 EDT(-0400)] <colinclark> Well, it seems very accurate to me. [18:32:45 EDT(-0400)] <Bosmo1> What's wrong with EventFirer now! [18:32:50 EDT(-0400)] <Bosmo1> [18:32:54 EDT(-0400)] <colinclark> Well, it's sort of a two-directional thing. [18:33:04 EDT(-0400)] <colinclark> You fire it, or you register listeners to it. [18:33:05 EDT(-0400)] <Bosmo1> Yes [18:33:12 EDT(-0400)] <michelled> ChangeApplier does seem acceptable [18:33:21 EDT(-0400)] <michelled> tolerable perhaps? [18:33:22 EDT(-0400)] <colinclark> Similarly, the DARApplier is both a place you request changes and that is a notifier of changes. [18:33:32 EDT(-0400)] <colinclark> Other names from the list... I will dig them up. [18:33:42 EDT(-0400)] <Bosmo1> On the other hand, unlike the "assembleModels" concept, it is not really possible to see one part of the idea without the other [18:33:53 EDT(-0400)] <Bosmo1> I mean, it doesn't make sense to fire events, without having some listeners to fire them to [18:34:05 EDT(-0400)] <anastasiac> what would we rename "that.applier" - "that.changeApplier" ? [18:34:15 EDT(-0400)] <Bosmo1> Whereas, it doesn't necessarily not make sense to just assemble models without any appliers [18:35:03 EDT(-0400)] <colinclark> anastasiac: I was thinking of just keeping it as that.applier, but I'm flexible. [18:35:09 EDT(-0400)] <Bosmo1> I think "applier" is pretty good [18:35:18 EDT(-0400)] <colinclark> Other names from the list: [18:35:19 EDT(-0400)] <colinclark> ModelHelper [18:35:19 EDT(-0400)] <colinclark> ModelChanger [18:35:20 EDT(-0400)] <anastasiac> michelled, what do you think about keeping "that.applier" ? [18:35:20 EDT(-0400)] <colinclark> ModelCenter [18:35:20 EDT(-0400)] <colinclark> ModelHub [18:35:24 EDT(-0400)] <Bosmo1> I mean, we abbreviate "Dom binder" to "dom" [18:35:31 EDT(-0400)] <colinclark> ModelOrchestrator [18:35:32 EDT(-0400)] <colinclark> ModelCoordinator [18:35:32 EDT(-0400)] <colinclark> ModelDirector [18:35:32 EDT(-0400)] <colinclark> ModelOrganizer [18:35:37 EDT(-0400)] <Bosmo1> It is named after its essential element [18:35:51 EDT(-0400)] <michelled> that.applier is fine. [18:35:58 EDT(-0400)] <colinclark> Bosmo1: Yes, we debated that one quite a bit, I remember. [18:36:00 EDT(-0400)] <ecochran_> ModelCoordinator is quite good but long [18:36:31 EDT(-0400)] <colinclark> I think most of these names are generally fairly vague. [18:36:52 EDT(-0400)] <colinclark> ModelHub vaguely appealed to me, but it doesn't tell us anything about what it does. [18:37:00 EDT(-0400)] <colinclark> Only that it thinks it's at the center of something. [18:37:22 EDT(-0400)] <Bosmo1> yes [18:37:36 EDT(-0400)] <colinclark> I really think the DARApplier is a central foundation of our architecture. It's very awesome. [18:37:41 EDT(-0400)] <colinclark> It's so amazing that it's hard to name. [18:38:10 EDT(-0400)] <colinclark> Any other ideas? [18:38:13 EDT(-0400)] <michelled> ModelRequestApplier? it's long [18:38:26 EDT(-0400)] <michelled> that doesn't say change [18:38:30 EDT(-0400)] <michelled> not so great [18:38:38 EDT(-0400)] <colinclark> I think the word Request is less descriptive than Change. [18:38:49 EDT(-0400)] <anastasiac> agree - request for what? [18:38:55 EDT(-0400)] <Bosmo1> It is a request [18:38:58 EDT(-0400)] <Bosmo1> A request for change [18:39:01 EDT(-0400)] <colinclark> I mean, at heart, this thing is concerned with helping manage changes to the model. [18:39:09 EDT(-0400)] <colinclark> I do think it's noteworthy that you make a request to it... [18:39:15 EDT(-0400)] <colinclark> but that can be expressed through its API, right? [18:39:15 EDT(-0400)] <Bosmo1> The DAR object is a "request" [18:39:22 EDT(-0400)] <colinclark> changeApplier.request(...) [18:39:52 EDT(-0400)] <colinclark> applier.requestChange(...) [18:39:53 EDT(-0400)] <colinclark> whatever [18:40:25 EDT(-0400)] <Bosmo1> Yes, and the argument to this method is a "request object" [18:40:33 EDT(-0400)] <colinclark> right [18:40:34 EDT(-0400)] <michelled> ChangeDirector? [18:40:39 EDT(-0400)] <colinclark> a "Change Request" object [18:41:13 EDT(-0400)] <colinclark> I feel really bad that we're having this discussion so late in the game. [18:41:17 EDT(-0400)] <colinclark> I apologize. [18:41:27 EDT(-0400)] <colinclark> We are feeling a bit of crunch here... [18:41:41 EDT(-0400)] <colinclark> as always, we can choose to just not rename these things for 1.0 and let people know that they will change in future releases [18:41:52 EDT(-0400)] <colinclark> But it will make our documentation so much clearer if we have a coherent name. [18:42:11 EDT(-0400)] <colinclark> Naming is hard, takes time. [18:42:27 EDT(-0400)] <colinclark> So far, ChangeApplier is most interesting to me. [18:42:36 EDT(-0400)] <Bosmo1> ok [18:42:38 EDT(-0400)] <colinclark> Other ideas? [18:42:42 EDT(-0400)] <Bosmo1> Well, let us do that [18:42:47 EDT(-0400)] <Bosmo1> As you say, we don't have any time [18:42:53 EDT(-0400)] <michelled> and it's tolerable [18:43:06 EDT(-0400)] <colinclark> We can certainly rename these things in the future based on feedback from users. [18:43:23 EDT(-0400)] <colinclark> anastasiac: What do you think, given that you're helping to coordinate our documentation. Do you think ChangeApplier will cut it? [18:43:36 EDT(-0400)] <colinclark> Bosmo1: What's the method used to request a change currently called? [18:43:51 EDT(-0400)] <anastasiac> it's true that ChangeApplier doesn't encapsulate the full power of the thing, but at a glance, it does give a good sense of it's basic nature [18:43:53 EDT(-0400)] <Bosmo1> requestAlteration() ? [18:44:22 EDT(-0400)] <Bosmo1> "requestChange" just sounds rather bland [18:44:27 EDT(-0400)] <colinclark> right... two methods [18:44:31 EDT(-0400)] <Bosmo1> The sort of thing that the Sakai community like to do a lot [18:44:34 EDT(-0400)] <colinclark> fireAlterationRequest() [18:44:39 EDT(-0400)] <colinclark> and requestAlteration() [18:44:43 EDT(-0400)] <Bosmo1> Without really having any clear conception of the kind of Change they want [18:45:18 EDT(-0400)] <colinclark> lol [18:45:42 EDT(-0400)] <colinclark> anastasiac was just asking the difference between those two methods... [18:45:53 EDT(-0400)] <colinclark> requestAlteration() just packages up a DAR and fires [18:46:00 EDT(-0400)] <colinclark> so here's my vote [18:46:07 EDT(-0400)] <colinclark> we call the thing a ChangeApplier [18:46:07 EDT(-0400)] <Bosmo1> yes, that's right [18:46:27 EDT(-0400)] <anastasiac> +1 for ChangeApplier [18:46:29 EDT(-0400)] <colinclark> When a component is given one, it will be called that.applier [18:46:43 EDT(-0400)] <colinclark> and the to request an alteration, you'd call [18:46:52 EDT(-0400)] <colinclark> that.applier.requestChange(path, value, type); [18:46:57 EDT(-0400)] <colinclark> bland though it is [18:47:02 EDT(-0400)] <Bosmo1> Well [18:47:09 EDT(-0400)] <Bosmo1> I can go with everything, except "requestChange" [18:47:12 EDT(-0400)] <Bosmo1> That really is a bridge too far [18:47:26 EDT(-0400)] <colinclark> really? [18:47:37 EDT(-0400)] <colinclark> i mean, what is doing except allowing you to request a change to the model? [18:47:39 EDT(-0400)] <Bosmo1> I think so [18:47:43 EDT(-0400)] <Bosmo1> It is just a really terrible name [18:47:45 EDT(-0400)] <colinclark> it's as simple and clear as possible [18:47:54 EDT(-0400)] <colinclark> requestModelChange()? [18:48:04 EDT(-0400)] <Bosmo1> [18:48:07 EDT(-0400)] <colinclark> I mean, alteration and change are reall just synonyms here. [18:48:15 EDT(-0400)] <anastasiac> Bosmo1, what do you suggest? [18:48:31 EDT(-0400)] <Bosmo1> Well, if we must have that, can't we name the whole thing an "AlterationApplier"? [18:48:59 EDT(-0400)] <colinclark> My argument is really just one of plain language. [18:49:15 EDT(-0400)] <colinclark> This is about providing a layer to help make changes to the model and notify others of the changes. [18:49:33 EDT(-0400)] <colinclark> Alteration is fine, it's just less straightforward and arguably less clear than "change." [18:50:24 EDT(-0400)] <colinclark> the thesaurus doesn't help us much [18:50:31 EDT(-0400)] <colinclark> first synonym for alteration is change [18:50:34 EDT(-0400)] <colinclark> and vice versa [18:52:17 EDT(-0400)] <colinclark> Bosmo1: I really hate naming. It's hard. [18:52:18 EDT(-0400)] <colinclark> And it's late [18:52:20 EDT(-0400)] <colinclark> I'm sorry. [18:52:32 EDT(-0400)] <colinclark> But can we live with ChangeApplier.requestChange()? [18:52:40 EDT(-0400)] <colinclark> ChangeApplier.makeRequest()? [18:52:45 EDT(-0400)] <colinclark> ChangeApplier.modelRequest()? [18:52:48 EDT(-0400)] <colinclark> Anything? [18:53:15 EDT(-0400)] <Bosmo1> Sorry, it was tea [18:53:17 EDT(-0400)] <colinclark> no worries [18:53:31 EDT(-0400)] <colinclark> i'm just late for my sailing class, but feeling horribly guilty for rushing all of this [18:53:50 EDT(-0400)] <colinclark> after all, it is uncivilized for us to be asking you all these questions at such a late hour [18:54:01 EDT(-0400)] <colinclark> for you, i mean [18:55:34 EDT(-0400)] <colinclark> Bosmo1: Ok, I'm going to have to run... [18:55:39 EDT(-0400)] <colinclark> Think about it a bit. Send me an email. [18:55:54 EDT(-0400)] <colinclark> If I don't hear from you, I can change it to ChangeApplier.requestChange() this evening or early tomorrow before code freeze. [18:55:56 EDT(-0400)] <colinclark> Seem cool? [18:56:09 EDT(-0400)] <colinclark> if anyone else comes up with awesome alternatives, email the list [19:17:24 EDT(-0400)] <Bosmo1> oops [23:02:15 EDT(-0400)] * colinclark (n=colin@bas2-toronto09-1176131209.dsl.bell.ca) has joined #fluid-work [23:21:37 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-69-153.dsl.mdsnwi.sbcglobal.net) has joined #fluid-work