[Smtk-developers] Q: Either-or combinations of attribute items

[Robert Michael O'Bara]

I wonder if we need a find method that is template based - like the addItemDefinition method in Definition.h ?
Then we have one method that will automatically deal with new item definition types

  typedef smtk::attribute::IntItem IntComp;
  typedef smtk::attribute::DoubleItem DoubleComp;
  typedef smtk::attribute::StringItem StringComp;
  typedef smtk::attribute::ValueItem ValueComp;
  typedef smtk::attribute::Item AttComp;

attribute->find<IntComp>("Specification Mode")->find<DoubleComp>("Height") ?

Also note that the above would core dump if the first find fails.



Robert M. O'Bara, MEng.
Assistant Director of Scientific Computing

Kitware Inc.
28 Corporate Drive
Suite 101
Clifton Park, NY 12065

Phone: (518) 881- 4931




On Nov 11, 2014, at 5:53 PM, David Thompson <david.thompson at kitware.com> wrote:

>> BTW, the UI will display this as a combo box with Enum entries ("Axis aligned", "General"), and when an entry is selected in the combo box, a widget with specified items for that Enum value will be shown under the combo.
> 
> Nice. Now I just need an easy way to access the resulting parameters. I had added methods to Attribute to find items of the correct type:
> 
>  DoubleItem findDouble(const std::string& itemName);
>  IntItem findInt(const std::string& itemName);
>  // and so on...
> 
> This has been really useful in smtk/model so far; I can write
> 
>  AttributePtr result;
>  if (result->findInt("outcome")->value() == OPERATOR_SUCCESS)
>    // ...
> 
> instead of many lines of code to find the number of items, iterate until I find one of the given name, and downcast it to the proper type. Now I need some way to access children the same way. Does anyone have a preferred method for doing this? I could add methods of the same name to ValueItem so that (for Bob's example), one could descend the tree manually:
> 
>   AttributePtr brickOp;
>   brickOp->findInt("Specification Mode")->findDouble("Width");
> 
> but this doesn't take active vs inactive children into account. An extra parameter might indicate whether findDouble searched all children or just the active children. Also, the above would not find granchildren without a full specification of the "path". It might be preferable to write
> 
>   brickOp->findDouble("Width", ACTIVE_CHILDREN);
>   // or NO_CHILDREN or ALL_CHILDREN for the 2nd argument
> 
> instead of
> 
>   brickOp->findInt("Specification Mode")->findDouble("Width");
> 
> Any opinions? Does search order (depth-first vs breadth-first) make a big difference to anyone (assuming the first match is returned)?
> 
> 	Thanks,
> 	David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/smtk-developers/attachments/20141111/ddbafe79/attachment-0001.html>