Save instances created from non-built-in ruby classes in a Sketchup model

I am trying to write a plugin for interior architects and furniture manufacturers to maintain the cabinet database.
All information about the cabinets will be stored in the MySql database. Inserting them into the model will be preceded by creating their instances in Ruby based on the appropriate classes written by me.
The idea is: to create instances of cabinets in Ruby, process them there, and only draw in Sketchup as
Class: Sketchup :: Group. Of course, I will need a link between the instances in Ruby and the drawings in Sketchup.
And my question is: how / where to store the instances created in Ruby to be available and created after reloading the model.
Did you do something like that? Do you have any idea?

Instances created in Ruby already stored in the model you can differentiate them if you are attaching attributes to it:


and soo on…

Only API Sketchup::Entity subclass instances are saved into the model .skp data.

As Dezmo shows, you would need to store properties and recreate your custom Ruby instances.
You can attach the properties using the AttributeDictionaries, or use persistent id to link into your SQL dB.

There is also in Ruby the OpenStruct which makes creating property sets easier than crafting custom classes.

Also using groups will hide your cabinets from the “In Model” Components collection. (This might be desirable.)

Thanks for your answers.

Also using groups will hide your cabinets from the “In Model” Components collection. (This might be desirable.)

Dan, could you please write something more about this. I don’t quite understand what’s going on.

It’s simple. Groups are actually “special” types of component instances.

So group instances also have a ComponentDefinition. This is why there is a Sketchup::ComonentDefinition#group? method to determine if the definition is used for groups.

It is the definition (for both groups and components) that really “owns” and has the entities collection.

1. So groups have “special” uses. If a user manually enters a group editing context, and that group’s definition has more than 1 instance, the definition is automatically cloned making that group instance unique.
(It becomes the first instance of the cloned definition, and the former definition’s instance count is decremented.)

2. The second thing is that by design, the definitions for groups are hidden from the “In Model” Component definitions listing (in the Components inspector panel.) They are still members of the model’s DefinitionList collection, but are just not shown.
This is done because nested DC groups should not be shown (as it would overwhelm the listing) and groups are not meant to be used like insertable components.

3. Thridly, group instances may not honor display and snap behavior like the instances of component definitions do.