FLUID-4637: Using event injection from a parent into multiple instances of the same subcomponent, internal references to the event will always trigger in the last subcomponent

Metadata

Source
FLUID-4637
Type
Bug
Priority
Major
Status
Closed
Resolution
Not A Bug
Assignee
Justin Obara
Reporter
Justin Obara
Created
2012-03-08T15:19:50.159-0500
Updated
2013-02-12T11:56:22.589-0500
Versions
  1. 1.5
Fixed Versions
N/A
Component
  1. IoC System

Description

This occurs when you have a single subcomponent that is spawned in multiple instances in a parent component. When you use event injection to map a parent event with an event in the subcomponent, if the subcomponent is internally listening to that event, it will always trigger only in the last instance of the subcomponent. This is regardless of where the event was initially triggered from.

Attachments

Comments

  • Justin Obara commented 2012-03-08T15:47:52.149-0500

    FLUID-4637.patch contains unit tests to show the issue.

    They can also be found in a branch on my github repo:
    https://github.com/jobara/infusion/tree/FLUID-4637

  • Antranig Basman commented 2013-02-06T01:36:54.017-0500

    Hi Justin - thanks for writing this up and producing the test case. In this case the test is invalid and the framework behaviour is correct. The injection of the parent event "{twinParent}.events.parentEvent" as childEvent causes there to be only ONE EVENT in the system, and since you have namespaced the listener (as "internal"), there is also only room for one listener to it in that namespace. So the resulting sequence is that twin1 instantiates, registers its listener to the event, and then twin2 instantiates, overwriting the "internal" namespaced listener with its own. Then when the event itself is fired (from either source) the one listener which remains will fire, which is the 2nd one registered. You can verify this by removing the namespace applied to the listener - in this case, BOTH events will fire, firstly to twin1's listener and then to twin2's.

    By removing the demands block however we can derive a valid test which I think does test something useful - that the reference to "{twinSubcomponent}" in the listener declaration does indeed resolve by priority onto the selfsame component and not to its "twin" - although the preferred way of writing such self-references in the modern framework is to use "{that}".