fluid-work IRC Logs-2013-04-15
[08:09:11 CDT(-0500)] <heidiv> morning jung1 - can i help with 4970?
[08:21:46 CDT(-0500)] <jhung1> cindyli: is your FLUID-4927 branch the latest you and justin_o have been working on?
[08:25:04 CDT(-0500)] <heidiv> jhung1 still the scrolling bug in winxp/chrome - it gets cut off
[08:26:09 CDT(-0500)] <jhung> heidiv: ok. I'll take a look in a sec.
[08:28:34 CDT(-0500)] <heidiv> jhung safari too fyi, winxp
[08:28:35 CDT(-0500)] <jhung> so odd! My panel doesn't work in IE on Win 7. :/
[08:28:47 CDT(-0500)] <heidiv> jhung i'll check ie9 now
[08:43:06 CDT(-0500)] <heidiv> IE9 works for me jhung
[08:44:28 CDT(-0500)] <jhung>
[08:44:36 CDT(-0500)] <jhung> You're WinXP, right?
[08:44:38 CDT(-0500)] <heidiv> jhung that's a good thing!
[08:44:44 CDT(-0500)] <heidiv> jhung win7, ie9
[08:44:57 CDT(-0500)] <heidiv> the panel doesn't open for you?
[08:45:01 CDT(-0500)] <jhung> Nope!
[08:45:07 CDT(-0500)] <heidiv> jhung cache? ahem
[08:45:13 CDT(-0500)] <jhung> maybe
[08:47:56 CDT(-0500)] <cindyli> jhung: the latest one should be FLUID-4927-b. He pushed more changes last Friday. I will merge in his branch into my FLUID-4927 in a minute.
[08:51:10 CDT(-0500)] <cindyli> jhung: I've merged in justin's FLUID-4927-b into my FLUID-4927. you can use either of those.
[08:55:40 CDT(-0500)] <jhung> thanks cindyli!
[08:55:47 CDT(-0500)] <cindyli> np
[08:56:17 CDT(-0500)] <jhung> cindyli: there's a stray comma at the end of line 140 in FatPanelUIOptions.js.
[08:56:40 CDT(-0500)] <cindyli> thanks, jhung, will fix that and push up
[09:00:36 CDT(-0500)] <cindyli> jhung: that seems having been fixed in justin's commit. I corrected another jslinting error in FatPanelUIOptions.js and pushed up. pls update your branch when you have a chance.
[09:06:14 CDT(-0500)] <heidiv> jhung so the only thing left seems to be the issue i'm having w scrolling cutting off on winxp/chrome and win7/chrome, but fine for you. hmm
[09:06:59 CDT(-0500)] <jhung> yeah heidiv. Maybe someone at the office can test it out? cindyli would you have a sec to try for us?
[09:07:37 CDT(-0500)] <cindyli> sure, jhung and heidiv, which branch should i try?
[09:08:04 CDT(-0500)] <heidiv> jhung the issue is overflow: auto on the html tag. once i remove that it works, it's in fss-base-global.css
[09:08:05 CDT(-0500)] <jhung> My FLUID-4970 or heidi's 4970 branch.
[09:08:45 CDT(-0500)] <jhung> heidiv: hmmm doesn't explain why it works for me though heidiv. Also shouldn't our styles override it?
[09:09:32 CDT(-0500)] <heidiv> jhung i suppose we don't specifically override this style, but should? see what happens for cindyli. jhung is it present for you in chrome/win7 when you inspect?
[09:09:46 CDT(-0500)] <jhung> let me see.
[09:10:56 CDT(-0500)] <jhung> which element heidiv? the BODY tag in the iframe?
[09:11:18 CDT(-0500)] <heidiv> jhung html of iframe
[09:12:53 CDT(-0500)] <heidiv> jhung i'm just confused why our win7/chrome's are behaving differently for this style...
[09:13:05 CDT(-0500)] <jhung> heidiv: yep there for me. But has no effect when disabled or enabled.
[09:13:13 CDT(-0500)] <jhung> Chrome Win7
[09:14:49 CDT(-0500)] <cindyli> jhung and heidiv, i have the same scrolling cutting off issue with chrome on win xp and 7
[09:15:09 CDT(-0500)] <heidiv> cindyli thanks!
[09:15:12 CDT(-0500)] <cindyli> np
[09:15:32 CDT(-0500)] <heidiv> jhung your browser mode is correct, too?
[09:15:34 CDT(-0500)] <jhung> cindyli: are you using VMWare or Virtualbox?
[09:15:43 CDT(-0500)] <cindyli> VMWare
[09:15:51 CDT(-0500)] <heidiv> and i'm virtualbox
[09:15:58 CDT(-0500)] <jhung> Chrome doesn't have a browser mode heidiv?
[09:16:12 CDT(-0500)] <heidiv> jhung right⦠ha
[09:16:17 CDT(-0500)] <jhung> lol
[09:16:43 CDT(-0500)] <heidiv> jhung i suppose i will add the over-ride then, but i wish you could replicate too!
[09:16:54 CDT(-0500)] <jhung> yeah.
[09:17:06 CDT(-0500)] <jhung> Over-ride sounds like the safe thing to do.
[09:17:59 CDT(-0500)] <heidiv> jhung have you tried removing the hardcoded overflows in the js?
[09:18:45 CDT(-0500)] <jhung> yes it doesn't seem to do anything heidiv.
[09:18:48 CDT(-0500)] <heidiv> jhung fyi the overflow over-ride fixes the mac/chrome weirdness as well
[09:18:53 CDT(-0500)] <jhung> cool
[09:19:05 CDT(-0500)] <jhung> heidiv: going to check my FF with that over-flow removed.
[09:19:58 CDT(-0500)] <jhung> seems good to me on FF Win7 heidiv
[09:20:25 CDT(-0500)] <heidiv> jhung but it didn't fix the IE bars hey?
[09:22:08 CDT(-0500)] <jhung> nope. those bars are still there heidiv
[09:24:24 CDT(-0500)] <jhung> oh wait...
[09:24:51 CDT(-0500)] <jhung> heidiv: they're not there. I had my browser zoom enabled. Are vertical scroll bars visible to you in IE?
[09:25:09 CDT(-0500)] <heidiv> jhung did you push the change?
[09:26:21 CDT(-0500)] <jhung> heidiv: which? the override or the removal of the overflow in FatPanelUiOptions.js?
[09:27:11 CDT(-0500)] <heidiv> jhung let's skype
[09:27:26 CDT(-0500)] <jhung> k
[09:31:57 CDT(-0500)] <heidiv> arashs we're almost done w our styling branch, do you need help w font icon research/testing?
[09:34:36 CDT(-0500)] <arashs> heidiv: I think we have covered all of the testing and research we wanted to do on the wiki
[09:35:02 CDT(-0500)] <heidiv> arashs k
[09:36:51 CDT(-0500)] <arashs> no problem heidiv , please let me know if you need my help, or want me to research/test something we have missed
[10:10:52 CDT(-0500)] <jhung> cindyli: when Table of Contents is enabled, a large gap appears above the UIO panel. There have been 2 jiras somewhat related to this - is this the same issue or is it new?
[10:11:25 CDT(-0500)] <jhung> happens only in FF.
[10:11:40 CDT(-0500)] <cindyli> jhung: do you have those 2 jiras at hand?
[10:11:41 CDT(-0500)] <jhung> To reproduce: pull changes from heidiv's FLUID-4970 branch.
[10:11:57 CDT(-0500)] <jhung> Load the demo in FF. Enable ToC. Hide and how panel again.
[10:12:11 CDT(-0500)] <jhung> Not right now cindyli. I can dig those up.
[10:12:23 CDT(-0500)] <jhung> Fine in Chrome though.
[10:12:49 CDT(-0500)] <cindyli> nvm, jhung, i can dig those up
[10:13:39 CDT(-0500)] <jhung> thanks cindyli
[10:13:48 CDT(-0500)] <jhung> heidiv: I wonder if it's something we did that causes this?
[10:14:24 CDT(-0500)] <heidiv> jhung looks like it's only for default theme? yes i imagine it's related to our css
[10:14:39 CDT(-0500)] <heidiv> n/m other themes too. let's fix it
[10:15:11 CDT(-0500)] <heidiv> if it's css⦠jhung i'll look at it
[10:15:18 CDT(-0500)] <jhung> k heidiv.
[10:20:06 CDT(-0500)] <heidiv> it looks like a "display:block" is being added to the toc div, inline⦠i'm guessing the js
[10:21:40 CDT(-0500)] <heidiv> cindlyi ^
[10:22:02 CDT(-0500)] <heidiv> maybe there was a check before to see if it was in the fatpanel iframe?
[10:24:11 CDT(-0500)] <michelled> jhung, heidiv, arashs: I'm thinking we should push off the font icon conversation until tomorrow when the KING is back
[10:24:14 CDT(-0500)] <michelled> what do you think?
[10:24:31 CDT(-0500)] <heidiv> michelled agreed. king!
[10:24:40 CDT(-0500)] <jhung> michelled: sounds fine to me.
[10:26:19 CDT(-0500)] <arashs> michelled: I will be away tomorrow, maybe I could catch up with you today?
[10:27:24 CDT(-0500)] <cindyli> jhung: the gap above the UIO panel in the fat panel seems a new issue. I will fix it in 4927 branch
[10:27:50 CDT(-0500)] <jhung> cindyli: okay. Was it related to styling or with JS?
[10:28:44 CDT(-0500)] <heidiv> js i think⦠i will leave it be
[10:29:51 CDT(-0500)] <cindyli> no, jhung
[10:43:15 CDT(-0500)] <jhung> michelled, arashs, heidiv: I'm going to have to step out until 1p. Regarding font icons, I think we should wait until King is around since he did most of the testing with 2 major implementations last Friday.
[12:13:08 CDT(-0500)] <heidiv> cindyli could you let me know when to the toc has been pushed to the -b branch?
[12:13:28 CDT(-0500)] <heidiv> that didn't make sense. when the fix for the toc issue
[12:13:52 CDT(-0500)] <cindyli> heidiv: it has been pushed to my FLUID-4927 branch. -b branch is justin's that i cannot push on to.
[12:14:09 CDT(-0500)] <heidiv> cindyli ah, ok. but your 4927 is the same
[12:14:10 CDT(-0500)] <cindyli> https://github.com/cindyli/infusion/tree/FLUID-4927
[12:14:16 CDT(-0500)] <heidiv> great, thank you!
[12:14:33 CDT(-0500)] <cindyli> np
[13:05:42 CDT(-0500)] <Ra__> Hello jhung! how have you been?..
[13:10:39 CDT(-0500)] <jhung> hey Ra__ not bad how are you?
[13:13:08 CDT(-0500)] <jhung> cindyli: did you put in a fix for the table of contents gap issue?
[13:13:19 CDT(-0500)] <Ra__> I'm fine.. I have got some new thoughts about the idea which I would like to tell you..
[13:13:43 CDT(-0500)] <cindyli> yes, jhung, pushed up this morning - https://github.com/cindyli/infusion/tree/FLUID-4927
[13:14:04 CDT(-0500)] <jhung> cindyli: doesn't seem to fix issue in Safari. Going to clear cache and try again. Stay tuned...
[13:14:21 CDT(-0500)] <jhung> Ra__: cool. What have you come up with?
[13:15:30 CDT(-0500)] <cindyli> let me know, jhung, my safari works fine though
[13:15:30 CDT(-0500)] <Ra__> I think that it would be a great concept if we could somehow present a complete video like a comic strip... i,e. stills embeded with the transcript...
[13:16:34 CDT(-0500)] <jhung> Ra__: That would be awesome!
[13:16:43 CDT(-0500)] <jhung> Ra__: What a fun idea.
[13:17:31 CDT(-0500)] <Ra__> The major hindrance in the idea is how!
[13:18:53 CDT(-0500)] <jhung> Indeed.
[13:20:08 CDT(-0500)] <jhung> If you have sketches to share with Justin_o and I, feel free to send them our way.
[13:20:12 CDT(-0500)] <jhung> ^Ra__
[13:22:03 CDT(-0500)] <jhung> cindyli, false alarm. Everything seems okay.
[13:22:11 CDT(-0500)] <cindyli> cool
[13:22:24 CDT(-0500)] <Ra__> jhung: No actually I havent got time to prepare any sketches since I have my exams going on.. I will try to develop some as soon as possible. I hope you understand.
[13:24:09 CDT(-0500)] <jhung> Of course Ra__. Not a problem.
[13:24:24 CDT(-0500)] <jhung> I forgot you had exams coming up.
[13:31:26 CDT(-0500)] <Ra__> jhung another thing I was thinking of was if we could maintain time tagged comments or tags or some sort of a heat-map.. it would be easier to find out the important parts of the video quickly and easily...
[13:32:54 CDT(-0500)] <Ra__> the only thing which is troubling me is that.. what would be the incentive of the people to contribute to this... it can be possible to implement in the educational videos though..
[13:33:40 CDT(-0500)] <jhung> In a classroom setting, classmates may do it to help each other out. So there's incentive there.
[13:34:33 CDT(-0500)] <jhung> However, I wonder if a heat map may detract from other possible relevant information? The heat map will only indicate what is popular, but may not necessarily be the most important.
[13:35:37 CDT(-0500)] <Ra__> Yes! thats what I feel.. it is possible to implement this in the educational videos...
[13:35:57 CDT(-0500)] <Ra__> I get you... it can be a problem..
[13:37:00 CDT(-0500)] <jhung> But it could still be a useful tool as long as users are aware that it isn't meant to replace watching / reading all the content.
[13:37:28 CDT(-0500)] <Ra__> Use at your own risk!..
[13:37:43 CDT(-0500)] <jhung> haha. Yes.
[13:38:14 CDT(-0500)] <jhung> But it's an interesting idea that may be worth puzzling over even if it won't be implemented.
[13:38:18 CDT(-0500)] <system64> Hey jhung! Any idea if colinclark will be joining us today?
[13:38:28 CDT(-0500)] <jhung> I do like the social aspect of the concept though Ra__.
[13:38:45 CDT(-0500)] <jhung> system64: Colinclark is on "semi-vacation"
[13:38:54 CDT(-0500)] <jhung> So he may not be joining.
[13:39:52 CDT(-0500)] <system64> jhung: Thanks, when will he be back?
[13:40:11 CDT(-0500)] <jhung> system64: according to the calendar, April 29.
[13:40:30 CDT(-0500)] <jhung> So maybe send him an email and he may pick it up system64.
[13:40:55 CDT(-0500)] <system64> jhung: I sent it on Saturday.
[13:41:29 CDT(-0500)] <system64> jhung: Who would be the right person to discuss WebRTC collaboration project?
[13:42:44 CDT(-0500)] <jhung> system64: that may very well be one of his projects. greggy1 do you know who else may be metoring the WebRTC project?
[13:43:54 CDT(-0500)] <system64> jhung: I had few discussions with him before, would have been great to have his feedback. Hope he replies to mail
[13:43:55 CDT(-0500)] <Ra__> jhung: I recently saw some widgets implementing emotional graphs for song videos.. they rely on the viewers inputs to display what emotion the song portrays..
[13:46:56 CDT(-0500)] <Ra__> What I am saying is a similar concept.. the viewer can time-tag the video with "Important", "Fun Fact", etc. etc. more relevant to the educational videos..
[13:47:24 CDT(-0500)] <jhung> system64: okay.
[13:48:57 CDT(-0500)] <jhung> Ra__: That's really interesting because I was thinking of a similar idea for a different project. The ability for learners / users to tag content based on emotions. Then other learners can seek it out.
[13:52:29 CDT(-0500)] <Ra__> yes it can actually be very useful but a lot of its utility depends on the viewers, you should hope you are not trolled!
[13:53:12 CDT(-0500)] <jhung> lol
[13:53:24 CDT(-0500)] <jhung> Hopefully there will be some moderation
[13:53:59 CDT(-0500)] <heidiv> have you guys seen the website where ppl can annotate lyrics to rap songs?
[13:54:05 CDT(-0500)] <heidiv> it's pretty amazing.
[13:54:29 CDT(-0500)] <Ra___> jhung: yes it can actually be very useful but a lot of its utility depends on the viewers, you should hope you are not trolled!
[13:55:21 CDT(-0500)] <jhung> Ra__: I think we'd need some moderation in that case.
[13:55:53 CDT(-0500)] <jhung> I think that goes without saying in a classroom setting (or at least I hope that's the case!).
[13:57:47 CDT(-0500)] <Ra___> yes I think you are right!
[14:03:48 CDT(-0500)] <jhung> cindyli: it seems that when you tab focus the contrast panel, the view does not scroll to focus.
[14:04:48 CDT(-0500)] <cindyli> jhung: as i rmb, that's a known issue, anastasiac issued a jira for that. let me dig up
[14:05:13 CDT(-0500)] <heidiv> jhung might be something we fix once the carousel feature is happening
[14:05:53 CDT(-0500)] <cindyli> jhung: is it same as what described here - http://issues.fluidproject.org/browse/FLUID-4963
[14:07:03 CDT(-0500)] <jhung> cindyli: okay. But now that we're out of demo and onto master, do you think we should address this now?
[14:07:36 CDT(-0500)] <cindyli> it should be addressed, jhung, but worth a separate jira
[14:08:14 CDT(-0500)] <heidiv> is scrollIntoView() being used now?
[14:09:49 CDT(-0500)] <heidiv> no, it's not
[14:10:06 CDT(-0500)] <cindyli> heidiv: scrollIntoView() is not used now. if you look at the comment that anastasiac made in that jira, that function creates inconsistent behavior across browsers
[14:10:32 CDT(-0500)] <heidiv> jhung was this the issue you were thinking might be related to our scrolling prob?
[14:11:33 CDT(-0500)] <heidiv> thanks cindyli β¦ we're trying to figure out why selecting a theme causes the scrollbar to jump to the beginning. very strange.
[14:11:45 CDT(-0500)] <cindyli> ah. ok
[14:13:02 CDT(-0500)] <jhung> heidiv: I'm not sure. I'll try disabling our overflow styles and see what happens.
[14:19:18 CDT(-0500)] <anastasiac> Bosmon, I'm wondering if you can explain what the renderer 'amalgateClasses' option is for, and when you need to use it and when you don't. I'm not quite clear on the concept
[14:20:24 CDT(-0500)] <Bosmon> Hi anastasiac - I don't see that in the renderer, but in "fetchResource"
[14:20:28 CDT(-0500)] <Bosmon> fetchResources
[14:20:34 CDT(-0500)] <anastasiac> right, sorry
[14:22:50 CDT(-0500)] <Bosmon> anastasiac - the intended behaviour appears to be to delay the completion of the current fetchResources operation until all of the specified "resource classes" have been fetched
[14:24:00 CDT(-0500)] <anastasiac> could you clarify that a bit, Bosmon? maybe "completion of" is what I'm not getting, I'm not sure. It sounds like you're saying it delays fetching resources until the resources have been fetched - and I'm pretty sure that's not what you're saying
[14:24:20 CDT(-0500)] <Bosmon> Well, each resource has attached an optional "resource class"
[14:24:34 CDT(-0500)] <anastasiac> is that a requirement?
[14:24:39 CDT(-0500)] <anastasiac> sorry
[14:24:44 CDT(-0500)] <anastasiac> "optional"
[14:24:47 CDT(-0500)] <Bosmon> Named as the property "fetchClass"
[14:24:52 CDT(-0500)] <anastasiac> right
[14:25:05 CDT(-0500)] <Bosmon> If it is supplied for a resource, it will be identified with that "class" of resource fetching
[14:25:11 CDT(-0500)] <Bosmon> For example I think we had 3 such classes in CSpace
[14:25:18 CDT(-0500)] <anastasiac> and if it's not supplied?
[14:25:41 CDT(-0500)] <Bosmon> Then the resource is just handled individually and not seen as part of a class
[14:26:12 CDT(-0500)] <Bosmon> The use of "amalgamateClasses" allows you to mention extra classes that you want to wait for, even if the current fetchResources record does not mention any resources of that class
[14:26:12 CDT(-0500)] <anastasiac> so you'd only use the classes if you, for some reason, wanted to load different 'classes' of resources at different times?
[14:26:40 CDT(-0500)] <Bosmon> Naturally as an INDIVIDUAL action, each call to fetchResources will only complete when the last resource mentioned in it completes
[14:27:04 CDT(-0500)] <Bosmon> But you may happen to know that you have a dependency on resources requested elsewhere - typically, in our case, through our somewhat bone-headed "primeCacheForResources" calls
[14:27:12 CDT(-0500)] <anastasiac> so amalgamateClasses would be useful if you don't need to wait for everything
[14:27:34 CDT(-0500)] <Bosmon> No, the opposite
[14:27:42 CDT(-0500)] <Bosmon> amalgamateClasses can only slow down the request completion
[14:28:10 CDT(-0500)] <anastasiac> but if "each call to fetchResources will only complete when the last resource mentioned in it completes", why would you need to slow it down?
[14:28:24 CDT(-0500)] <Bosmon> Because you may need to wait for additional resources requested elsewhere
[14:28:49 CDT(-0500)] <Bosmon> It is a pretty terrible system, and I'm not sure we want to advertise it too widely
[14:28:56 CDT(-0500)] <Bosmon> You may as well mark all this stuff as "deprecated"
[14:28:59 CDT(-0500)] <anastasiac> so in a simple case where a component is only dependent on its own template, no need for classes, no need for priming - is that right?
[14:29:11 CDT(-0500)] <Bosmon> That's right
[14:29:12 CDT(-0500)] <anastasiac> and is it deprecated now? what's the currently-recommended way of doing things?
[14:29:21 CDT(-0500)] <Bosmon> Sadly we have no replacement as yet
[14:29:33 CDT(-0500)] <Bosmon> I was just about to write the JIRA for the "globally asynchronous ginger world"
[14:29:38 CDT(-0500)] <anastasiac> so we can't deprecate it yet, if it's the only way we have
[14:29:56 CDT(-0500)] <Bosmon> I'm sure we could do SOMETHING to it
[14:30:00 CDT(-0500)] <Bosmon> What if we had never invented it? : P
[14:31:01 CDT(-0500)] <anastasiac> also, I wanted to double-check: we pretty much still need to call fetchResources directly, since the initRendererComponent doesn't really handle asynchrony, right? if we leave it up to the framework, we can't be sure the template is ready when we need it - is that still right, or has that been addressed by any of the recent changes?
[14:31:14 CDT(-0500)] <Bosmon> anastasiac - that remains unchanged, yes
[14:31:32 CDT(-0500)] <Bosmon> The general architecture in CSpace was to have a top-level component which blocked on ALL outstanding I/O for templates
[14:31:39 CDT(-0500)] <Bosmon> Which is what the use of "amalgamateClasses" was for
[14:31:56 CDT(-0500)] <Bosmon> It is a terribly inefficient and also incapable system
[14:32:23 CDT(-0500)] <anastasiac> but for a simple, relatively independent component, I should just call fetchResources - say, in preInit?
[14:33:32 CDT(-0500)] <Bosmon> anastasiac - you still would have the timing issue you mentioned
[14:33:41 CDT(-0500)] <Bosmon> The first-level answer is "yes, you would call fetchResources"
[14:33:53 CDT(-0500)] <anastasiac> but I'd need the callback
[14:34:00 CDT(-0500)] <Bosmon> but THEN you have the problem of ensuring that the component is not instantiated until the I/O has ALREADY completed
[14:34:09 CDT(-0500)] <Bosmon> Which essentially means you need to somehow issue the I/O twice
[14:34:25 CDT(-0500)] <Bosmon> This is one of the many painful things wrong with the current system
[14:34:47 CDT(-0500)] <Bosmon> SOMETHING in the system needs to have already issued the I/O and got it into the cache, in the proper, asynchronous way
[14:34:50 CDT(-0500)] <anastasiac> so what's the recommended pattern, currently? and please tell me we plan to improve this in the next round of framework updates
[14:35:04 CDT(-0500)] <Bosmon> AFTER that, that thing then permits the component which actually wants the template to then construct
[14:35:24 CDT(-0500)] <Bosmon> It then makes a call to fetchResources() which we expect will then conclude synchronously, as a result of fetching it from the cache
[14:35:37 CDT(-0500)] <Bosmon> This is the CSpace style of doing these things
[14:35:45 CDT(-0500)] <anastasiac> what about the fetchResources callback - doesn't that wait till after the resource is fetched?
[14:36:04 CDT(-0500)] <Bosmon> The alternative is the UIOptions way of doing things, which is to have a dedicated top-level component which holds all templates, as well as having the responsibility for blocking subcomponents
[14:36:28 CDT(-0500)] <Bosmon> Then the subcomponents once they instantiate simply resolve the parent's instance of the resources directly
[14:36:37 CDT(-0500)] <Bosmon> Rather than issuing a fresh fetchResources call
[14:37:05 CDT(-0500)] <Bosmon> We plan to improve this in the next round of updates by allowing component instantiation to be truly asynchronous
[14:37:10 CDT(-0500)] <Bosmon> At present it can't be
[14:37:26 CDT(-0500)] <Bosmon> There is no scope in the current framework for a component whose instantiation STARTS and then doesn't synchronously conclude
[14:38:03 CDT(-0500)] <anastasiac> what about the fetchResources callback, Bosmon - doesn't that wait till after the resource is fetched?
[14:38:24 CDT(-0500)] <Bosmon> anastasiac - it does, yes - which is why a "genuine" fetchResources call can never be part of the workflow of an instantiating component
[14:38:51 CDT(-0500)] <Bosmon> However, if the resource has ALREADY been fetched by a previous call into the cache, a subsequent call for the same resource will complete synchronously
[14:38:59 CDT(-0500)] <Bosmon> And so therefore is OK to use in a component initialisation
[14:39:05 CDT(-0500)] <Bosmon> This is the way it is done in CSpace
[14:39:37 CDT(-0500)] <anastasiac> so the CSpace way is: 1) call primeCacheFromResouces() outside the component init, then 2) call fetchResourcs() as part of component init - is that accurate?
[14:40:53 CDT(-0500)] <Bosmon> anastasiac - that's right
[14:41:07 CDT(-0500)] <anastasiac> okley
[14:41:15 CDT(-0500)] <Bosmon> Or 1) could be achieved by a direct call to fetchResources with the correct options
[14:41:44 CDT(-0500)] <Bosmon> You'll see that the implementation of primeCacheFromResources() does almost nothing but forward to fetchResources
[14:42:05 CDT(-0500)] <anastasiac> ah, ok, right
[14:42:43 CDT(-0500)] <anastasiac> well, I'm certainly looking forward to the improvements. This is quite a bit of hoop-jumping
[14:44:05 CDT(-0500)] <Bosmon> It's not only hoop-jumping, but in many cases it simply doesn't work - since there is no way to get the choice of template to be responsive to an IoC context
[14:44:52 CDT(-0500)] <anastasiac> Bosmon, does the forceCache property do anything useful here?
[14:45:08 CDT(-0500)] <Bosmon> anastasiac - the forceCache property is what causes the cache to be used at all
[14:45:25 CDT(-0500)] <Bosmon> Without this property, the 2nd call to fetchResources will not see any benefit of the 1st call
[14:45:28 CDT(-0500)] <anastasiac> so if I don't set it, even calling primeCacheFromResources has no effect?
[14:45:44 CDT(-0500)] <Bosmon> anastasiac - that's right
[14:46:05 CDT(-0500)] <Bosmon> There's even a nice TODO on it : P
[14:46:12 CDT(-0500)] <anastasiac>