Data Object Slot Groups for RiverWare 6.8 -- Analysis
Phil Weinstein, CADSWES -- Edit: 8-20-2015 (a), initial writing in progress.
This document provides an analysis of a new requested capability in RiverWare, characterized by this request summary (from TVA):
Create Slot Groups on Data Objects: Allow arbitrary sets of slots to be grouped together (such as SEPA data, Policy Data, etc). Allow the group and slots to be copied/pasted.
An initial analysis and summary was prepared last month, focusing on a direct architecutal approach to adding Slot Groups. See this document:
Estimates for TVA Data Object Enhancements / July 2015 -- (7-21-2015)
R:\doc\openObject\SlotGroups\SlotGroups-TvaEst-July2015.html
R:\doc\openObject\SlotGroups\SlotGroups-TvaEst-July2015.pdfNote [8-19-2015]: The only revisions to those estimates that I would make is that Slot Group Filtering, as such, is not actually a requirement. That potentially adds a lot of complexity, and is not likely to be important. The support of that feature for Slots (including within an Agg Obj Element, if we do choose that approach) should be sufficient. This reduces that estimate by 16 hours. (Tasks 1.5 and 1.12).
This analysis revisits that approach, and also an alternative approach leveraging Aggregate Objects and their Element Objects. These two approaches are described in these subsequent sections:
TVA development model:
R:\doc\openObject\SlotGroups\models\SpecialOps6HourV6.mdl
Two issues of slot name "scope" weigh heavily on the chosen architectural approach for Slot Groups.
The implications of the two contrasting approaches are summarized in this table:
| Slot name uniqueness at Object Level | References require Slot Group Name | |
| New Architectural Feature (as currently devised) | Unique, as natural outcome of the most direct implementation, as currently devised. | No, by default. Slots actually still "live on" the object. Slot Group membership is a new property associated with each Slot. |
| Implemented with Agg Obj Elements | Not unique, as the natural outcome of the most direct implementation. (Slots in a slot group can readily have the same as a slot in a different group, but on the same data object). | Yes. Doing otherwise would require both explicitly enforcing slot name uniqueness (across all slot groups within the object) AND a data object's slot name space would have to be extended to include that of the child element objects (groups). |
This issue is significant, and weighs heavily on the decision of which approach to take.
This wasn't identified as an explicit requirement, but it obviously would potentially be useful. An initially perceived benefit of the Agg Obj Element approach was that this feature would be essentially free. However, it would not be difficult to add provisions (a RPL Predefined Function) to return the list of slots in a named Slot Group on a particular Data Object. Also, with the Agg Obj Element, we would want to customize any indications about these objects generated by the program (including error messages) to correctly distinguish between Agg Obj Elements and Data Object Slot Groups -- and that may have a large impact.
The fundamental required features apply almost exclusively to the Open Object Dialog. This section provides a review of how the major required features would be provided in that dialog. Regardless of whether support for Aggregate Object Elements are used internally -- at the data model level -- the design and GUI implementation would reasonably be based on support for those objects.
(3.1) Life-cycle Management of a set of Slot Group instances on Data Objects.
(3.2) Slot Group Naming (unique within the data object instance)
(3.3) Slot Group Custom Ordering
(3.4) Slot Filtering -- no Slot Group enhancement recommended
(3.5) Slot Clipboard: Support for copying and pasting Slot Groups.
(3.6) GUS slot selector support -- not initially required
While not directly making use of Agg Obj Element provisions, much of the Slot Group's management could be based on those operations for Agg Obj Elements -- this includes Inserting, Appending and Deleting Elements, supported in both a menubar "Elements" menu and the content menu on Element items.
A significant distinction is that deleting a Slot Group would not necessarily delete the contained Slots -- though that could be implemented as an option -- perhaps as a third button in the Delete Elements Warning dialog shown above.
As currently envisioned, Slot Groups will not have their own "Open" dialog -- as do Slots. It would be reasonable to support Slot Group naming with inlined edits, as are Aggregate Object Elements. (But the containing Data Object name would not have to be part of the Slot Group tree item label -- in particular, if this is a New Architectural Feature approach is taken).
For certain usability and implementation reasons, we may want to require that Slot Group names be distinct from the names of Slots, within any given Data Object.
Currently, Element Objects within an Agg Object are not reorderable. See the controls highlighted controls at the bottom of this Open Object dialog screenshot:
The Up and Down arrow icon buttons are enabled only when slots are selected. However, that would seem to be an important capability for Slot Groups. It would be reasonable to support reordering of ONLY Slot Groups OR Slots at any given time -- that is, the Up and Down arrow icon buttons would be enabled if only one of those two types of treeview items were selected.
With the New Architectural Feature approach, the Slot reordering algorithm would need to be adjusted to disable the move up/down operations if the first/last slots within a Slot Group are selected. Also (see below), with that approach, I'm recommending that there be support for the "conventional" display of a Data Object's slots -- without regard to Slot Groups. In that mode, the slot reordering algorithm should still function as it would for the normal Slot Group treeview presentation, where slots within a group must remain contiguous.
No enhancement is actually required for Slot Filtering, with either implementation approach. This mechanism is multifacited and quite well developed. (And it does support filtering of Slots on Aggregate Object Elements). The added complexity of incorporating Slot Groups into the filtering capabilies would probably not even be appreciated by users -- it's already quite complex.
Note that the original July estimate included 16 hours for the Slot Group Filtering enhancement (Tasks 1.5 and 1.12). Again, I'm recommending that this be skipped.
It would be reasonable to enhance the Slot Clipboard in such that way that it contains only slots or slot groups at any given time. Basically, the "Copy Slots" operation would be enabled if only Slot or Slot Group items were selected within the slot list.
With the Agg Obj Element approach, the Slot Clipboard's "Slot Group" mode would essentially be references to Agg Obj Elements. With the New Architectural Feature approach, it would be references to a Data Object and the name of a Slot Group. (It would be OK to drop the slot clipboard's Slot Group content if Slot Groups get renamed).
With this Slot Clipboard enhancement in place, it would be quite easy to enhance the newly developed "Copy Slots to Data Objects..." operation to support Slot Groups. (Whether Slots or Slot Groups were supported would depend on the nature of the slot list's item selection, upon initiating the operation). This new feature is described in this document:
Open Object Dialog, Slot Copy/Paste Enhancements for RiverWare 6.8 (8-17-2015).
Source: R:\doc\openObject\CopySlots\OpenObjCopyPasteEnh-Aug2015.docx
Online HTML copy: http://cadswes2.colorado.edu/~philw/2015/OpenObj/CopyPasteSlots/FeatureDoc.html
PDF: http://cadswes2.colorado.edu/~philw/2015/OpenObj/CopyPasteSlots/OpenObjCopyPasteEnh-Aug2015.pdf
The GUS slot selector could be enhanced in the following two ways to support Slot Groups. This is not an initial requirement, and could be done as a subsequent enhancement:
As mentioned above, two implementation approaches are being considered. The following subsections describe these approaches in more detail.
(4.1) Data Object Slot Groups, as a New Architectural Feature
(4.2) Data Object Slot Groups, Implemented with Agg Object Elements
This was the approach outlined in the July analysis and estimate cited above. The relationship between a Data Object and its slots would not be directly affected -- a Data Object's slots still live on the Data Object. With the specific implementation being proposed -- each Slot would have an additional property indicating which Slot Group (if any) it is associated with -- relative to the containing Data Object.
Since the association with a Data Object's slot with a Slot Group is implemented just as a property of the Slot, it would be natural -- and useful during development, for debug and testing -- to support a mode where the Data Object's slots are displayed "conventionally" within the Open Object dialog -- without regard to Slot Groups. In such a view, a slot's Slot Group association could be displayed as an optional column.
Aside from optional ancillary features (e.g. a RPL Predefined Function to support the enumeration slots in a Slot Group), development would be focused around the Open Object Dialog, its QTreeWidget-based slot list, and internal data model support for supported features.
The current support for Agg Object Elements could be leveraged for Slot Groups. This would entailed the following sorts of tasks: