Take a look at XForms standard, it might work well for you with its declarative contraints.
On Wed, Sep 3, 2014 at 5:55 PM, Kevin Meyer <[email protected]> wrote: > 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 > > > >
