[YANGTOOLS-1259] Split out immutable NormalizedNode implementations Created: 19/Feb/21  Updated: 05/Jan/24  Resolved: 05/Jan/24

Status: Resolved
Project: yangtools
Component/s: data-impl
Affects Version/s: None
Fix Version/s: 12.0.0

Type: Task 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:
Blocks
blocks NETCONF-1215 Mandatory attributes in RPC input are... Confirmed
blocks YANGTOOLS-1242 Split up yang-data-impl Confirmed
blocks YANGTOOLS-1307 Correctly tag missing key violations Confirmed
Relates
relates to YANGTOOLS-980 Expand DataSchemaContextTree capabili... Confirmed
Epic Link: Redesign NormalizedNode

 Description   

Many yang-data-api users are interested only in the immutable NormalizedNode implementation hosted in yang-data-impl. Split it out to yang-data-spi, so it can be used independently of others.

This also entails dealing with Builders and ImmutableNodes classes. The new artifact should only have ImmutableNodes, which provides a superset of methods from Builders and ImmutableNodes.

Furthermore OrderingAware constructs, like MapNode and LeafListNode should have three basic builder factories:

class ImmutableNodes {
    public static CollectionNodeBuilder<MapEntryNode, ? extends MapNode> mapBuilder(Ordering ordering) {
        return switch (ordering) {
            case SYSTEM -> systemMapBuilder();
            case USER -> userMapBuilder();
        };
    }

    public static CollectionNodeBuilder<MapEntryNode, SystemMapNode> systemMapBuilder() {
        return ImmutableMapNodeBuilder.create();
    }

    public static CollectionNodeBuilder<MapEntryNode, UserMapNode> userMapBuilder() {
        return ImmutableUserMapNodeBuilder.create();
    }
}

Access to individual builders is mediated through NormalizedNode.BuilderFactory and the shapes of builders dictated by NormalizedNode.Builder interface hierarchy.


Generated at Wed Feb 07 20:55:38 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.