VDM Joomla Component BuilderArchitecture / 1.0.0
Read the white paper
Read MarkdownDownload MarkdownSource

Service Directory and the wider definition ecosystem

Hello World isolates a few mechanisms so their traces are easy to follow. The Service Directory supplies a larger application context: many fields and views, custom code, reusable layouts and templates, query definitions, placeholders, validation rules, and extension relationships.

The application has its own authorship. Its blueprint and generated README identify Lemuel van der Merwe as the application author. This white paper's authorship and JCB's architecture belong to Llewellyn van der Merwe; generating another author's application does not transfer that application's authorship. E05

Two versioned component identities in the blueprint repository#

The pinned Joomla packages repository contains two Service Directory component roots:

Component identity Recorded component version Namespace prefix
160d0efb-6bf0-48eb-8d46-55cf74729501 6.0.3 JoomService
35a38329-d1e9-43df-a8f8-af1b8e6d8bd9 5.0.3 JoomService

They are separate root records. The counts of the entire repository must not be presented as the private dependency closure of only one of them.

Each root references component admin/site associations, updates, menus, router and configuration records, files/folders, plugin relationships, reusable custom-code aliases, and assets. The versioned generated Service Directory repository shows the native application product of this family.

The repository exposes several layers of reuse#

Across the inspected package snapshot, the root payload catalogue contains 133 fields, 25 admin views, 20 layouts, 13 Dynamic Gets, seven site views, seven templates, 25 custom-code records, ten placeholders, and additional validation, class, plugin, and component definitions.

Those counts identify available definitions, not generated file cardinalities. A layout can be called from several contexts. A field can appear in several associations. A Dynamic Get can serve a particular result role. The compiler expands those uses according to the selected component graph and target, rather than emitting one file for every catalogue item.

The generated application includes its administrator and site structure, forms, SQL, runtime classes, language material, assets, and reusable code. The same intermediate-store and contextual-generation mechanisms examined in Hello World operate over a broader set of interactions here.

Application blueprints are only one distribution channel#

The wider repositories demonstrate distinct categories of reusable input:

Repository Architectural role
joomengine/packages Component blueprints and their dependency graphs
joomengine/super-powers Managed reusable code definitions
joomengine/joomla-powers Target-sensitive Joomla namespace/type mappings
joomengine/joomla-fieldtypes Reusable field-type definitions
joomengine/snippets Reusable interface and presentation material
joomengine/repoindex Repository-target definitions for discovery and publication
joomengine/jcb-documentation Operational explanations of authoring, reuse, compilation, and maintenance

The source map pins each examined repository. They are not interchangeable bags of source files: their indexes, payload types, acquisition handlers, and compiler consumers differ.

What this adds to the architectural account#

The ecosystem shows the same identity and transport principles operating at several levels. A project can import an application design, acquire a missing field type, resolve a code definition, select a target-specific platform mapping, and emit complete extension artifacts. Each operation has a defined representation boundary, yet the results can join one compiler execution.

This is the important composition. The repository channels do not replace the compiler; they make its required definitions available. The compiler does not replace authoring; it interprets represented choices and authored code. Generated products do not replace blueprints as the editable source of intent; they are the target implementation.

Scope of the comparison#

The two package roots and the generated repository are related public artifacts, but their version labels and snapshots are not asserted to be a byte-matched export/build certificate. A precise runtime reproduction selects one root, fixes the compiler and all dependencies, and compares the resulting artifact set under a declared equivalence.

That distinction leaves the evidence intact. The repositories directly show the represented definitions and the generated application structures. The compiler source explains the operations connecting those representation families. The verification chapter describes how to add a controlled fresh-build record without rewriting the architectural account.

The larger example therefore complements, rather than replaces, the small trace: Hello World makes individual correspondences easy to inspect; Service Directory demonstrates the breadth of design information coordinated through the same architecture.

Article basisPinned Service Directory, package, Power, field-type, snippet, and repository-index sourcesEdition and sources
Publication contents
Download all Markdown

Search article titles and the complete text.