continued chat about demands resolution

Justin Obara obara.justin at gmail.com
Wed Aug 15 12:34:08 UTC 2012


Hi Antranig,

Sorry about the late reply. I had been mid way through some other work and needed to finish that up before going back to this. 
The solution was exactly as you outlined. Once I exposed the event through "decapod.pdfExporter" it all started working.

Thanks
Justin

On 2012-08-09, at 11:16 PM, Antranig Basman wrote:

> 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