Skip to content
Snippets Groups Projects
Commit c94659f1 authored by Floris Berendsen's avatar Floris Berendsen
Browse files

DOC: added some notes on design considerations

parent 1dfb1122
No related branches found
No related tags found
No related merge requests found
......@@ -30,12 +30,15 @@ namespace selx
Blueprint::ComponentIteratorPairType::second_type componentItEnd = componentItPair.second;
for (componentIt = componentItPair.first; componentIt != componentItEnd; ++componentIt)
{
ComponentSelector::NumberOfComponentsType numberOfComponents = this->m_ComponentSelectorContainer[*componentIt]->UpdatePossibleComponents();
ComponentSelector::NumberOfComponentsType numberOfComponents = this->m_ComponentSelectorContainer[*componentIt];
// The current idea of the configuration setup is that the number of
// possible components at a node can only be reduced by adding criteria.
// If a node has 0 possible components, the configuration is aborted (with an exception)
// If all nodes have exactly 1 possible component, no more criteria are needed.
//
// Design consideration: should the exception be thrown by this->m_ComponentSelectorContainer[*componentIt]?
// The (failing) criteria can be printed as well.
if (numberOfComponents == 0)
{
itkExceptionMacro("Too many criteria for component");
......@@ -101,7 +104,16 @@ namespace selx
//
// We might consider copying the blueprint graph to a component selector
// graph, such that all graph operations correspond
//
// This could be in line with the idea of maintaining 2 graphs: 1 descriptive (= const blueprint) and
// 1 internal holding to realized components.
// Manipulating the internal graph (combining component nodes into a hybrid node, duplicating sub graphs, etc)
// is possible then.
//
// Additional redesign consideration: the final graph should hold the realized components at each node and not the
// ComponentSelectors that, in turn, hold 1 (or more) component.
//
//
// Or loop over connections:
//Blueprint::ConnectionIteratorPairType connectionItPair = this->m_Blueprint->GetConnectionIterator();
//Blueprint::ConnectionIteratorPairType::first_type connectionIt;
......
......@@ -30,6 +30,8 @@ public:
ComponentIndexType index0 = blueprint->AddComponent(componentParameters);
ComponentIndexType index1 = blueprint->AddComponent(componentParameters);
// TODO: For now, the connections to make are explicitly indicated by the Interface name.
// Design consideration: connections might be indicated by higher concepts ( MetricCostConnection: value and/or derivative? DefaultPipeline? )
ParameterMapType connectionParameters;
connectionParameters["NameOfInterface"] = ParameterValueType(1, "itkImageSourceInterface");
......@@ -61,9 +63,14 @@ TEST_F(ProcessObjectTest, Configure)
overlord = Overlord::New();
overlord->SetBlueprint(blueprint);
bool allUniqueComponents;
// Read the blueprint and try to realize all components
// If for any node no components could be selected an exception is thrown.
EXPECT_NO_THROW(allUniqueComponents = overlord->Configure());
// If for any node multiple components are selected, allUniqueComponents is false.
EXPECT_TRUE(allUniqueComponents);
// If Configuration was successful, the graph (pipeline) can be executed.
EXPECT_NO_THROW(overlord->Execute());
}
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment