fluid-work IRC Logs-2011-05-27

Owned by Fluid IRC Log Bot
Last updated: May 27, 2011Version comment
26 min read

[08:26:26 CDT(-0500)] <colinclark> thanks for your code review, cindyli
[08:26:38 CDT(-0500)] <cindyli> np, colinclark
[08:26:44 CDT(-0500)] <colinclark> vitals.inc.php does make sense for this
[08:26:54 CDT(-0500)] <cindyli> great
[08:26:58 CDT(-0500)] <colinclark> I'll make those updates today
[08:27:06 CDT(-0500)] <cindyli> while reviewing urs, i found some bad of mine. should i fix in my branch, commit and u merge?
[08:27:10 CDT(-0500)] <cindyli> thx, colinclark
[08:27:35 CDT(-0500)] <colinclark> cindyli: It's up to you
[08:27:43 CDT(-0500)] <colinclark> Why don't I just give you push access to that repo?
[08:27:53 CDT(-0500)] <cindyli> ah, sounds good. thx
[08:37:22 CDT(-0500)] <Justin_o> colinclark: where can i test the fix for FLUID-4256
[08:37:35 CDT(-0500)] <Justin_o> do i need it to run off of a server, or will the demo exhibit the problem?
[08:39:55 CDT(-0500)] <colinclark> Justin_o: You'll need to try it with the new Image Gallery server
[08:40:20 CDT(-0500)] <Justin_o> colinclark: ah okay.. thanks
[08:40:58 CDT(-0500)] <colinclark> I had trouble understanding which function you thought should be an invoker, Justin_o?
[08:41:02 CDT(-0500)] <colinclark> I'm sure you're right (smile)
[08:42:15 CDT(-0500)] <Justin_o> colinclark: oh the comment didn't show up with the code for you? (sad)
[08:42:28 CDT(-0500)] <colinclark> It sort of did
[08:42:35 CDT(-0500)] <colinclark> maybe I'm just kind of dumb (tongue)
[08:42:51 CDT(-0500)] <Justin_o> it's the one on line 148 of HTML5UploaderSupport.js
[08:43:20 CDT(-0500)] <colinclark> Ah, the call to monitorFileUploadXHR()
[08:43:50 CDT(-0500)] <colinclark> I think there's a comment somewhere in the vicinity of the definition of that function saying that it really needs to be refactored
[08:43:55 CDT(-0500)] <colinclark> even the name hints at it
[08:44:02 CDT(-0500)] <colinclark> this should really be a component
[08:44:31 CDT(-0500)] <colinclark> it's a kind of bridge between the raw status change events of an XHR instance and the events of the Uploader
[08:44:46 CDT(-0500)] <colinclark> So I agree with your comment, and figure we should go even a little further
[08:44:59 CDT(-0500)] <colinclark> I didn't in this pull request, just to keep it focused on the topic at hand
[08:45:04 CDT(-0500)] <colinclark> but I'm happy to if you think I should
[08:45:31 CDT(-0500)] <cindyli> colinclark: i will fix the move of parse_ini_file() into vitals, since i'm working on it. is it ok?
[08:45:41 CDT(-0500)] <colinclark> thanks so much, cindyli!
[08:45:45 CDT(-0500)] <cindyli> np
[08:46:48 CDT(-0500)] <Justin_o> colinclark: will that refactoring be part of any of the other open jiras
[08:46:54 CDT(-0500)] <Justin_o> for uploader?
[08:46:57 CDT(-0500)] <colinclark> On bug parade?
[08:47:00 CDT(-0500)] <colinclark> Not currently
[08:47:06 CDT(-0500)] <Justin_o> colinclark: okay..
[08:47:18 CDT(-0500)] <Justin_o> colinclark: would you be comfortable with it shipping like this?
[08:47:41 CDT(-0500)] <Justin_o> is it something that people are likely to want to configure?
[08:47:55 CDT(-0500)] <colinclark> No
[08:47:59 CDT(-0500)] <colinclark> There's only one implementation
[08:48:08 CDT(-0500)] <colinclark> it's largely an internal thing
[08:48:26 CDT(-0500)] <colinclark> but those are often famous last words, I guess
[08:50:46 CDT(-0500)] <Justin_o> colinclark: does this make sense.. file a jira if there isn't one..and make it a higher priority for the next release
[08:50:57 CDT(-0500)] <colinclark> sure, I can do that
[08:51:08 CDT(-0500)] <Justin_o> and for this release leave it as is, or make it an invoker for now if you think that's bette
[08:51:10 CDT(-0500)] <Justin_o> better
[08:51:20 CDT(-0500)] <Justin_o> i'll rely on your judgement for that last part
[08:51:50 CDT(-0500)] <Justin_o> and by better i guess i just mean worth it for this release and won't cause backwards compatability issues when we fix it for next release
[08:52:58 CDT(-0500)] <colinclark> yeah
[08:53:02 CDT(-0500)] <colinclark> maybe I should just fix the real issue
[08:53:07 CDT(-0500)] <colinclark> Here's the JIRA: http://issues.fluidproject.org/browse/FLUID-4268
[08:53:23 CDT(-0500)] <colinclark> If you want to bug parade it, I can probably squash it pretty quickly
[08:53:34 CDT(-0500)] <Justin_o> colinclark: okay.. will do
[08:54:22 CDT(-0500)] <Justin_o> colinclark: so i guess i could push FLUID-4256 in once i get it tested then
[08:54:30 CDT(-0500)] <colinclark> Justin_o: I think I would, yes
[08:54:42 CDT(-0500)] <colinclark> It's a fairly major bug
[08:54:45 CDT(-0500)] <colinclark> and this does indeed fix it
[08:55:45 CDT(-0500)] <Justin_o> colinclark: okay.. i'll pull down the new image gallery now then and see if i can get it running to test this
[08:55:52 CDT(-0500)] <colinclark> Justin_o: Cool
[08:55:59 CDT(-0500)] <colinclark> Let me know what you think of the new Gallery while you're at it
[08:56:19 CDT(-0500)] <Justin_o> colinclark, cindyli: yes.. is it ready for review and push yet too?
[08:56:36 CDT(-0500)] <colinclark> One thing that occurred to me was that, even though it's not intended as a real demo, it might need some L&F love
[08:56:53 CDT(-0500)] <colinclark> jameswy: I've been meaning to ask you about that for a few days and keep forgetting
[08:57:17 CDT(-0500)] <colinclark> We have this server we use for testing the Uploader--an "image gallery"
[08:57:27 CDT(-0500)] <colinclark> It's primarily just used for QA
[08:57:40 CDT(-0500)] <colinclark> but it is posted on our daily build site, meaning people can try it out themselves
[08:57:51 CDT(-0500)] <colinclark> it's a classic "developer UI" (wink)
[08:59:34 CDT(-0500)] <jameswy> colinclark: Haha. We're a bit backlogged right now with design tasks because of the IDI. Were you thinking it'd be good to have a look over the UI for the 1.4 release?
[08:59:42 CDT(-0500)] <colinclark> Yeah, that's what I figured
[08:59:54 CDT(-0500)] <colinclark> jameswy: I was thinking a bit of lipstick might be fine for 1.4
[09:00:04 CDT(-0500)] <colinclark> I can imagine this might, for 1.5 or 1.6, become a full-fledged demo
[09:00:28 CDT(-0500)] <colinclark> But don't let it get in the way of the IDI site, I know there's a lot to do there
[09:01:36 CDT(-0500)] <jameswy> colinclark: Where can I see the current build? It's not under the demo portal, is it?
[09:01:41 CDT(-0500)] <colinclark> no
[09:01:53 CDT(-0500)] <colinclark> it's linked to from http://build.fluidproject.org
[09:01:56 CDT(-0500)] <colinclark> but promise you won't cry (wink)
[09:02:18 CDT(-0500)] <colinclark> Ooh, it's crashed
[09:02:55 CDT(-0500)] <cindyli> Justin_o: my code review on colinclark's new image gallery is done. however, i noticed a few not-so-nice things i introduced, so, i'm now working on colinclark's branch to correct them. will do a push soon. u may wanna hold off on ur review till my push is in
[09:03:11 CDT(-0500)] <colinclark> jameswy: Okay, don't sweat it until we get the new version launched
[09:03:19 CDT(-0500)] <Justin_o> cindyli: okay
[09:03:24 CDT(-0500)] <cindyli> thx
[09:03:27 CDT(-0500)] <jameswy> Alrighty.
[09:17:13 CDT(-0500)] <michelled> heidi_, cindyli: looks like I'm done to my last conflict to resolve
[09:17:35 CDT(-0500)] <michelled> could you take a look at this and tell me what you actually expect in slidingPanel finalInit? http://pastebin.com/ipdzrMaL
[09:17:59 CDT(-0500)] <heidi_> looking...
[09:18:49 CDT(-0500)] <heidi_> michelled , the top one that.locate("toggleButton").text(that.options.strings.hideText); that.show(that.locate("panel"), that.events.afterPanelShown.fire);
[09:19:10 CDT(-0500)] <michelled> ok, thx heidi_
[09:19:19 CDT(-0500)] <heidi_> np
[09:25:09 CDT(-0500)] <harriswong> Justin_o:
[09:25:11 CDT(-0500)] <harriswong> woops
[09:25:16 CDT(-0500)] <harriswong> Justin_o: ping
[09:25:58 CDT(-0500)] <Justin_o> harriswong: hello
[09:28:57 CDT(-0500)] <yura__> mlam: do you know if your fix for form data is in the main branch yet ?
[09:29:07 CDT(-0500)] <mlam> yura__: No, it's not in yet
[09:29:16 CDT(-0500)] <harriswong> Justin_o: I went through the blockers. There is only 1 issue without assignee , FLUID-4169.
[09:29:28 CDT(-0500)] <yura__> oh alright, apparently we already have jiras filed against this in cspace (smile))
[09:29:34 CDT(-0500)] <yura__> mlam: ^
[09:29:47 CDT(-0500)] <mlam> colinclark: any chance we can get the refactored fileSender component into the repo today?
[09:30:14 CDT(-0500)] <Justin_o> mlam: FLUID-4256?
[09:30:17 CDT(-0500)] <mlam> yura__: Ok, thanks for letting me know
[09:30:39 CDT(-0500)] <mlam> Justin_o: yah that's the one
[09:30:52 CDT(-0500)] <harriswong> Justin_o: Would you like me to confirm the assigned ones for you?
[09:30:56 CDT(-0500)] <Justin_o> mlam, yura__ : i'll be pushing it in after i test it out..
[09:31:09 CDT(-0500)] <mlam> ok,thanks Justin_o.
[09:31:25 CDT(-0500)] <mlam> it seems to be a popular request the past couple days (smile)
[09:31:27 CDT(-0500)] <yura__> (smile)
[09:31:45 CDT(-0500)] <Justin_o> harriswong: which ones are still open?
[09:34:03 CDT(-0500)] <harriswong> Justin_o: Framework, 4169, 3716; ImageReorderer: 3953; Infusion Builder: 4122; IoC: 4178, 3716; Tech doc: 3716; UIO: 4234; Uploader: 4223, 3999
[09:35:03 CDT(-0500)] <harriswong> Justin_o: 1796 is unresolved, but closed.
[09:36:30 CDT(-0500)] <mlam> heidi_: jameswy, how far off you two from finishing up the no-preview demo for UI options?
[09:37:11 CDT(-0500)] <heidi_> mlam pretty much done but i'm going through all the templates and cleaning up the css... making sure its consistent etc. i can push what i have, but what do oyu need it for?
[09:37:39 CDT(-0500)] <mlam> I was planning to test the auto save component later today
[09:40:07 CDT(-0500)] <michelled> heidi_, cindyli: the UIOptions merge branch is ready now - you should probably take a look at it to see if it has what you expect. Also, when you are pushing changes to your individual branches you'll need to also push the changes to the 4267 branch
[09:40:20 CDT(-0500)] <michelled> mlam: are you also working on a branch that should be merged in here?
[09:40:29 CDT(-0500)] <heidi_> mlam it doesn't use auto save - just the fat panel will
[09:40:43 CDT(-0500)] <heidi_> oh, tho i guess it's a choice? the full versions have save buttons
[09:41:02 CDT(-0500)] <heidi_> michelled that's awesome, thanks so much
[09:41:13 CDT(-0500)] <mlam> yah, the auto-save is now a component option, so i guess it should be available everywhere
[09:41:35 CDT(-0500)] <cindyli> michelled: sounds that we should keep our own branch in sync with the merge branch, right?
[09:41:38 CDT(-0500)] <michelled> fluid-everyone: if you are working on ui options you should probably start with the 4267 branch instead of master
[09:41:43 CDT(-0500)] <michelled> cindyli: yep
[09:41:46 CDT(-0500)] <mlam> michelled: um, i'm working off of cindyli's 4216 branch
[09:41:49 CDT(-0500)] <cindyli> cool
[09:41:52 CDT(-0500)] <heidi_> mlam it'd be weird to use auto save and also have save buttons. hmm!
[09:42:00 CDT(-0500)] <heidi_> but i guess possible
[09:42:05 CDT(-0500)] <heidi_> or is it one or the other?
[09:42:35 CDT(-0500)] <michelled> anastasiac: here's the branch: https://github.com/michelled/infusion/tree/FLUID-4267
[09:42:40 CDT(-0500)] <cindyli> mlam: seems now u need to work off the new 4267 branch
[09:42:44 CDT(-0500)] <mlam> Yah, I was talking to cindyli about that yesterday. But I think it was decided at the dev meeting that the auto-save would be a component option. So i think if it's an option, it would be possible to auto-save anywhere
[09:42:47 CDT(-0500)] <michelled> mlam: are you pushing to cindyli's branch?
[09:42:58 CDT(-0500)] <mlam> cindyli: Yah, I'll do that now
[09:43:05 CDT(-0500)] <cindyli> thx
[09:43:23 CDT(-0500)] <cindyli> michelled: mlam has his own branch for auto save to push in
[09:43:38 CDT(-0500)] <mlam> michelled: No, not yet.
[09:43:51 CDT(-0500)] <mlam> michelled: Yah, I've merged cindyli's 4216 branch into my own repo
[09:44:01 CDT(-0500)] <cindyli> seems that mlam's branch should also be included into 4267
[09:44:05 CDT(-0500)] <anastasiac> thanks
[09:44:30 CDT(-0500)] <michelled> mlam: have you done some commits of your own in your branch?
[09:44:37 CDT(-0500)] <mlam> not yet michelled
[09:44:44 CDT(-0500)] <harriswong> Justin_o: is there anything else you would like me to look at?
[09:44:57 CDT(-0500)] <michelled> ok, then I think you should delete it and rebranch off 4267
[09:45:13 CDT(-0500)] <michelled> or merge 4267 in - what ever is easier
[09:45:40 CDT(-0500)] <mlam> Ok
[09:48:41 CDT(-0500)] <michelled> mlam, cindyli, heidi_, anastasiac: you all have push access to my repo now so you can keep the 4267 branch updated
[09:48:52 CDT(-0500)] <mlam> cool, thanks michelled
[09:49:00 CDT(-0500)] <anastasiac> thanks, michelled.
[09:49:01 CDT(-0500)] <cindyli> nice. thx
[09:49:03 CDT(-0500)] <michelled> np
[09:49:19 CDT(-0500)] <colinclark> mlam, heidi_ In terms of autosave, I think we're just talking about common sense here
[09:49:23 CDT(-0500)] <colinclark> yes, it's a configurable option
[09:49:26 CDT(-0500)] <anastasiac> heidi_, I'll merge that test page I created into michelled's branch, as well as the yellow/black themes (once they're done)
[09:49:37 CDT(-0500)] <colinclark> and yes, it would be insane to include buttons in the UIO user interface when autosave was enabled
[09:50:01 CDT(-0500)] <heidi_> anastasiac - that's perfect
[09:50:15 CDT(-0500)] <michelled> mlam, cindyli, heidi_, anastasiac: if you are doing new work that you are going to merge into the branch please update the JIRA with a link to your branch
[09:50:24 CDT(-0500)] <michelled> http://issues.fluidproject.org/browse/FLUID-4267
[09:50:34 CDT(-0500)] <heidi_> michelled will do, am going to merge in the full no preview branch soon
[09:51:08 CDT(-0500)] <cindyli> sure, michelled
[09:51:58 CDT(-0500)] <heidi_> colinclark yeah, so allowed but not recommended
[09:52:23 CDT(-0500)] <colinclark> seems reasonable to me
[09:55:10 CDT(-0500)] <cindyli> Justin_o: git help. i have colin's image gallery github as a remote, how can i push changes into?
[09:55:43 CDT(-0500)] <cindyli> Justin_o: i did: git config remote.colin.url [colin-github-http-url]
[09:55:47 CDT(-0500)] <cindyli> git add ...
[09:55:51 CDT(-0500)] <cindyli> git commit ...
[09:55:58 CDT(-0500)] <cindyli> git push colin colin/master
[09:56:43 CDT(-0500)] <Justin_o> harriswong: sorry.. missed your message
[09:56:46 CDT(-0500)] <cindyli> was asked for password at push. i did something wrong? Justin_o
[09:56:54 CDT(-0500)] <Justin_o> did you want to look at 4169
[09:57:00 CDT(-0500)] <Justin_o> harriswong: ^^
[09:57:11 CDT(-0500)] <colinclark> cindyli: you're cindyli on github, right?
[09:57:17 CDT(-0500)] <cindyli> yes
[09:57:33 CDT(-0500)] <harriswong> Justin_o: Will do
[09:57:59 CDT(-0500)] <Justin_o> cindyli: so two things.. 1) make sure that colinclark has given you permission.. 2) make sure you are not using a readonly url
[09:58:08 CDT(-0500)] <Justin_o> harriswong: thanks
[09:58:12 CDT(-0500)] <colinclark> cindyli: I did add you as a collaborator
[09:58:32 CDT(-0500)] <cindyli> colinclark: Justin_o, i did received the email of the permission grant
[09:59:09 CDT(-0500)] <Justin_o> cindyli: you might want to just remove the remote and re-add it
[09:59:15 CDT(-0500)] <Justin_o> cindyli: git remote rm remoteName
[09:59:27 CDT(-0500)] <Justin_o> then do the git remote add remoteName url again
[09:59:42 CDT(-0500)] <cindyli> sounds good. trying, Justin_o thx
[10:13:14 CDT(-0500)] <Justin_o> cindyli, colinclark : okay finally got apache working on my machine.. some setting buried in one of the configs was incorrect (sad)
[10:13:38 CDT(-0500)] <Justin_o> cindyli, colinclark: when i'm trying to upload files though i'm getting a 403 error message on the page
[10:13:50 CDT(-0500)] <Justin_o> the permissions for the temp directory are wide open though.. any thoughts?
[10:14:08 CDT(-0500)] <colinclark> did you run the install script?
[10:14:17 CDT(-0500)] <Justin_o> yes
[10:14:27 CDT(-0500)] <Justin_o> it created the temp directory for me
[10:16:01 CDT(-0500)] <Justin_o> colinclark: never mind.. forgot they had to be images.. oops
[10:16:52 CDT(-0500)] <colinclark> we should perhaps improve the error messages
[10:17:20 CDT(-0500)] <Justin_o> colinclark: i guess that will be improved once the uploader error messaging support is added
[10:17:44 CDT(-0500)] <colinclark> yup
[10:17:44 CDT(-0500)] <Justin_o> by the way.. the fix looks like it's working
[10:18:23 CDT(-0500)] <colinclark> cool!
[10:28:15 CDT(-0500)] <Justin_o> colinclark, mlam, yura__ : FLUID-4256 is in
[10:28:26 CDT(-0500)] <mlam> cool, thanks Justin_o
[10:28:31 CDT(-0500)] <colinclark> thanks!
[10:28:45 CDT(-0500)] <mlam> cindyli: ^^ the FormData fix is in
[10:28:59 CDT(-0500)] <yura__> sweet thanks
[10:29:06 CDT(-0500)] <cindyli> great. thx
[10:49:19 CDT(-0500)] <jessm> fluid-everyone, this is the event that aaron is coming to Toronto to attend: http://www.rhok.org/event/toronto
[10:49:26 CDT(-0500)] <jessm> perhaps some of your would be interested in it
[10:49:40 CDT(-0500)] <jessm> he'll also be joining y'all on the 2nd floor on thurs. and fri next week!
[10:49:41 CDT(-0500)] <jessm> yay
[10:50:38 CDT(-0500)] <colinclark> That'll be great
[10:51:25 CDT(-0500)] <Justin_o> jessm: that's really good that we'll get to meet him in person so soon
[10:51:50 CDT(-0500)] <jessm> it is awesome
[11:20:01 CDT(-0500)] <cindyli> Justin_o: finally, my changes made into colinclark's image gallery branch. you may wanna go ahead with the code review.
[11:20:54 CDT(-0500)] <Justin_o> cindyli: sure will do, thanks
[11:21:04 CDT(-0500)] <cindyli> np
[11:31:42 CDT(-0500)] <heidi_> hey jameswy , i see there's a FullUIOptions.css and a FullPreviewUIOptions and a FullNoPreview.css - which one are you using for full w/ preview?
[11:32:14 CDT(-0500)] <heidi_> i'm guessing FullUIOptions.css is old?
[11:33:23 CDT(-0500)] <heidi_> er, FullPreview looks not used anymore
[11:34:22 CDT(-0500)] <heidi_> or it's for both? haha...ahh
[11:34:27 CDT(-0500)] <jameswy> heidi_: FullUIOptions applies to both w/ and w/o preview
[11:34:36 CDT(-0500)] <heidi_> hmm
[11:34:37 CDT(-0500)] <heidi_> ok
[11:34:53 CDT(-0500)] <jameswy> The other two apply to w/ and w/o preview respectively.
[11:35:51 CDT(-0500)] <colinclark> should FullUIOptions.css be named something like UIOptionsBase.css?
[11:37:08 CDT(-0500)] <jameswy> colinclark: Probably not--the other UIOs (fat, skinny panels) don't draw from it.
[11:37:15 CDT(-0500)] <jameswy> We already have a UIOptions.css that acts as the base.
[11:39:53 CDT(-0500)] <jameswy> Hm. Actually, adopting a convention of FullUIOptionsBase.css and UIOptionsBase.css sounds like it'd be a good idea.
[11:42:35 CDT(-0500)] <heidi_> jameswy i'm not sure we need a separate globally one for the full version
[11:42:43 CDT(-0500)] <heidi_> i'd like to keep things simple and clean
[11:43:51 CDT(-0500)] <heidi_> i'll see what i can do otherwise the base naming sounds good
[11:44:20 CDT(-0500)] <colinclark> ahh, I see jameswy
[11:44:22 CDT(-0500)] <colinclark> it's for full-only
[11:44:28 CDT(-0500)] <colinclark> but both with and without preview
[11:44:30 CDT(-0500)] <colinclark> makes sense to me
[11:44:46 CDT(-0500)] <colinclark> but heidi_ knows these things better than me (smile)
[11:45:11 CDT(-0500)] <heidi_> i'll see what works best!
[11:45:31 CDT(-0500)] <heidi_> jameswy i'm just noticing there's stuff in full i want in fat ... so it becomes more uiobasey
[11:45:42 CDT(-0500)] <heidi_> funny statement
[11:46:15 CDT(-0500)] <jameswy> heidi_: Excellent. If we can flatten it out the css a bit, that'd be awesome.
[12:25:16 CDT(-0500)] <colinclark> Hey huslage, were my directions to the office even slightly comprehensible? (smile)
[12:25:23 CDT(-0500)] <huslage> yep
[12:25:27 CDT(-0500)] <huslage> they were fine
[12:25:30 CDT(-0500)] <colinclark> cool
[12:25:31 CDT(-0500)] <huslage> thanks
[12:25:36 CDT(-0500)] <colinclark> we're all super excited to meet you in person
[12:26:09 CDT(-0500)] <huslage> me too (smile)
[12:27:53 CDT(-0500)] <michelled> heidi_, cindyli: is there a fully working demo of UIO?
[12:28:11 CDT(-0500)] <heidi_> michelled the full w/ preview should work
[12:28:28 CDT(-0500)] <anastasiac> michelled, heidi_, jameswy, cindyli: I've pushed the new UIOptions test page to michelled's 4267 branch. It's in the standalone-demos folder. The page includes as many different ui widgets/fields/css stylings as I could think up, so transforming the page will test many things. Just showing the fat panel reveals some issues already (smile)
[12:28:54 CDT(-0500)] <cindyli> thx, anastasiac
[12:29:28 CDT(-0500)] <heidi_> anastasiac great thaks. we ditched the stand-alone demo for Uio, not sure if that matters
[12:29:49 CDT(-0500)] <jhung> justin_o, colinclark: jameswy pinged me about some work needed for a demo/tutorial? I don't have much time today, but Monday is better.
[12:29:51 CDT(-0500)] <anastasiac> heidi_, yes, I know - I wasn't sure where we should put this test page, so it's there for now. We can move it
[12:30:03 CDT(-0500)] <michelled> heidi_: the settings don't get applied in the full with preview
[12:30:04 CDT(-0500)] <heidi_> ok cool
[12:30:24 CDT(-0500)] <heidi_> cindyli is full w/ preview working?
[12:30:46 CDT(-0500)] <cindyli> should be working, heidi_
[12:30:47 CDT(-0500)] <Justin_o> jhung: thanks.. i guess i'll start in on something and have you check it out for me on monday
[12:31:06 CDT(-0500)] <cindyli> ok, michelled, let me take a look
[12:31:13 CDT(-0500)] <jhung> justin_o: k. Sounds good!
[12:35:39 CDT(-0500)] <cindyli> michelled: the settings applied right on me. were u trying src/webapp/demos/uiOptions/FullPreviewUIOptions/html/uiOptions.html?
[12:35:58 CDT(-0500)] <michelled> yes
[12:36:11 CDT(-0500)] <michelled> I guess I'll try to clear everything and see if that works
[12:37:15 CDT(-0500)] <cindyli> ok, michelled. the weird thing is the preview window turns quite small in demo. any styling change on preview recently, heidi_?
[12:37:42 CDT(-0500)] <michelled> cindyli: the preview gets updated but clicking save and apply doesn't transform the page
[12:38:03 CDT(-0500)] <cindyli> ic what u mean. trying more, michelled
[12:38:14 CDT(-0500)] <heidi_> cindyli the css might have affected the preview size yes, but would that break things? I'm fixing the overall styling of all 3 now
[12:38:22 CDT(-0500)] <michelled> reset and cancel also don't work
[12:39:10 CDT(-0500)] <cindyli> heidi_: u may wanna have a look on this demo, full with preview, regrading preview window size
[12:39:23 CDT(-0500)] <heidi_> cindyli yes working on the styling of all the layouts now
[12:39:37 CDT(-0500)] <cindyli> thanks!
[12:39:46 CDT(-0500)] <heidi_> they all share a lot of css/html so cleaning up
[12:42:33 CDT(-0500)] <cindyli> michelled: figured out. line 332, bindHandlers() was commented out. haha, heidi_, might be u testing full w/o preview
[12:42:46 CDT(-0500)] <heidi_> :o my bad
[12:43:05 CDT(-0500)] <heidi_> i've since fixed that the proper way! (sending empty subcomponent)
[12:43:09 CDT(-0500)] <cindyli> alrite, putting it back would fix
[12:43:13 CDT(-0500)] <heidi_> sorry dudes
[12:43:25 CDT(-0500)] <michelled> np, will you push your fix heidi_?
[12:43:35 CDT(-0500)] <michelled> thanks for looking into it cindyli (smile)
[12:43:43 CDT(-0500)] <cindyli> np
[12:43:44 CDT(-0500)] <heidi_> yes... now which branch was that in...
[12:43:57 CDT(-0500)] <cindyli> 4267
[12:45:07 CDT(-0500)] <michelled> the branches that were merged in were 4230, 4216, 4217 and 4203
[12:47:49 CDT(-0500)] <heidi_> got it
[12:49:32 CDT(-0500)] <heidi_> michelled trying to push but it's asking me to login
[12:50:04 CDT(-0500)] <michelled> Justin_o: have you seen that before? ^
[12:50:30 CDT(-0500)] <heidi_> do you have to add my key or something?
[12:50:39 CDT(-0500)] <Justin_o> michelled: yes.. with cindy's computer earlier today
[12:50:41 CDT(-0500)] <heidi_> or maybe i'm just putting the wrong username (my github name?)
[12:50:47 CDT(-0500)] <Justin_o> heidi_: could be
[12:50:59 CDT(-0500)] <heidi_> Justin_o it should work?
[12:51:06 CDT(-0500)] <Justin_o> you could also switch to using the ssh url if you have an ssh key setup
[12:51:25 CDT(-0500)] <heidi_> oh i might've put in the wrong remote url for michelle
[12:51:42 CDT(-0500)] <Justin_o> heidi_: yes... i think you should have been able to do that.. it wasn't working for cindyli today either though.. so maybe there's something wrong on the github end
[12:51:52 CDT(-0500)] <Justin_o> heidi_: that could be it too
[12:52:45 CDT(-0500)] <cindyli> heidi_: which branch were you in at push?
[12:53:18 CDT(-0500)] <cindyli> i figured out later that i cannot push from say, colin/master, i need to merge his branch into mine and push from my branch
[12:57:00 CDT(-0500)] <heidi_> Justin_o is there a way to edit a remote entry
[12:57:21 CDT(-0500)] <heidi_> cindyli yeah am gonna push from mine into michelle's branch, she gave me push access... should work
[12:57:56 CDT(-0500)] <cindyli> cool
[12:58:00 CDT(-0500)] <Justin_o> heidi_: you can just delete and readd it
[12:58:06 CDT(-0500)] <Justin_o> git remote rm remoteName
[12:58:16 CDT(-0500)] <heidi_> that makes sense
[12:58:17 CDT(-0500)] <heidi_> thanks
[12:58:17 CDT(-0500)] <Justin_o> git remote add remoteName remoteURL
[12:58:31 CDT(-0500)] <cindyli> another way is to change the config
[12:58:49 CDT(-0500)] <cindyli> git config remote.michelle.url [michelle-github-ssh-url]
[12:59:30 CDT(-0500)] <heidi_> thanks cindyli
[12:59:36 CDT(-0500)] <cindyli> anytime
[12:59:36 CDT(-0500)] <heidi_> Justin_o i would use git@github.com:michelled/infusion.git ?
[13:00:51 CDT(-0500)] <cindyli> yes, heidi_, the ssh one
[13:01:03 CDT(-0500)] <heidi_> Justin_o cindyli i get error: src refspec FLUID-4267 does not match any. error: failed to push some refs to 'git@github.com:michelled/infusion.git'
[13:01:12 CDT(-0500)] <heidi_> oh wait...
[13:01:27 CDT(-0500)] <heidi_> yeah
[13:01:34 CDT(-0500)] <heidi_> i'm running git push michelle FLUID-4267 from my branch
[13:01:42 CDT(-0500)] <heidi_> that's wrong tho... sorry
[13:02:00 CDT(-0500)] <cindyli> good that u figure out
[13:02:03 CDT(-0500)] <heidi_> or is it? ah, confused
[13:02:34 CDT(-0500)] <heidi_> what am i doing wrong cindyli?
[13:02:35 CDT(-0500)] <michelled> heidi_: is your branch merged with 4267?
[13:02:43 CDT(-0500)] <cindyli> that push seems right
[13:02:49 CDT(-0500)] <cindyli> yes, i can try push
[13:02:53 CDT(-0500)] <heidi_> michelled i have to merge in 4267 first?
[13:03:08 CDT(-0500)] <cindyli> yes, mine merged with 4267
[13:03:16 CDT(-0500)] <michelled> heidi_: if you have a copy of 4267 in your repo
[13:03:20 CDT(-0500)] <michelled> then you merge in your branch
[13:03:27 CDT(-0500)] <michelled> then you do your push command, that will work
[13:03:39 CDT(-0500)] <heidi_> umm
[13:03:49 CDT(-0500)] <heidi_> so i have to create my own 4267
[13:03:52 CDT(-0500)] <heidi_> from yours
[13:03:56 CDT(-0500)] <heidi_> merge in my branch
[13:03:57 CDT(-0500)] <michelled> your command is saying 'replace michelle's 4267 with my 4267
[13:03:57 CDT(-0500)] <heidi_> then push?
[13:04:19 CDT(-0500)] <michelled> heidi_: yep
[13:04:30 CDT(-0500)] <heidi_> okay i'll try that!
[13:04:38 CDT(-0500)] <michelled> if you don't then you'll be saying 'replace michelle's 4267 with my branch x'
[13:05:27 CDT(-0500)] <heidi_> yikes
[13:08:59 CDT(-0500)] <cindyli> heidi_: I've pushed change into michelled's 4267
[13:09:11 CDT(-0500)] <cindyli> heidi_: the push command - git push michelle FLUID-4216:FLUID-4267
[13:09:42 CDT(-0500)] <heidi_> cindyli now i'm more confused... is this an alternative to creating my own 4267?
[13:09:54 CDT(-0500)] <cindyli> no, u don't have to create ur own 4267
[13:10:01 CDT(-0500)] <cindyli> for instance, u have 4230
[13:10:05 CDT(-0500)] <cindyli> u do:
[13:10:15 CDT(-0500)] <cindyli> git remote add michelle [ssh-url]
[13:10:18 CDT(-0500)] <cindyli> git fetch michelle
[13:10:28 CDT(-0500)] <cindyli> git merge michelle/FLUID-4267
[13:10:43 CDT(-0500)] <cindyli> at push: git push michelle FLUID-4230:FLUID-4267
[13:10:46 CDT(-0500)] <heidi_> cindyli but i don't want to merge 4267 into my branch?
[13:10:58 CDT(-0500)] <cindyli> ah, why?
[13:11:15 CDT(-0500)] <heidi_> michelled Justin_o is there a pref to merging small branch into big branch vs. big branch into small?
[13:11:16 CDT(-0500)] <cindyli> i think we all have to work with the most recent code
[13:11:34 CDT(-0500)] <heidi_> cindyli i think we're doing the same thing, just switched
[13:11:39 CDT(-0500)] <cindyli> ok
[13:12:35 CDT(-0500)] <heidi_> Justin_o thoughts?
[13:13:46 CDT(-0500)] <michelled> heidi_: my preference is to merge into the 4267 branch and then push that
[13:13:52 CDT(-0500)] <michelled> but either is fine
[13:14:54 CDT(-0500)] <heidi_> michelled before i pushed, i had to merge in the new remote 4267 stuff anyway
[13:16:21 CDT(-0500)] <Justin_o> heidi_, michelled: it might be clearer to think of the 4267 branch as a pseudo master branch
[13:17:26 CDT(-0500)] <michelled> Justin_o: when 4267 finally gets merged into master we'll be sure to use --no-ff so all our merging backward and forward won't matter too much
[13:18:04 CDT(-0500)] <michelled> Justin_o: are you suggesting that we use the same techniques that we currently use for master when merging into 4267?
[13:18:07 CDT(-0500)] <heidi_> ah cool
[13:23:52 CDT(-0500)] <heidi_> michelled did my push work/full w preview functioning again?
[13:24:36 CDT(-0500)] <heidi_> i'm gonna add in my style fixes soon
[13:28:06 CDT(-0500)] <michelled> heidi_: yep, full with preview works again but fat panel and no preview throw errors now
[13:28:23 CDT(-0500)] <heidi_> michelled yep that'll get fixed
[13:28:42 CDT(-0500)] <michelled> cool
[13:30:10 CDT(-0500)] <Justin_o> michelled: since you'll do a --no-ff when merging 4267 into the project repo you probably don't have to be as strict, but it might be easier to keep the branches separate when working so it's easier to keep track of.. i don't really have too much of a preference either way though
[13:52:56 CDT(-0500)] <heidi_> michelled Justin_o is fss clearfix in trunk?
[13:53:24 CDT(-0500)] <michelled> heidi_: we are waiting to hear about licensing on the code
[13:55:10 CDT(-0500)] <heidi_> michelled justin sent an email this morning with their response
[13:55:23 CDT(-0500)] <heidi_> "Seems as though we just need to add a comment with it."
[13:56:41 CDT(-0500)] <Justin_o> heidi_: i was talking to colin about this the other day.. to be safe we will need to have an open source license provided for it
[13:59:23 CDT(-0500)] <heidi_> Justin_o where does that leave things? just wondering cos uio layouts use cleafix
[14:00:12 CDT(-0500)] <Justin_o> heidi_: right forgot about that..
[14:00:26 CDT(-0500)] <Justin_o> if we don't hear back we'll have to find another approriate clearfix that has a license
[14:04:07 CDT(-0500)] <heidi_> michelled i wonder if we can merge that clearfix branch into 4267 in the meantime?
[14:04:52 CDT(-0500)] <michelled> heidi_: I don't think we should
[14:05:03 CDT(-0500)] <michelled> we'll need to back it out if we can't use it
[14:05:10 CDT(-0500)] <michelled> but I can be convinced (smile)
[14:05:19 CDT(-0500)] <michelled> say, if you want to take responsibility for backing it out (wink)
[14:06:30 CDT(-0500)] <heidi_> michelled i think what could happen is the clearfix branch will change , swapping one class for another, but all should work the same
[14:06:48 CDT(-0500)] <heidi_> it'll still go in, cos we need clearfix right Justin_o
[14:07:50 CDT(-0500)] <Justin_o> heidi_: yes.. we do need a clearfix solution of some kind
[14:08:12 CDT(-0500)] <Justin_o> heidi_, michelled : is it not already in there from fluid-3782, i think jameswy was using it
[14:08:14 CDT(-0500)] <michelled> heidi_: if the work for redoing clearfix takes longer it will mean that the ui o branch will be waiting on that too
[14:08:20 CDT(-0500)] <michelled> before it can be merged into master
[14:08:26 CDT(-0500)] <Justin_o> michelled: good point
[14:08:39 CDT(-0500)] <jameswy> Yep, I was using the clearfix.
[14:08:40 CDT(-0500)] <Justin_o> michelled: but i think the styling may be dependent on it
[14:08:52 CDT(-0500)] <jameswy> And yep, the styling is dependent on it.
[14:09:02 CDT(-0500)] <michelled> ok, fair enough
[14:10:04 CDT(-0500)] <heidi_> okay
[14:11:15 CDT(-0500)] <heidi_> Justin_o i don't think it's in 3782
[14:11:33 CDT(-0500)] <heidi_> jameswy had a copy of it in our UIO css, but it was removed with hopes we could use the fss one (smile)
[14:12:39 CDT(-0500)] <Justin_o> heidi_: i see
[14:17:11 CDT(-0500)] <heidi_> Justin_o michelled so... can we merge it in?
[14:17:20 CDT(-0500)] <heidi_> can i do it on my end and push?
[14:18:16 CDT(-0500)] <Justin_o> heidi_: i'll leave it up to michelle since she is the gatekeeper of the merge branch
[14:22:21 CDT(-0500)] <anastasiac> Bosmon, do you have a moment for a question? I'm trying to wrap my head around demands vs. defaults, specifically: when would a component developer use demands for a subcomponent intead of defaults (aside from the obvious case of when you want a completely different component for different contexts). What are the use cases for this?
[14:23:13 CDT(-0500)] <colinclark> big question (smile)
[14:23:44 CDT(-0500)] <anastasiac> indeed
[14:23:54 CDT(-0500)] <Bosmon> Thanks, anastasiac
[14:24:19 CDT(-0500)] <Bosmon> Yes, primarily I see defaults being used in the case where the "primary integration scenario" for a tree of components is as a largely self-contained unit
[14:24:41 CDT(-0500)] <Bosmon> So, in some points of code review for UIOptions you will see places where I criticised some of the default layout because it contained references to things "outside the tree"
[14:24:58 CDT(-0500)] <Bosmon> This looks like the "first rule" to be followed - where you CAN write defaults for a component subtree, they need to be self-contained
[14:25:08 CDT(-0500)] <Bosmon> Where they can't be self-contained, you should not write them (smile)
[14:25:44 CDT(-0500)] <Bosmon> But I think it should be possible in all cases where defaults have been written for a tree section, that that entire section should be able to start up successfully using just those defaults
[14:25:53 CDT(-0500)] <Bosmon> I mean, this is sort of what "defaults" means, as a term (tongue)
[14:26:09 CDT(-0500)] <anastasiac> ok, so: if it's all inside the tree, you can use defaults, it not, you'll need demands
[14:26:17 CDT(-0500)] <anastasiac> is that a correct summary, Bosmon?
[14:26:21 CDT(-0500)] <anastasiac> so far?
[14:26:34 CDT(-0500)] <Bosmon> Well, it is sort of "logically correct" but I'm not sure its "morally correct" (tongue)
[14:26:42 CDT(-0500)] <Bosmon> It sort of poses the issue the wrong way round...
[14:26:52 CDT(-0500)] <anastasiac> how would you pose it?
[14:27:06 CDT(-0500)] <Bosmon> That is, in our design, we should be actively striving to write defaults that are self-contained
[14:27:20 CDT(-0500)] <Bosmon> And use demands to cover cases where we are orchestrating the interaction of components that are not necessarily related
[14:27:32 CDT(-0500)] <anastasiac> ah, gotcha
[14:28:07 CDT(-0500)] <colinclark> So, Bosmon, is the Uploader a good example of this in some way?
[14:28:14 CDT(-0500)] <Bosmon> Sometimes, it only makes sense for a group of components to interact in an arrangement where all of them are present
[14:28:21 CDT(-0500)] <Bosmon> But sometimes they interact in patterns which overlap in complex ways
[14:28:27 CDT(-0500)] <anastasiac> so: try to keep things related, and use defaults, and only use demands when you're deliberately (or can't avoid) working withthings that aren't related
[14:28:34 CDT(-0500)] <Bosmon> Yes, the Uploader I think is a good example of "mostly related" components
[14:28:49 CDT(-0500)] <anastasiac> ok, starting to make sense
[14:28:51 CDT(-0500)] <Bosmon> Wherease, for example, the Pager (when it is rewritten) would be an example of "not necessarily related" components
[14:29:06 CDT(-0500)] <anastasiac> maybe another use case would help me: https://github.com/michelled/infusion/blob/FLUID-4267/src/webapp/components/uiOptions/js/UIOptions.js#L596
[14:29:30 CDT(-0500)] <Bosmon> Our plan for that group was to present it as a "Table" component, "Pager proper" component, and then a "PagedTable" orchestrating the two
[14:29:41 CDT(-0500)] <anastasiac> why are these parameters to preview provided in demands, and not in the uiopts "components:" declaration of preview?
[14:29:43 CDT(-0500)] <Bosmon> In this case it makes sense to have a Table without a Pager, and also, to have a Pager without a Table
[14:30:26 CDT(-0500)] <Bosmon> And also to have both - whereas in the Uploader, in many cases it is not sensible to have "all the pieces" together - although in this case there is so much polymorphism that many things still need to be done with demands
[14:30:36 CDT(-0500)] <Bosmon> Let me look at that link...
[14:33:05 CDT(-0500)] <Bosmon> Well, I think this area is due for refactoring in any case
[14:33:11 CDT(-0500)] <Bosmon> We should look at it once it is finished
[14:33:58 CDT(-0500)] <anastasiac> so Bosmon, could those arguments have been specified in the defaults, somewhere around line 225?
[14:34:06 CDT(-0500)] <anastasiac> and would that have been better?
[14:34:27 CDT(-0500)] <Bosmon> WIth the current factoring, they could have been, yes
[14:34:38 CDT(-0500)] <Bosmon> And if we agreed with the factoring, it would have been better
[14:34:40 CDT(-0500)] <anastasiac> ok, good
[14:34:58 CDT(-0500)] <Bosmon> It also should have used the pseudoargument style "container" for the container
[14:35:04 CDT(-0500)] <Bosmon> Since it is really only overriding one argument
[14:35:49 CDT(-0500)] <michelled> heidi_: if you need clearfix in order to continue with styling then merge it in
[14:35:57 CDT(-0500)] <michelled> please note it on the JIRA for 4267
[14:36:08 CDT(-0500)] <anastasiac> so with your PagedTable example, Bosmon: the Table and Pager are basically independent, but would the PagedTable, which knows about the Pager and the Table, declare things in its dependencies declaration, instead of using demands? doesn't the PagedTable create the relationship between Pager and Table, making them 'related'?
[14:40:40 CDT(-0500)] <heidi_> michelled will do
[14:44:03 CDT(-0500)] <Bosmon> Well - it would probably be better for the "PagedTable" to just be a fairly dumb "container of things"
[14:44:26 CDT(-0500)] <Bosmon> We would not write demands blocks targetted at this name, since it would restrict people from creating other things which orchestrated Pagers and Tables
[14:45:04 CDT(-0500)] <Bosmon> In which case it would just be a "thing" containing a Pager and a Table, and demands blocks would act against ALL cases they could find both Pagers and Tables
[14:45:29 CDT(-0500)] <Bosmon> But who knows, we may not be able to make that design work... we would need to try it out (tongue)
[14:45:36 CDT(-0500)] <anastasiac> ah
[14:46:17 CDT(-0500)] <anastasiac> so demands are useful when the demand may be relevant in more than just the context of the component the developer is currently developing...
[14:46:22 CDT(-0500)] <Bosmon> It would seem to offer better genericity not to believe in the existence of the name "PagedTable", except as a code which instantiated a particular block of things... much like our "wrapper functions" we make for Reorderer configurations
[14:46:35 CDT(-0500)] <Bosmon> I think we were talking about wrapper functions with colinclark yesterday here
[14:46:51 CDT(-0500)] <Bosmon> And reflecting that IoC needs to provide better support for defining them declaratively
[14:47:31 CDT(-0500)] <Bosmon> Right now, given that a wrapper function IS not a "component" we can't make one with the equivalent of something like "autoInit"
[14:48:00 CDT(-0500)] <colinclark> Bosmon: Yes, I think that's ultimately the case, about wrapper functions
[14:48:02 CDT(-0500)] <Bosmon> We need a special syntax to express, "This thing is just a function which accepts some options, perhaps merges in some defaults, and then forwards to a proper creator function"
[14:48:16 CDT(-0500)] <colinclark> I can imagine a kind of thing much like a set of autoInit defaults...
[14:48:18 CDT(-0500)] <colinclark> which defines a name
[14:48:21 CDT(-0500)] <Bosmon> We can do this right now only in the case the "wrapper function name" actually makes a REAL component itself
[14:48:26 CDT(-0500)] <colinclark> and the variation in configuration from a base configuration
[14:48:29 CDT(-0500)] <colinclark> if that makes sense
[14:48:30 CDT(-0500)] <anastasiac> so broadly oversimplifying: if you're writing components that you expect to be modularly re-used and re-combined in different cases, use demands; if you're writing something that you know is pretty interdependent and isn't likely to be re-used in other cases, use defaults. Does that sum things up reasonably well, Bosmon?
[14:48:50 CDT(-0500)] <colinclark> hmm
[14:49:05 CDT(-0500)] <Bosmon> That seems somewhat right, anastasiac - but doesn't cover the case of the UPloader very well
[14:49:11 CDT(-0500)] <colinclark> I worry about that "you know it's interdependent and isn't likely to be re-used in other cases part," though
[14:49:20 CDT(-0500)] <colinclark> Since everyone thinks they're in that category
[14:49:26 CDT(-0500)] <Bosmon> This is a thing which, although it is tightly integrated, still needs to make extensive use of demands blocks
[14:49:32 CDT(-0500)] <anastasiac> I know that wouldn't cover all cases, but it's a starting point for understanding
[14:49:36 CDT(-0500)] <colinclark> until they find themselves in the position to need to reuse something
[14:50:48 CDT(-0500)] <anastasiac> so Bosmon, when you said before "in our design, we should be actively striving to write defaults that are self-contained", what you mean is we should recommend that people strive for the modular designs, and use demands?
[14:50:56 CDT(-0500)] <Bosmon> I guess the question is - if you write something in a subcomponent's defaults - why would you NOT write than in the defaults for the subcomponent's own creator function itself
[14:51:13 CDT(-0500)] <anastasiac> ah, good question
[14:51:32 CDT(-0500)] <Bosmon> And if there is material that you wouldn't write there - it must be appropriate only in this context
[14:51:39 CDT(-0500)] <Bosmon> And in which case, why wouldn't you write it in demands?
[14:51:58 CDT(-0500)] <Bosmon> I think in many cases we are writing "large subcomponent default trees" only because of the readability advantage
[14:52:47 CDT(-0500)] <anastasiac> so we should be encouraging our users to use demands instead of nesting things in the default trees, right Bosmon?
[14:52:58 CDT(-0500)] <Bosmon> When you see these large trees, I guess it must make one suspicious - are these components really only designed to work smoothly together in this exact integration?
[14:53:34 CDT(-0500)] <Bosmon> anastasiac - I'm not sure we can make a completely clear recommendation on that specific practice
[14:53:51 CDT(-0500)] <Bosmon> We can only give general guidelines on "how to design component sets that are likely to be stable and reusable"
[14:53:57 CDT(-0500)] <anastasiac> right
[14:54:13 CDT(-0500)] <Bosmon> I'm not even sure we understand all the implications yet of one choice rather than another
[14:54:26 CDT(-0500)] <anastasiac> well, that's good to know (wink)
[14:54:26 CDT(-0500)] <Bosmon> But certainly people should plan for demands blocks to be used against their components
[14:54:39 CDT(-0500)] <Bosmon> And make sure that they haven't done anything with their naming that makes this awkward
[14:55:01 CDT(-0500)] <Bosmon> For example, the use of the "cookieSettingStore" in the UIEnhancer was a great example of use of the wrong name
[14:55:10 CDT(-0500)] <Bosmon> Any names which appear inside subcomponent default trees need to be "moral names"
[14:55:23 CDT(-0500)] <Bosmon> That is, names for what FUNCTION this subcomponent represents to its container
[14:55:29 CDT(-0500)] <Bosmon> And not the name of a particular implementation of it
[14:56:01 CDT(-0500)] <Bosmon> This again convinces us a little more towards generally expecting people to use demands blocks rather than "huge defaults" in many cases
[14:56:58 CDT(-0500)] <Bosmon> This is a little like the issue that comes up in "classic OO", of recommending people to use "interface names" rather than "implementation names"
[14:57:07 CDT(-0500)] <Bosmon> We don't really have a separate concept of "interface" and "implementation" any more
[14:57:09 CDT(-0500)] <anastasiac> right
[14:57:26 CDT(-0500)] <Bosmon> But we do have something similar in the concept of "moral function name" and "concrete component name"
[14:57:50 CDT(-0500)] * anastasiac adds "moral" to her list of words we need to find a better word for (smile)
[14:57:57 CDT(-0500)] <Bosmon> It's usually pretty clear by looking at a name which of these two it represents
[14:58:02 CDT(-0500)] <Bosmon> Hah
[14:58:13 CDT(-0500)] <Bosmon> It is the thing which we have sometimes referred to as "demanded name"
[14:58:20 CDT(-0500)] <anastasiac> right
[14:58:23 CDT(-0500)] <Bosmon> That is, the "name of the function that the caller wants"
[14:58:46 CDT(-0500)] <Bosmon> The ground is muddy because the caller may not necessarily have used the proper kind of abstraction in asking for what they wanted
[14:59:04 CDT(-0500)] <Bosmon> They may have done the equivalent of saying, "I need to walk to the post office" rather than saying "I need to send a letter" (tongue)
[14:59:23 CDT(-0500)] <anastasiac> (smile)
[14:59:27 CDT(-0500)] <Bosmon> But "I need to send a letter" is a "moral function" with respect to "I need to walk to the post office" (tongue)
[14:59:37 CDT(-0500)] <anastasiac> exactly
[14:59:42 CDT(-0500)] <Bosmon> I hope that is all clear now (smile)
[15:00:04 CDT(-0500)] <anastasiac> it is much clearer than it was before, which is not to be sneezed at
[15:00:15 CDT(-0500)] <anastasiac> thanks so much, Bosmon
[15:14:00 CDT(-0500)] <Bosmon> I once had a girlfriend who would be perpetually saying the equivalent of "I need to walk to the post office" ....
[15:16:18 CDT(-0500)] <Bosmon> Or still worse.... YOU need to walk to the post office (smile)