Closed bartv closed 3 years ago
In the current state of things, the input attributes would look like this:
desired_attributes = {
"identifier": "my-evc-001",
"connectionType": "POINT_TO_POINT",
"evcEndPoints": [
{
"identifier": "my-evc-ep-1",
"egressBandwidthProfilePerEndPoint": [
{
"cir": 1,
},
{
"cir": 2,
},
],
"evcEndPointMap": {
"type": "LIST",
"vlanIdList": [{"vlanId": 200}],
},
"carrierEthernetSubscriberUni": {
"href": "inmanta:456-852-789",
},
},
{
"identifier": "my-evc-ep-2",
"egressBandwidthProfilePerEndPoint": [
{
"cir": 1,
},
{
"cir": 2,
},
],
"evcEndPointMap": {
"type": "LIST",
"vlanIdList": [{"vlanId": 201}],
},
"carrierEthernetSubscriberUni": {
"href": "inmanta:123-852-456",
},
},
],
}
for a service definition that looks like this:
entity CarrierEthernetService:
connection_type connectionType
end
entity CarrierEthernetEvc extends CarrierEthernetService, lsm::ServiceEntity:
evc_id identifier
end
index CarrierEthernetEvc(identifier)
CarrierEthernetEvc.evcEndPoints [2] -- CarrierEthernetEvcEndPoint
entity CarrierEthernetEvcEndPoint extends lsm::EmbeddedEntity:
evc_id identifier
end
index CarrierEthernetEvcEndPoint(identifier)
CarrierEthernetEvcEndPoint.egressBandwidthProfilePerEndPoint [0:] -- EgressBwpFlow
CarrierEthernetEvcEndPoint.evcEndPointMap [1] -- VlanIdListOrUntag
CarrierEthernetEvcEndPoint.carrierEthernetSubscriberUni [1] -- CarrierEthernetSubscriberUniRef
entity EgressBwpFlow extends lsm::EmbeddedEntity:
std::positive_int cir
end
entity VlanIdListOrUntag extends lsm::EmbeddedEntity:
vlan_id_list_type type
end
VlanIdListOrUntag.vlanIdList [0:] -- VlanId
entity VlanId extends lsm::EmbeddedEntity:
vlan_id_type vlanId
end
entity CarrierEthernetSubscriberUniRef extends lsm::EmbeddedEntity:
string href
end
Here is an automatically generated openapi json file for this service:
To adhere as much as possible to the patternfly guidelines and components, Form Group
s have been used to achieve the following design:
We start at level 0 for the root properties. Every next level has an indentation of 32px (This was the indentation provided by Patternfly Form Group components). We make a distinction between FLAT properties and NESTED properties.
FLAT (all basic values with basic input fields):
NESTED:
These types should cover all different possibilities. FLAT values can just be presented as a normal input field. NESTED values have a collapsable view. Inside this view, for each property that is flat, we can show the normal input field. For every property that is nested, we show a collapsable view again. (... and so on... and so on...)
List of objects are special where they have 2 actions.
This looks useful indeed. I even think that the json and/or yaml view could be nice (in a later version). Because that is exactly what you do: create a json body (of which yaml is a less bad way to write it)
Looks nice indeed, the different views as well. Minor comment: Maybe we could increase the visual emphasis on what belongs together, with regards to nesting. I think it can be a bit difficult to follow that, if the structure is complex. (Then again, there might not be an easy way to show it, if it's that complex, but maybe some more spacing / bordering can help). +1 : The design might be easier to understand if the property names were not just one letter long :slightly_smiling_face:
Overall very nice I think. :+1:
Yea, I think we need to try it out a bit. We can always improve it later.
Diverging from this design would introduce custom styles which is more work.
I hope the collapsing will help the overall UX. Hide some details you are not focussed on.
Maybe to aid the structure we can introduce some different labels.
(instead of abc
, we can do def.abc
and emphasize the dot a bit.
Currently the add instance form only support the toplevel attributes. More and more services use a nested structure. This goal of this ticket is to: