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 >> > _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
