[09:34:42 CST(-0600)] <cindyli> michelled, anastasiac, i'm going to start writing unit tests for FLUID-4545. Is it ok that I use anastasiac's work to add the initial unit test, acheetham:FLUID-4572-template-path-for-tests, as a base even though anastasiac is probably still working on it.

[09:35:44 CST(-0600)] <anastasiac> cindyli, I'm just finishing up some changes to that branch in response to michelled's comments, and I need to talk to michelled about some of them, but they're not major - I don't see why you couldn't start with what's there

[09:36:06 CST(-0600)] <cindyli> cool. thanks, anastasiac

[09:45:49 CST(-0600)] <anastasiac> Bosmon, I'm writing tests for the VideoPlayer and I found myself needing to override the path to the template (since the relative path from the tests folder was different). It seemed to me that it would be good to have a way to override the path without needing to know the template name(s)

[09:45:56 CST(-0600)] <anastasiac> i.e. just override the path part

[09:46:15 CST(-0600)] <Bosmon4> anastasiac - that sounds reasonable

[09:46:27 CST(-0600)] <Bosmon4> Do you feel inclined to follow a similar strategy to the one we did in UIOptions?

[09:46:59 CST(-0600)] <anastasiac> the strategy in UIOptions seems rather complicated - it wraps the path in a subcomponent.

[09:47:15 CST(-0600)] <Bosmon4> Yes, we have some framework limitations at the moment

[09:47:45 CST(-0600)] <anastasiac> would it make sense to create a utility function somewhere that would simply combine a path with a set of filenames to create a resourceSpec?

[09:48:02 CST(-0600)] <anastasiac> "fluid.fetchResources.buildResourceSpec" ?

[09:48:05 CST(-0600)] <anastasiac> for use in simple cases?

[09:50:16 CST(-0600)] <Bosmon4> I think the longer-term issue was that the plan was to move the IO for UIOptions into a component higher up the tree

[09:50:54 CST(-0600)] <Bosmon4> It is easy to make the utility function, but the problem is to ensure that the user's configuration for the path segment can be seen early enough to do the I/O for the component

[09:51:02 CST(-0600)] <Bosmon4> This was the reason for the complex strategy in UIOptions

[09:51:04 CST(-0600)] <anastasiac> right

[09:51:39 CST(-0600)] <Bosmon4> I had a brief look at your JIRA from last week - I don't have too much time right now, but the short answer is that every component should define a grade

[09:51:51 CST(-0600)] <Bosmon4> In a version of the framework to come soon, it will be mandatory...

[09:52:05 CST(-0600)] <anastasiac> ok, I suspected that was the correct approach

[09:52:08 CST(-0600)] <anastasiac> to dealing with it

[09:52:34 CST(-0600)] <Bosmon4> We only really continue to support components without grades so that we don't have to rewrite our entire codebase overnight....

[09:52:47 CST(-0600)] <Bosmon4> But every component written in new code should have a proper grade in its defaults

[09:53:14 CST(-0600)] <anastasiac> so w.r.t. customized template paths, we don't really have an easy way for an integrator to do that right now, is that right?

[09:53:32 CST(-0600)] <Bosmon4> There's no very clear way, no

[09:54:12 CST(-0600)] <anastasiac> ok, thanks. Do you know if there's a JIRA already about this, or should I create one?

[09:54:14 CST(-0600)] <Bosmon4> The code in UIOptions represents our best attempt so far

[09:54:35 CST(-0600)] <anastasiac> ok, I'll model the VideoPlayer's solution on UIOptions in the meantime

[09:54:51 CST(-0600)] <Bosmon4> It's hard to do too much better until we achieve the two main framework milestones we are aiming for

[09:55:07 CST(-0600)] <Bosmon4> i) ginger world for options resolution, ii) 2-phase renderer components

Browser not supported