Skip to content

feat(harmonia): unify page/record title styling across all generated views + shell - #6361

Merged
delchev merged 1 commit into
masterfrom
feat/harmonia-unified-titles
Jul 21, 2026
Merged

feat(harmonia): unify page/record title styling across all generated views + shell#6361
delchev merged 1 commit into
masterfrom
feat/harmonia-unified-titles

Conversation

@delchev

@delchev delchev commented Jul 21, 2026

Copy link
Copy Markdown
Contributor

Unifies every page/record title in the generated Harmonia UI (and the built-in shell sections) to one caption style: text-2xl font-semibold tracking-tight.

Changes

  • Record captions — the document header, the manage create/edit form caption, and the form-builder title were an uppercased font-normal label. They're now semibold and not uppercased ("Sales Invoice", not "SALES INVOICE"). The document number keeps font-bold so it stays heavier than the caption → "Sales Invoice SI-0000001".
  • Browse titles — list, manage-list, master-detail, report (chart/table), and report-file. x-h-toolbar-title is kept (truncation in the toolbar) with the caption classes added.
  • Built-in shell — the Inbox title adopts the caption style; Documents gains a "Documents" caption alongside its path breadcrumb (whose root is "Home"). These live in the shared application-core shell.

Secondary headers are left as-is by design: the master-detail Entity #id sub-panel titles, the document items-panel header, and the card ("Details") / dialog titles.

Verification (live)

Rebuilt the jar and regenerated kf-mod-sales-invoices: the browse list, the document caption + bold number, and the shared Inbox/Documents shell all render the unified caption. No Java touched (template + shell HTML only).

Follow-up to the merged #6355 (which humanized the labels + task-form Details layout).

🤖 Generated with Claude Code

…views + shell

Every page title now uses one caption style - text-2xl font-semibold tracking-tight:

- Record captions (document header, manage create/edit form, form-builder title):
  were an uppercased font-normal label; now semibold and NOT uppercased ('Sales
  Invoice', not 'SALES INVOICE'). The document number keeps font-bold so it stays
  heavier than the caption ('Sales Invoice SI-0000001').
- Browse titles (list, manage list, master-detail, report chart/table, report-file):
  x-h-toolbar-title kept (truncation) with the caption classes added.
- Built-in shell sections: the Inbox title adopts the caption style, and Documents
  gains a 'Documents' caption alongside its path breadcrumb (root = Home).

Secondary headers left as-is by design: the master-detail 'Entity #id' sub-panel
titles, the document items-panel header, card ('Details') and dialog titles.

Verified live: regenerated kf-mod-sales-invoices - the list, document caption/number,
and the shared Inbox/Documents shell all render the unified caption.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@delchev
delchev merged commit 8ed68db into master Jul 21, 2026
10 checks passed
@delchev
delchev deleted the feat/harmonia-unified-titles branch July 21, 2026 20:27
delchev added a commit that referenced this pull request Jul 22, 2026
…6372)

#6361 unified the form caption to the document-title style and dropped the
force-uppercase (.toUpperCase()), matching the non-uppercased document
layout - but this UI assertion still expected the old all-caps 'ORDERS' and
was left red on master. Assert the resolved human label 'Orders' instead;
the test's intent (the generator derives a real label, not the raw
${ENTITYLABEL} placeholder) is unchanged. Only source assertion affected.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
delchev added a commit that referenced this pull request Jul 22, 2026
…re (#6388)

The test asserted exactly one <span> containing 'Orders' as the create-form
caption. Since the fixture entity is named 'Orders', its derived entityLabel
(the form caption) equals its menuLabel (the list toolbar title), and #6361
unified both to caption <span>s - so the label legitimately renders in two
places and the ExistsByTypeAndContainsText finder (which rejects >1 match)
fails with 'Found [2] ... expected at most one'. (#6372 surfaced it by
lowercasing the form caption to match the list title's 'Orders'.)

The assertion's real intent is that the generator DERIVED the label rather
than leaking the literal ${ENTITYLABEL}; assert that placeholder is ABSENT
instead - count-immune, and the form rendering + label resolution stay proven
by the Country/City depends-on assertions that follow.

Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant