FLUID-4302: Framework usability issue: situation with ambiguously named component and DOM binder was hard to diagnose

Metadata

Source
FLUID-4302
Type
Improvement
Priority
Blocker
Status
Closed
Resolution
Cannot Reproduce
Assignee
N/A
Reporter
Antranig Basman
Created
2011-06-23T17:51:37.321-0400
Updated
2019-11-22T07:30:22.793-0500
Versions
  1. 1.4
  2. 1.5
Fixed Versions
  1. 1.9
Component
  1. IoC System

Description

The following revision of ErrorsView.js (now outdated) shows a construct that was led to confusion:

https://github.com/jhung/infusion/blob/9e8ae1fb32dac30a0c0170676a3cc343fca994b5/src/webapp/components/uploader/js/ErrorsView.js

fluid.demands("fluid.uploader.errorsView", "fluid.uploader.multiFileUploader", {
        container: "{multiFileUploader}.options.selectors.errorsPanel", // TODO: Why can't I bind to {multiFileUploader}.dom.errors?
        options: {            
            listeners: {
                "{multiFileUploader}.events.afterFileDialog": "{errorsView}.refreshView"
            }
        }
    });

Due to ambiguous resolution of "errorsView" this quietly caused a binding of the listener onto the wrong target. [This doesn't match what I remember of the original problem but is the only possible problem I can see right now - Colin, can you add details?]

Comments

  • Antranig Basman commented 2015-06-09T20:05:10.656-0400

    There's been no further feedback on this issue and this area of the framework has changed so much in 4 years that we are unlikely to reproduce it in the same form. Especially, attempting to bind a "container" onto a "selector" is a terrible hack that should never be necessary/effective.

  • Justin Obara commented 2015-06-26T09:51:07.265-0400

    Reopening to change the fix version to 1.9