Uploaded image for project: 'Fluid Infusion'
  1. Fluid Infusion
  2. FLUID-5028

Allow set of subcomponents of a component to be responsive to "changes" which occur after subcomponent instantiation begins

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 1.4, 1.5
    • Fix Version/s: None
    • Component/s: IoC System
    • Labels:
      None

      Description

      One remaining limitation in the IoC instantiation system is that the start point of instantiating subcomponents is still a definite timing point. In particular, the following workflow is currently impossible -
      i) begin instantiation of parent component
      ii) begin instantiation of subcomponent
      iii) subcomponent contributes a dynamic grade back to its parent designating further subcomponents
      iv) after subcomponent is constructed, instantiation may later continue with the dynamically designated siblings from step iii)

      Instead, the set of subcomponents of a component is currently fixed for all time (that is, for the current "ginger fit") at the point it begins. Dynamic grades which have not been seen by this point will not affect the subcomponent set.

      Lifting this restriction is important to various kinds of configuration flexibility. For example, in the current implementation of the Uploader we still have a "2-component solution" since we can't get the "real uploader" to be sensitive to the context resolution done by its own ProgressiveEnhancer. When shown the current dynamic grades system, Justin_O remarked, "why can't the Uploader be its own ProgressiveEnhancer", and the problem described in this JIRA is one of the two chief reasons. If the Uploader COULD designate its own ProgressiveEnhancer, the process of its adaptation could be folded into its own instantiation process rather than requiring a 2nd component. With the use of nickNames and distributeOptions, it's possible to paper over this problem almost completely from the point of view of external users, but it remains an implementation complexity and annoyance for implementors and other code readers.

      When FLUID-4925 is implemented, it will also need to be made sensitive to this possibility. This problem is also alluded to as part of the long discussion in FLUID-4930 - we need a facility to mark a path as "dirty" or "clean", or at the least have a clear and cheap workflow for only "restarting" on the subcomponent collection when we can detect that the "gradeNames" collection has changed. This facility does appear to violate our "referential transparency" religion in that in theory there is a value ("gradeNames") which does not appear to remain fixed over time - but if we consider that "gradeNames" is morally equivalent to a hash of gradeName to "true" (which in fact we should reimplement it in terms of for efficiency reasons, as long as we can avoid mergePolicy annoyances) and is only observed through the use of "hasGradeName" we could consider that the religion is preserved - from this point of view, "gradeNames" is still only also a structure which evolves additively ("monotonically") as it should - at earlier points in time it could be considered to just be "partially evaluated" (hence the connection with FLUID-4930).

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                antranig Antranig Basman
                Reporter:
                antranig Antranig Basman
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated: