feat(intent): document (header-items) layout + aggregate totals + kebab table-name fix - #6091
Merged
delchev merged 3 commits intoJun 27, 2026
Conversation
…ab table-name fix - IntentNaming.upperSnake now collapses non-alphanumeric separators (-, space, ., /) to a single underscore, so a kebab-case intent/project name yields a valid SQL identifier (sales-invoices -> SALES_INVOICES, not the invalid SALES-INVOICES that breaks table creation). Pure-identifier entity/field names are unaffected. - Document (header-items) layout: a master that owns a composition child whose name ends in "Item" (SalesInvoice -> SalesInvoiceItem) is emitted with layoutType MANAGE_DOCUMENT + documentItemsEntity, so it renders as a document (header form, inline items table, totals footer) instead of the default master-detail. The items child stays a DEPENDENT detail. generateUtils gains a uiDocumentModels collection. - New field attribute `aggregate: true` -> emits an "aggregate" render hint so a (typically calculated) total shows in the document's totals footer, not the header form. Presentational only. - Billing sample: SalesInvoice totals marked aggregate. Tests cover the document layout, documentItemsEntity, and the aggregate hint. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The document (header-items) view templates and the kebab-fix unit test that were not captured by the earlier diff: document.js manifest, document-page.js + document-view templates, and IntentNamingTest (3 cases). NOTE: document.js is not yet imported in template/ui/template.js and index.html.template has no MANAGE_DOCUMENT route branch, so the document UI does not generate yet - wiring is the remaining step. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…es' into feat/intent-document-layout # Conflicts: # components/engine/engine-intent/src/main/java/org/eclipse/dirigible/components/intent/generator/edm/EdmIntentGenerator.java
delchev
added a commit
that referenced
this pull request
Jun 27, 2026
…attributes (#6089) * feat(intent): cross-model entity references, n:m, and faithful field attributes Lets a multi-project app (e.g. Billing: uoms, countries, currencies, customers, customer-payments, sales-invoices) be authored as separate .intent models that reference each other cross-model, reusing the proven PROJECTION mechanism. Tranche A - cross-model references: - New top-level `uses:` block (UsesIntent) + optional `model:` on a relation. - Parser allows a to-one relation to target an entity in a declared uses model (forbids cross-model composition; rejects undeclared models). - EdmIntentGenerator emits a PROJECTION entity per cross-model target (owner table + PK resolved from the owner .model when present, else by convention) plus an integer FK + dropdown; projections carry no perspective so they stay out of the consuming app's nav. No template changes (existing parameterUtils / generateUtils / schema template already handle PROJECTION). - workspaceName plumbed through endpoint -> service -> context for the projectionReferencedModel path. Tranche B - n:m via an explicit intermediate entity (composition to one side, cross-model manyToOne to the other, plus bridge fields like Amount). Reuses the composition + cross-model paths; no extra generator logic. Tranche C - faithful field attributes: FieldIntent unique / precision / scale / calculatedOnCreate / calculatedOnUpdate, and entity-level `audit: true` (emits the four standard audit columns). EdmIntentGenerator emits dataUnique, precision/scale, isCalculatedProperty + calculatedPropertyExpression*, and auditType. Includes the 6 Billing example .intent files (test resources), parser + EDM generator unit tests (21 pass), and intent-assistant-guide.md docs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * feat(intent): contribute generated apps to one shared shell, grouped (#6090) Multi-project intent apps generated a standalone Harmonia shell each, forcing the user to jump between per-domain UIs. This makes each project ALSO contribute its entities as perspectives to the platform's shared application shell, grouped, so they appear as one app. The standalone per-project shell is unchanged (still ideal for an all-in-one model and for testing a domain in isolation). - New entity-level `group:` (EntityIntent.group); EdmIntentGenerator sets the perspective's groupId (perspectiveNavId) from it. - Harmonia template emits a per-entity perspective .js + .extension registered to `application-perspectives` (namespaced id, groupId, path = this project's own SPA route in embedded mode), across the list/manage/master/setting collections. - Harmonia shell gains an embedded (chromeless) mode: when loaded with ?embedded (how the shared shell hosts a perspective) it hides its own sidebar so the shared shell provides the single chrome. Standalone mode unaffected. - Navigation groups are defined once (a dedicated navigation-groups project that exports getPerspectiveGroup per id); entities only reference the id - avoids the shell's duplicate-group-id drop. - Billing example models tagged with groups (master-data / sales / payments / settings); guide documents `group:`. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> * feat(intent): document (header-items) layout + aggregate totals + kebab table-name fix (#6091) * feat(intent): document (header-items) layout + aggregate totals + kebab table-name fix - IntentNaming.upperSnake now collapses non-alphanumeric separators (-, space, ., /) to a single underscore, so a kebab-case intent/project name yields a valid SQL identifier (sales-invoices -> SALES_INVOICES, not the invalid SALES-INVOICES that breaks table creation). Pure-identifier entity/field names are unaffected. - Document (header-items) layout: a master that owns a composition child whose name ends in "Item" (SalesInvoice -> SalesInvoiceItem) is emitted with layoutType MANAGE_DOCUMENT + documentItemsEntity, so it renders as a document (header form, inline items table, totals footer) instead of the default master-detail. The items child stays a DEPENDENT detail. generateUtils gains a uiDocumentModels collection. - New field attribute `aggregate: true` -> emits an "aggregate" render hint so a (typically calculated) total shows in the document's totals footer, not the header form. Presentational only. - Billing sample: SalesInvoice totals marked aggregate. Tests cover the document layout, documentItemsEntity, and the aggregate hint. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * Add document-layout UI templates + IntentNaming test The document (header-items) view templates and the kebab-fix unit test that were not captured by the earlier diff: document.js manifest, document-page.js + document-view templates, and IntentNamingTest (3 cases). NOTE: document.js is not yet imported in template/ui/template.js and index.html.template has no MANAGE_DOCUMENT route branch, so the document UI does not generate yet - wiring is the remaining step. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #6089 (
feat/intent-cross-model-references) - base is that branch, so the diff here is only the document-layout work.Changes
IntentNaming.upperSnake): collapse any run of non-alphanumeric separators (-, space,.,/) to a single underscore so a kebab-case intent/project name produces a valid SQL identifier -sales-invoices→SALES_INVOICES, not the invalidSALES-INVOICES(an unquoted-breaks table creation). Pure-identifier entity/field names are unaffected. This is needed by the hyphenated sample model names.Item(e.g.SalesInvoice→SalesInvoiceItem) is emitted withlayoutType: MANAGE_DOCUMENT+documentItemsEntity, so it renders as a document - header form, inline items table, totals footer - instead of the default master-detail. The items child stays aDEPENDENTdetail.generateUtilsgains auiDocumentModelscollection.aggregate: truefield attribute: emits anaggregaterender hint so a (typically calculated) total appears in the document's totals footer rather than the header form. Presentational only.SalesInvoicetotals (net/vat/gross/discount/total/paid) markedaggregate: true.Verification
mvn -pl components/engine/engine-intent test(21 pass), incl. new assertions thatSalesInvoicegetsMANAGE_DOCUMENT+documentItemsEntity: SalesInvoiceItem, that aggregate fields carry the hint, and that the items child staysMANAGE_DETAILS.Note / follow-up
The Harmonia template does not yet have a generator bound to the new
uiDocumentModelscollection, so aMANAGE_DOCUMENTmaster currently produces no UI from the Harmonia recipe (it's excluded from theMANAGE/MANAGE_MASTERcollections). The document view template is the remaining piece. This also interacts with the shared-shell PR (#6090), which keys perspectives off the manage/master collections - aMANAGE_DOCUMENTentity would need adding there too.🤖 Generated with Claude Code