Backend Overview

LaravelUi5 bridges two ecosystems — Laravel and OpenUI5 — by providing a consistent artifact model that spans both worlds. Each UI5 module you create has a backend representation (PHP) and a frontend counterpart (JavaScript). This duality is managed through unified conventions and a set of Artisan tools.

Module Creation Strategies

LaravelUi5 supports both quick-start scaffolding for demos and structured integration of real-world UI5 projects.

Quick Start Modules

Here’s the example the Getting Started guide walks through:

php artisan ui5:assemble launchpad-app

This command assembles a fully working example module under ui5/Showcase, including:

• composer.json with package metadata
• src/ShowcaseModule.php defining the backend module entry point
• src/ShowcaseApp.php defining the backend app entry point
• src/Dashboards/ and src/Groups/ holding a pre-wired "Sales Overview" dashboard
• resources/app/ containing a UI5 frontend app
• src/ShowcaseServiceProvider.php for the app's container bindings (the module itself is registered in config/ui5.php)

Add a data floorplan to that same app with php artisan ui5:wire User.

This entry point shows how easily a UI5 module can be wired into Laravel, without external setup.

It's ideal for:

• demos and onboarding
• simple internal tools
• prototyping and experimentation

⚠️ Note: These modules are not meant to replace full-fledged UI5 projects. If you need TypeScript, test tooling, or advanced deployment pipelines, we recommend developing your UI5 app separately and integrating it via ui5:app or ui5:lib.

Production-Ready Module Imports

The commands ui5:app and ui5:lib are designed to import artifacts from existing UI5 source projects into your Laravel environment. They assume:

• UI5 projects live outside the Laravel app (e.g. ../ui5-{domain}/)
• LaravelUi5 pulls in a specific version snapshot of the source
• Artifacts are placed under ui5/{Domain}/resources/ui5/
• Matching backend classes are generated automatically: the App or Library class, its Module, and for apps a Manifest and a ServiceProvider

This is the recommended approach for integrating production-grade UI5 apps or libraries.

Conventions

The following conventions define how imported UI5 modules are structured, named, and integrated within the Laravel app.

Structure Conventions

In LaravelUi5, each UI5 application or library corresponds to exactly one domain.

Put differently: one app equals one module equals one source project.

This strict one-to-one relationship ensures clean boundaries and predictable integration.

The domain name you choose — for example, Users or Timesheet — determines the identity and structure of the module on all levels.

• It defines the PHP namespace, which can be customized using the --php-ns-prefix option.
• It sets the target folder under ui5/ inside the Laravel app, where the imported artifact will reside.
• It helps locate the UI5 source project: with --js-ns-prefix, the generator also looks for ../{prefix}.{domain}/ (the Easy UI5 folder convention). The JavaScript namespace itself is always read from the source project.

This convention keeps both backend and frontend aligned, and ensures that all generated artifacts remain modular, versionable, and easy to reason about.

📝 Noteui5:app and ui5:lib never invent a JavaScript namespace. They read it from the source project (ui5.yaml, manifest.json, .library), whether you pass --create or --refresh; the --js-ns-prefix option only helps find the source folder. ui5:assemble takes no namespace options at all — the blueprint fixes the app as Showcase under com.example.showcase.

Filesystem Conventions

LaravelUi5 assumes a shared workspace where your Laravel app and all UI5 source projects live side by side:

your-workspace/
├── laravel-app/               ← The deployable Laravel project
├── ui5-core-lib/              ← Source project for a UI5 library
├── ui5-offers/                ← Source project for a UI5 application
└── com.acme.budget/      ← Folder structure as generated by Easy UI5

This layout is required and cannot be changed.

How It Works

• UI5 source projects (like ui5-offers) are developed outside the Laravel project.
• LaravelUi5 provides Artisan commands (ui5:app, ui5:lib) to import a snapshot of the UI5 artifacts into the Laravel app.
• Imported artifacts are placed inside

laravel-app/
└── ui5/
    └── Offers/
        └── resources/
            └── ui5/           ← Application or library source lives here

This makes UI5 artifacts available for:

• Runtime serving via Laravel routes.
• Integration with the registry and system config.
• Deployment and packaging.

🛠️ This approach gives you the best of both worlds: full freedom during UI5 development and full control during Laravel deployment.

Artifact Hierarchy

LaravelUi5 provides a structured artifact model inside the Laravel app, where UI5 components from external projects are registered, organized, and integrated.

Versioning itself happens in the UI5 source projects. LaravelUi5 pulls in specific versions as needed and exposes them as modular artifacts.

At the core of this model is a clear hierarchy with three layers: the roots that carry everything, the data seam an app exposes, and the visual artifacts it renders.

Roots

• Modules act as containers. They group related artifacts under a common domain but are not addressable on their own. They are also where #[Slot] declarations live.
• Libraries typically reflect a one-to-one copy of an external UI5 library project. They provide shared UI logic across modules or apps.
• Applications are the logical root for user-facing content, and the anchor point for the subordinate artifacts below — which derive their context from the app but can be composed and displayed independently.

The data seam

• The OData service is not a separate artifact: every application is an OData v4 service, because AbstractUi5App extends ODataService. It is the app's read surface, reachable at /odata/{namespace}@{version}/….
• Resources are read-only data endpoints for the shapes OData does not serve — a computed payload, a bespoke JSON document.
• Actions are the only write path. OData in LaravelUi5 is read-only, so every create, update, and delete is an Action: a backend-only operation defined in Laravel and callable from UI5 via LaravelUi5.call(...), independent of any visual component.

Visual artifacts

• Tiles, Cards, and Charts are the composable pieces — a single value, a content container, a plotted series.
• Dashboards bring those pieces together into a cohesive interface. A dashboard aggregates Dashboard Groups, each naming the children it renders; the composition is declared in PHP and served as a JSON control tree.
• Reports stand apart from that composition: a server-rendered HTML document, parameterised by slots and displayed in <lux:Report>.

This abstraction layer makes it easy to reason about complex UI5 landscapes while keeping everything modular and environment-aware.