You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently GetRevitElementType method is used to query representations of Revit types from BHoM object representing Revit elements. This has 1 main drawback, being the developer needing to know that support for any new object type needs to be added explicitly to the method (e.g. @enarhi has a low chance of knowing about it while working on #1341).
Additionally, GetRevitParameterValue does not leverage GetRevitElementType, instead it parses all properties of the parent object looking for the one that has RevitPulledParameters fragment, which ultimately should give the same results.
Ideally, the 2nd solution could be encoded into GetRevitElementType to avoid requirement for manual support for each new type. Then it could be reused wherever needed.
I see two potential issues with such solution:
performance - parsing all property values in search for fragment would be way slower than simply returning the property bound compile time
existence of BHoM objects that have more than 1 property corresponding to Revit entities - here I can think of a Revit element with a type and nested element, which could possibly land under 2 different properties in the resultant BHoM object - a bit speculative but sounds like a potential risk
The text was updated successfully, but these errors were encountered:
Description:
Currently
GetRevitElementType
method is used to query representations of Revit types from BHoM object representing Revit elements. This has 1 main drawback, being the developer needing to know that support for any new object type needs to be added explicitly to the method (e.g. @enarhi has a low chance of knowing about it while working on #1341).Additionally,
GetRevitParameterValue
does not leverageGetRevitElementType
, instead it parses all properties of the parent object looking for the one that hasRevitPulledParameters
fragment, which ultimately should give the same results.Ideally, the 2nd solution could be encoded into
GetRevitElementType
to avoid requirement for manual support for each new type. Then it could be reused wherever needed.I see two potential issues with such solution:
The text was updated successfully, but these errors were encountered: