# Operations and selection
**URL:** https://discourse.kitware.com/t/operations-and-selection/480
**Category:** Design
**Created:** [June 10, 2020, 1:18am UTC](https://discourse.kitware.com/t/operations-and-selection/480 "2020-06-10T01:18:40Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [June 10, 2020, 1:18am UTC](https://discourse.kitware.com/t/operations-and-selection/480/1 "2020-06-10T01:18:40Z")
I have a use case (for aeva) where I would like an operation to modify the application’s selection. I see a few ways to do it:
- _good_: add `ReferenceItem`s to the operator’s `Result` attribute named _append to selection_ and _remove from selection_. Then the application can decide what to do with them when processing the result. The reference items can have `HoldReference="true"` so that shared pointer things (like ephemeral selection objects).
- _bad_: add a new `SelectionOperation` subclass of `XMLOperation` and have the application register its `Selection` with the operation manager, which will construct each SelectionOperation it creates with the application’s selection object.
- _ugly_: have the operation link to the SMTK’s `paraview/appcomponents` library. When the application runs, it fetches the application’s selection from the `pqSMTKBehavior` instance and modifies it.
While I included the _ugly_ option as a joke (albeit a prank I may pull in the short term), does anyone have a preference for the long-term solution?
---
### Author:  [@tj.corona](https://discourse.kitware.com/u/tj.corona)
#### Post date: [June 10, 2020, 12:20pm UTC](https://discourse.kitware.com/t/operations-and-selection/480/2 "2020-06-10T12:20:44Z")
I am not sure if your _good_ solution is that much better than the other options you mentioned. I’m also not sure that the other options you mentioned are all that _bad_ and _ugly_. I would be interested in knowing more about your use-case to determine whether or not this is broad pattern that we expect many modeling sessions to require.
---
### Author:  [@dcthomp](https://discourse.kitware.com/u/dcthomp)
#### Post date: [June 10, 2020, 2:21pm UTC](https://discourse.kitware.com/t/operations-and-selection/480/3 "2020-06-10T14:21:05Z")
Offline, @tj.corona came up with a third alternative that seems like the cleanest approach:
- add a `SelectionGroup` (that inherits `smtk::operation::Group`) to indicate the operation would like to work with a selection provided by the operation.
- have the application add an `operation::MetadataObserver` to its `operation::Manager` that passes the `Selection` to operations in that group as they are created by the operation manager.
I’m not sure how (without inheritance), the application’s metadata observer can pass the selection to the operation, but assuming that works out, it definitely is the most flexible alternative; the operation would be able to prepare the selection directly instead of via hints.