mirror of
https://github.com/go-admin-team/go-admin.git
synced 2026-09-25 19:36:07 +00:00
zhangwenjian
545453c93e
vue.go.template (F4) only had a flat fallback for an unconfigured colWidth: 110 for datetime, 120 for everything else. R2 asks for a precise per-type inference instead - varchar(n) tiered by n, tinyint(1) narrower than a general integer, text/blob wide - sized so a typical table's list columns land inside go-admin-ui's ~580px text-column budget. text/template cannot parse "varchar(255)" itself, so this has to run in gen.go before the template executes, not in the template. Judgment is columnType, not goType, same as F1/F2's earlier reversal (API契约.md §1.1): sys_tables.go:323-338 gives every non-primary-key int/tinyint/bigint/decimal column goType "string", so goType alone cannot tell a boolean flag from a bigint from a name column. InferColumnWidth(columnType string) int is exported and pure per 测试用例.md §2.5's own request, so it can be pinned with an exact input/output table rather than only asserting "the rendered page happens not to overflow" - see column_width_test.go, including the tinyint(1)-vs-tinyint(4) and the varchar tier-boundary cases. applyInferredColumnWidths only touches a column already at the 0 sentinel, wired into both Preview and NOActionsGen ahead of the template execute calls; a column already configured (by the user or F6) is left untouched, also pinned by a test. Verified against the real NOActionsGen call path (not just the unit test): generated a table mixing every branch (tinyint(1), datetime, decimal, varchar at three tiers, text, and one pre-configured column) and printed the resulting tab.Columns[i].ColWidth after generation - every value matched InferColumnWidth's own table, and the pre-configured column's 333 was left untouched.