continued chat about demands resolution

Antranig Basman antranig.basman at colorado.edu
Fri Aug 10 03:16:52 UTC 2012


Thanks for this query, Justin. As I outlined in the channel, this is because of the rules for component 
visibility which were tightened up considerably for the 1.4 release. This is illustrated graphically by the 
increasingly legendary "yellow squares" diagram which shows which components are in scope for IoC resolution 
from a particular location in the tree:

http://wiki.fluidproject.org/display/docs/Demand+Resolution

The rules are that a component is in scope if it is a direct child of a component ancestor. In this case, 
your component "decapod.outputSettings" is not in scope from the resolution site which is at the component 
"decapod.exportControls". The component "decapod.pdfExportOptions" is visible since it is a child of 
"decapod.pdfExporter" which is on the direct ancestor path - but children of "decapod.pdfExportOptions", 
including "decapod.outputSettings" are not themselves visible.

The best solution to this would be promote the event "onValidationError" which appears to be the vital 
material you are resolving to in the demands block so that it is either defined or injected to a higher 
component. From a rough guess, the component "pdfExportOptions" appears to be the best point to refactor 
since it seems odd to have a component with such a high position of responsibility which appears to just be 
housing "options".

Cheers,
Antranig

On 09/08/2012 14:17, Justin Obara wrote:
> Hi Antranig,
>
> Sorry I didn't get a chance to finish up the conversation we started in the Channel yesterday about a
> problem I was having with getting my demands block to resolve.
> http://wiki.fluidproject.org/display/fluid/fluid-work+IRC+Logs-2012-08-08
>
> I've updated the code in my bitbucket repo, so you should be able to see the problem now.
> https://bitbucket.org/jobara/decapod-0.6-ui-iteration5
>
> Specifically it's the demands block on line 67 - 85 of pdfExporterDemands.js that isn't running.
> https://bitbucket.org/jobara/decapod-0.6-ui-iteration5/src/2cae87392f07/components/exporter/js/pdfExporterDemands.js
>
> As shown by these unit tests.
> https://bitbucket.org/jobara/decapod-0.6-ui-iteration5/src/2cae87392f07/tests/exporter/js/pdfExporterTests.js
>
>
> Here's a tree representation of how I expect the components to be resolved. The () indicate the event they
> are created on or that they are created by the renderer. The {} indicate any specified priority.
>
>   * decapod.pdfExporter
>       o decapod.pdfExporter.eventBinder (afterFetchResources)
>       o decapod.dataSource
>       o decapod.exportPoller
>           + decapod.exportPoller.eventBinder {last}
>           + decapod.dataSource {first}
>       o decapod.exportInfo (afterFetchResources)
>       o decapod.pdfExportOptions (afterFetchResources)
>           + decapod.select (afterFetchResources)
>           + decapod.outputSettings (afterFetchResources)
>       o decapod.exportControls (onExportOptionsReady)
>           + decapod.exportControls.trigger (renderer)
>           + decapod.exportControls.progress (renderer)
>           + decapod.exportControls.complete (renderer)
>
>
> I also copied the IoC log from the unit test running. I've attached it to the e-mail as log.text.
> In both the expected tree above, and in the log, it appears that the context have all initialized.
> Any suggestions on what could be going wrong would be greatly appreciated.
>
> Thanks for your help
> Justin
>



More information about the fluid-work mailing list