Notes: generic fields on bins/bin types, field groups as domain filter, duplicate bin type
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -206,6 +206,13 @@ Some fields naturally belong together (e.g. `frequency_stability` and
|
|||||||
Structured records are the more powerful option but require a schema system and
|
Structured records are the more powerful option but require a schema system and
|
||||||
more complex UI. Grouping/linkage is a lighter short-term win.
|
more complex UI. Grouping/linkage is a lighter short-term win.
|
||||||
|
|
||||||
|
As fields are shared across entity types (components, bins, bin types, and anything
|
||||||
|
else added later), the field pool grows to span unrelated domains. Groups also serve
|
||||||
|
as a domain filter in the field selector — when adding a field to a bin type, you
|
||||||
|
should be able to filter to e.g. "physical" or "storage" fields rather than seeing
|
||||||
|
electrical component fields mixed in. Each field should be able to belong to one or
|
||||||
|
more groups.
|
||||||
|
|
||||||
#### Semantically-aware formatting (acronyms, proper names)
|
#### Semantically-aware formatting (acronyms, proper names)
|
||||||
Formatters that apply title case or similar text transformations can corrupt acronyms
|
Formatters that apply title case or similar text transformations can corrupt acronyms
|
||||||
(e.g. `NPN` → `Npn`) or brand/proper names. The root cause is that free-text field
|
(e.g. `NPN` → `Npn`) or brand/proper names. The root cause is that free-text field
|
||||||
@@ -416,6 +423,23 @@ dimensions are pre-filled — no need to re-enter for every bin of the same mode
|
|||||||
This also enables filtering/grouping bins by type, and makes it easy to re-process
|
This also enables filtering/grouping bins by type, and makes it easy to re-process
|
||||||
all bins of a type if the corner algorithm improves.
|
all bins of a type if the corner algorithm improves.
|
||||||
|
|
||||||
|
### Generic fields on bins and bin types
|
||||||
|
Bins and bin types should support the same generic field system as components —
|
||||||
|
arbitrary key/value pairs from the shared field definitions. Examples: color, material,
|
||||||
|
manufacturer, max load, purchase link. Bin types carry the "template" fields (e.g.
|
||||||
|
nominal dimensions from the datasheet) while individual bins carry instance-specific
|
||||||
|
fields (e.g. actual color of that specific unit).
|
||||||
|
|
||||||
|
Because fields are shared across components, bins, and anything else that grows into
|
||||||
|
the system, they will quickly span unrelated domains. Field grouping (see Field system
|
||||||
|
section) becomes important here so the field selector can be filtered to show only
|
||||||
|
relevant fields for the current entity type.
|
||||||
|
|
||||||
|
### Duplicate bin type
|
||||||
|
Bin types should be duplicatable — common when you have the same physical container
|
||||||
|
in different colors, sizes, or configurations. Duplicating copies all fields and
|
||||||
|
dimensions; the user then adjusts what differs.
|
||||||
|
|
||||||
## Grids
|
## Grids
|
||||||
|
|
||||||
### Grid view layers
|
### Grid view layers
|
||||||
|
|||||||
Reference in New Issue
Block a user