Issue #5729: Improve the handling of fragment IDs in
CommandableFragmentGenerator and children
Bug fixes:
none
Operational changes:
none
Known issues:
The interface for setting and fetching fragment IDs from
CommandableFragmentGenerator has changed, so classes that inherit
from it may also need to change. Some usage notes, for reference:
The CommandableFragmentGenerator constructor (and the
constructors of all classes that inherit from it) check the
input ParameterSet for several fragment-id-like parameters:
It first checks for a parameter named “fragment_ids”, and if
that exists, it stores the specified list of IDs in its
internal list of fragment IDs.
It next checks for a parameter named “fragment_id”.
If that parameter exists, and the fragment_ids parameter
was not specified, the specified fragment ID is stored
as the first element in the internal list of fragment
IDs.
If that parameter exists, and the fragment_ids parameter
was specified, then an exception is thrown. (Both
parameters can not be specified in the same
ParameterSet.)
If neither “fragment_ids” nor “fragment_id” are specified in
the ParameterSet, then the relevant child class should take
care of filling the fragment_ids_ data member or over-ride
the fragmentIDs() method to specify the fragment IDs that
the particular FragmentGenerator instance generates.
The fragment_ids() method returns the list of fragment IDs, as
one would expect. This list could have one or more elements.
The fragment_id() method is a convenience method that returns
the single fragment ID in the case that only one fragment ID has
been specified. If more than one fragment ID has been specified
and this method is called, an exception is thrown.