Migrating from column types

This page is for table views written against Syside versions before 0.11. If your views already use columnFeature and featureRepresentation, nothing here applies; the sections below map each retired column type onto its modern equivalent and show how a hierarchical table declares its now-explicit tree column.

Syside before version 0.11 configured columns with a single featureToRender attribute set to a ColumnType (CT) enum member, parameterised through nested attributes. That API is retired: the ColumnType enum no longer exists in the SysideViews library, and views written against it produce name-resolution errors after the library update. Each old column type maps onto a chain / representation pair. The simple column types, those without nested attributes, map directly:

<0.11 featureToRender	>=0.11 column definitions
declaredName	attribute :>> featureRepresentation :> ColRep::declaredName;
declaredShortName	attribute :>> featureRepresentation :> ColRep::declaredShortName;
name	attribute :>> featureRepresentation :> ColRep::name;
shortName	attribute :>> featureRepresentation :> ColRep::shortName;
qualifiedName	attribute :>> featureRepresentation :> ColRep::qualifiedName;
documentation	attribute :>> featureRepresentation :> ColRep::documentation;
reqId	// the requirement ID is the declared short name attribute :>> featureRepresentation :> ColRep::declaredShortName;
owner	:>> columnFeature = Owner(baseViewElement); // qualifiedName is the default representation
heritage	:>> columnFeature = HeritageList(baseViewElement); attribute :>> featureRepresentation :> ColRep::name;

Parameterised column types

The remaining column types were parameterised through attributes nested inside featureToRender. Each case below shows a complete column before and after the migration.

attributeValue

Before:

view Priority :> columnViews {
    attribute :>> featureToRender = CT::attributeValue {
        attribute attributeName = "priority";
    }
}

After:

view Priority :> columnViews {
    :>> columnFeature = NamedUsage(baseViewElement, "priority",
        UsageKind::attributeUsage);
    attribute :>> featureRepresentation :> ColRep::featureValue;
}

namedFeatureValue

Before:

view Engine :> columnViews {
    attribute :>> featureToRender = CT::namedFeatureValue {
        attribute featureName = "engine";
    }
}

After:

view Engine :> columnViews {
    :>> columnFeature = NamedUsage(baseViewElement, "engine");
    attribute :>> featureRepresentation :> ColRep::featureValue;
}

specificDocumentation

The documentationName parameter moves onto the representation.

Before:

view Rationale :> columnViews {
    attribute :>> featureToRender = CT::specificDocumentation {
        attribute documentationName = "rationale";
    }
}

After:

view Rationale :> columnViews {
    attribute :>> featureRepresentation :> ColRep::specificDocumentation {
        attribute :>> documentationName = "rationale";
    }
}

constraintLanguage with ConT::required

The ConstraintType (ConT) enum is retired along with constraintLanguage; each of its four members is its own case below. The old constraintLanguage value moves onto the 'language' representation as languageName in every one of them.

Before:

view Constraint :> columnViews {
    attribute :>> featureToRender = CT::constraintLanguage {
        attribute constraintName = "RC1";
        attribute constraintType = CT::CL::ConT::required;
        attribute constraintLanguage = "English";
    }
}

After:

view Constraint :> columnViews {
    :>> columnFeature = RequirementConstraintsFirst(
        baseViewElement,
        RequirementConstraintKindSV::required
    );
    attribute :>> featureRepresentation :> ColRep::'language' {
        attribute :>> languageName = "English";
    }
}

constraintLanguage with ConT::assumed

Before:

view Constraint :> columnViews {
    attribute :>> featureToRender = CT::constraintLanguage {
        attribute constraintName = "AC1";
        attribute constraintType = CT::CL::ConT::assumed;
        attribute constraintLanguage = "English";
    }
}

After:

view Constraint :> columnViews {
    :>> columnFeature = RequirementConstraintsFirst(
        baseViewElement,
        RequirementConstraintKindSV::assumed
    );
    attribute :>> featureRepresentation :> ColRep::'language' {
        attribute :>> languageName = "English";
    }
}

constraintLanguage with ConT::asserted

Before:

view Constraint :> columnViews {
    attribute :>> featureToRender = CT::constraintLanguage {
        attribute constraintName = "maxAltitude";
        attribute constraintType = CT::CL::ConT::asserted;
        attribute constraintLanguage = "English";
    }
}

After:

view Constraint :> columnViews {
    :>> columnFeature = NamedUsage(baseViewElement, "maxAltitude",
        UsageKind::assertedConstraintUsage);
    attribute :>> featureRepresentation :> ColRep::'language' {
        attribute :>> languageName = "English";
    }
}

constraintLanguage with ConT::plain

Before:

view Constraint :> columnViews {
    attribute :>> featureToRender = CT::constraintLanguage {
        attribute constraintName = "maxAltitude";
        attribute constraintType = CT::CL::ConT::plain;
        attribute constraintLanguage = "English";
    }
}

After:

view Constraint :> columnViews {
    :>> columnFeature = NamedUsage(baseViewElement, "maxAltitude",
        UsageKind::constraintUsage);
    attribute :>> featureRepresentation :> ColRep::'language' {
        attribute :>> languageName = "English";
    }
}

The RequirementConstraints family matches a constraint by its attachment rather than its name, which is why required and assumed drop the constraintName; it suits the usual unnamed, singular require / assume block. A named one can equally be reached by name, since these are plain constraint usages by metaclass.

Kinds now match exactly, which changes two of these mappings. A view that reached an assert constraint through a plain constraint kind needs the assertedConstraintUsage kind, or includeSubtypes set to true. Conversely, exact constraintUsage also matches the require / assume constraints inside a requirement; outside requirements the two were always the same thing.

The worked examples in Common patterns show the resulting columns in full.

Hierarchical tables

Before 0.11 a hierarchical table view had no dedicated tree column: whichever column was declared first implicitly carried the tree. Now the tree column is explicit. Every HierarchicalTableView owns a built-in hierarchicalColumn view usage, and the old first column becomes a redefinition of it: :>> hierarchicalColumn instead of the :> columnViews subset used for ordinary columns.

Before:

view myHierarchy : TVD::HierarchicalTableView {
    expose MyModel::RootRequirement;

    // the first column implicitly carried the tree
    view ID :> columnViews {
        attribute :>> featureToRender = CT::declaredShortName;
    }
    view Documentation :> columnViews {
        attribute :>> featureToRender = CT::documentation;
    }
}

After:

view myHierarchy : TVD::HierarchicalTableView {
    expose MyModel::RootRequirement;

    // the tree column is explicit: redefine hierarchicalColumn
    view ID :>> hierarchicalColumn {
        attribute :>> featureRepresentation :> ColRep::declaredShortName;
    }
    view Documentation :> columnViews {
        attribute :>> featureRepresentation :> ColRep::documentation;
    }
}

A first column left as a plain columnViews subset no longer becomes the tree: the table renders the built-in tree column ahead of it, labelled by the declared name, and the old column repeats as an ordinary one. If the declared name is all the old first column showed, delete the column and let the default hierarchicalColumn stand.