Some things that aren’t really related to the question, but might be useful to consider in the feature:
@model_operation doesn’t hold an Operation object (there is no such class), but the name of the operation. I’d typically call this
operation_name for a more honest and easier to understand code.
I suspect you never use the
draw_status variable as it in my experience would always contain the same value. If so, you can just purge it to have less things going on, and make the code easier to read.
The capitalization of “King Post” suggests it is exposed in the UI. Generally it’s good to separate UI strings from internal identifiers, as the UI may be translated or in other ways changed.
String comparison is also slow in Ruby, so for an internal identifier a symbol,
:king_post, or a constant referencing an Integer,
KING_POST, would be faster. Using another type for identifiers could also help distinguish them from UI string.
In the long term though, I’d advise to use a class hierarchy rather than identifiers to structure the code. Rather than comparing @Trusstype to a String, you could check if @truss is of a certain class, like so
@truss.is_a?(KingPost). Even better could be to define the behavior common to all trusses in the Truss class, and then have the KingPost class override that method, perhaps with a call to super.