Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. Be respectful, on topic and if you see a problem, Flag it.

If you would like to contact our Community Manager personally, feel free to send a private message or an email.

part studio granularity best practices and refactoring

jeff_mcafferjeff_mcaffer Member Posts: 64 ✭✭

With the help of you all I've been learning onshape and am continually impressed. As yet though, I I've not really grokked the Zen of how complex part studios and assemblies should be. As a result, I find myself frequently wanting to refactor what features are in what part studios. In some cases, this is merely aesthetic (is the part studio too packed? or, do I have too many parts studios to manage?). In other cases, there are functional implications (e.g., you can't derive a part into its own part studio).

In any event there does not appear to be a way to copy features from one part studio to another (though you can copy sketches around). Duplicating a part studio and deleting the bits you don't want from the original and new copies is "OK" for splitting but is prone to loss and redundancy. I don't see a way to merge part studios. This all leads to two questions:

  • What's the best way to learn the best practices around part studio granularity? Are there any guides (or guidelines)?
  • Am I missing something wrt part studio refactoring facilities in onshape?

Aside, since onshape is (very cooly) based on code, I wonder if we could use some of the facilities seen in software development environments like Visual Studio, Eclipse, IntelliJ,.. which all have really rich code refactoring facilities. This discussion is directly analogous to coding and complexity of classes, functions, packages, modules, … We've learned from decades of coding that one's view of "right" factoring changes as one's understanding of the project and scope of sharing evolves. Thus, the need for refactoring.

Answers

Sign In or Register to comment.