Hi guys,
I'm having to tackle a problem at work that involves working with a list
of objects in a tree structure.
The list is a flat list of "configuration records" (needed to configure a
scientific plant system prior to operation) and "configuration
constraints" (which express mathematical relationships with and between
configuration records).
The flat list of configuration records is not convenient to work with - so
we want to give the plant system responsible officer (RO) a visual
structure to help group similar records together, and edit record values
(i.e. the tree nodes - the configuration records - represent objects that
the RO will edit in many ways).
Each record represents one of many value types (doubles, integers,
strings, or arrays of each, etc).
For the moment, though, I just assume each is a double (floating point)
number.
"Fortunately" there is a strict naming scheme for these records which
embeds a "control breakdown structure" and a "function breakdown
structure" (see below for a list of record names).
The "configuration editor" needs to parse an XML file with a "flat"
structure (all configuration records are at the same level), but the
visual UI should extract and support a tree struture:
e.g., using the list below:
D1-I3-B3C0
+ DP
+ AN
+ DD
B,R
+ FT
TM-R
+ CB
etc
(defining the text parsing rules that encode the structure is another
problem)
The "configuration editor" will need to write back the XML file, which
must remain parseable by other systems that should not be affected by
information required (if any) to encode the "visual" structure.
Contraints could be similarly grouped, but they are "just" named
expressions: e.g.
"Max power limit" "D1-I3-B3C0:DP-AN-DD-B + D1-I3-B3C0:DP-AN-DD-B < 10"
Ideally, the UI items should be aliasable (e.g. "D1-I3-B3C0" is "Neutron
Diagnostics", "DP" is "Data Processing", etc) in the UI. So, yes, I expect
to create POJOs to represent the UI structure, and some will contain a
"configuration record" (the leaves in the tree).
Two questions come to mind:
1. What do the POJOs look like that can encode such a structure of
configuration records
2. Can the Wicket viewer be updated to support a drag-and-drop tree
structure(drag and drop to re-arrange the structure from the "as-parsed")
to reannrage and merge branches.
Later on it may turn out more flexible to write a stand-alone viewer to
manage the UI (that uses the REST API to interface with the core
application logic).
I want to consider Isis as there will (later on) be many service-level
operations (such as authorisation, auditing, version control, etc) that
Isis supports quite nicely!
Thanks in anticipation!
Kevin
Example partial list of configuration records:
D1-I3-B3C0:DP-AN-DD-B
D1-I3-B3C0:DP-AN-DD-R
D1-I3-B3C0:DP-AN-FT-TM-R
D1-I3-B3C0:DP-AN-FT-TN-R
D1-I3-B3C0:DP-AN-FT-TR-R
D1-I3-B3C0:DP-AN-DD-B
D1-I3-B3C0:DP-CB-CS-S
D1-I3-B3C0:DP-CL-PA-NC-S
D1-I3-B3C0:DP-CL-PA-NR-R
D1-I3-B3C0:DP-CL-PA-XC-S
D1-I3-B3C0:DP-CL-PA-XR-R
D1-I3-B3C0:DP-CL-PW-NC-S
D1-I3-B3C0:DP-CL-PW-NR-R
D1-I3-B3C0:DP-CL-PW-XC-S
D1-I3-B3C0:DP-CL-PW-XR-R
D1-I3-B3C0:DP-CL-WD-DC-S
D1-I3-B3C0:DP-CL-WD-DR-R
D1-I3-B3C0:DP-CL-WD-DS-R
D1-I3-B3C0:DP-ME-CM-R
D1-I3-B3C0:DP-ME-CN-R
D1-I3-B3C0:DP-ME-CR-R
D1-I3-B3C0:DP-ME-WD-R
D1-I3-B3C0:GL-VA-VP-RV-R
D1-I3-B3C0:GL-VA-VT-RV-R
D1-I3-B3C0:IF-DN-CD-S
D1-I3-B3C0:IF-DN-RD-R
D1-I3-B3C0:IF-TN-CG-MT-R
D1-I3-B3C0:IF-TN-CG-PX-R
