[MDSAL-696] Do not use DerivableSchemaNode Created: 15/Oct/21 Updated: 09/Mar/22 Resolved: 08/Mar/22 |
|
| Status: | Resolved |
| Project: | mdsal |
| Component/s: | Binding codegen, Binding runtime |
| Affects Version/s: | None |
| Fix Version/s: | 9.0.0 |
| Type: | Improvement | Priority: | High |
| Reporter: | Robert Varga | Assignee: | Robert Varga |
| Resolution: | Done | Votes: | 0 |
| Labels: | pt | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||
| Epic Link: | Binding Damage | ||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
DerivableSchemaNode.getOriginal() is used by mdsal-binding-runtime-api and mdsal-binding-generator to resolve original statement backwards along the instantiation axis. Since BindingRuntimeContext is driven by state from GeneratorReactor and that has the capacity to resolve statement -> generator relationships without DerivableSchemaNode (as demonstrated by Analyze the code and its intent and remodel it so that callers of BindingRuntimeContext.originalNodeOf() have everything they need to operate reasonably efficiently (based, again, on their callsites which should be mostly in mdsal-binding-dom-codec). Exactly how GeneratorReactor achieves is not quite clear yet, but it probably be similar to what |
| Comments |
| Comment by Robert Varga [ 05/Dec/21 ] |
|
Analyzing the various accesses to BindingRutimeContext and its underlying BindingRuntimeTypes sheds a bit of light on this. So far it seems that BindingRuntimeTypes really wants to be a tree of RuntimeType instances, each of which provides lookup mechanism by Type and by schema tree (and/or perhaps data tree?) QNames to find child definitions. We already have grouping/augment dependencies available, all we need is to cross-reference them to design the appropriate lookup tables – which is exactly what AbstractExplicitGenerator.getOriginal() is supposed to provide. |