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
Having recently been enabling the UpdateOnly for Robot_Toolkit (is working really well!) I'm thinking it would be good to extend/expose a bit more structured interaction to the human interface.
A specific workflow to enable could be: push property changes of objects to specific objects/a selection only, without needing to pull/construct the whole object. At the moment, the typical update only workflow means pushing an object with all properties required to be set, otherwise null or empty properties will reset the properties in the external software. Moreover, there are some object properties that the current toolkit/behavior preclude, e.g. changing of object numbering in Robot/structural adapters, as the comparers are hard coded.
As a suggestion, the specific workflow could be enabled through the current Push component, and by pushing 'bespoke' or specific classes into 'objects' input that contain:
ObjectType - the types of object whose property is required to be updated;
Comparer (or ObjectComparer) - the property of the object to compare. This needs a bit of work, as I think we should expose 'Comparerers' more generally in the human interface, so that people can compare things in any workflow;
PropertyName - the name of the property to be updated;
PropertyValue - the value to update the property to.
Specific workflow: modify the node numbers of a Robot analysis model by comparing the nodal coordinates and updating the numbers where they match within a human-specified tolerance.
We actually used to have a method not to dissimilar to this on the base Adapter interface (UpdateProperty) but it was never really properly implemented in any toolkit and was decided to get removed for now a few months ago with focus on getting the push fully functioning with proper support for the UpdateOnly workflow. Link to method from 2.0 release branch here:
Might be a candidate to bring back again at some point (maybe tweaked a bit according to what your findings adding the Update methods for Robot @rwemay ). If added back in, it would be nice to get it functioning through the CRUD methods already in place though I would say (if possible) to avoid having two completely different sets of methods to maintain + avoid confusion between Update and UpdateProperty!
Also, general exposure of comparers to let users choose I think would be a quite cool feature. Having default ones stored on the adapter itself, controlling the standard workflow (merging nodes by coordinates etc) but being able to, if you wanted to, instead merge nodes by name, bars by section or whatever weird and wonderful thing you might want to be able to do:+1:
Right - perfect, UpdateProperty was what I had in mind, but would be great to weave into current adapter/interface, if it's not pushing too much in/complicating it for humans too much. Agree on comparer exposure, could be really good. Also a good way to expose to people how complex these operations can actually be - not every workflow works with strick/hard coded node numbering!
Having recently been enabling the UpdateOnly for Robot_Toolkit (is working really well!) I'm thinking it would be good to extend/expose a bit more structured interaction to the human interface.
A specific workflow to enable could be: push property changes of objects to specific objects/a selection only, without needing to pull/construct the whole object. At the moment, the typical update only workflow means pushing an object with all properties required to be set, otherwise null or empty properties will reset the properties in the external software. Moreover, there are some object properties that the current toolkit/behavior preclude, e.g. changing of object numbering in Robot/structural adapters, as the comparers are hard coded.
As a suggestion, the specific workflow could be enabled through the current Push component, and by pushing 'bespoke' or specific classes into 'objects' input that contain:
ObjectType
- the types of object whose property is required to be updated;Comparer
(orObjectComparer
) - the property of the object to compare. This needs a bit of work, as I think we should expose 'Comparerers' more generally in the human interface, so that people can compare things in any workflow;PropertyName
- the name of the property to be updated;PropertyValue
- the value to update the property to.Specific workflow: modify the node numbers of a Robot analysis model by comparing the nodal coordinates and updating the numbers where they match within a human-specified tolerance.
Thoughts on a postcard @al-fisher , @alelom , @IsakNaslundBh
The text was updated successfully, but these errors were encountered: