FLUID-4155: Allow support for "instantiation hints" which can guide relative instantiation order of siblings through IoC

Metadata

Source
FLUID-4155
Type
Improvement
Priority
Major
Status
Closed
Resolution
Fixed
Assignee
Justin Obara
Reporter
Antranig Basman
Created
2011-03-21T03:22:05.295-0400
Updated
2014-03-03T13:12:52.375-0500
Versions
  1. 1.3.1
Fixed Versions
  1. 1.5
Component
  1. IoC System

Description

In most cases, arbitrary order (together with "gingerness" induced by inter-component references) is sufficient for instantiating the order of sibling components. However, in some cases, for example, where the only result of one instantiation is a set of (potentially unknown) context tags whose purpose is to guide the instantiation of the other, this natural order is not sufficient and one component must definitely precede its sibling, even though there is not the possibility of writing a dependence (fictitious or otherwise) that might force this ordering.
In these (sparing) cases it would be useful to attach a "priority" annotation to a subcomponent record which will provide a hint to the system as to relative ordering. These "priority" fields will have the identical values and semantics as "priority" records attached to event listeners (which are similarly sparingly applied, but crucial when they are).

Comments

  • Antranig Basman commented 2013-02-13T18:03:45.125-0500

    Note that we already have implemented a system which detects the "fluid.typeFount" grade name and instantiates any such components by priority

  • Antranig Basman commented 2013-06-03T04:15:39.822-0400

    To a large extent, the requirement for this feature has been removed by FLUID-4330 and FLUID-4916 dynamic grades, and will be considered completely resolved once we have implemented FLUID-4925 and FLUID-5028 - since in that case, subcomponent type computation will necessarily precede all other resolution work (as far as possible) across an entire component tree, ensuring that component construction is done in the light of maximum possible information.
    Since we are not planning to allow component authors to supply manual "hints" in the way suggested in this issue description, this issue can be closed in favour of the others described.