# Joomla Component Builder: Contextual Compilation Architecture

Author: Llewellyn van der Merwe
Edition: 1.0.0 (2026-09-16)
Source revision: 7ac0ba83361e4b1d5181d2a441989ab17d50d63f
License: CC BY 4.0

This complete edition is assembled from the individual Markdown articles.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/index.md

# Joomla Component Builder Architecture

**Contextual compilation from structured intent to complete applications**  
**Llewellyn van der Merwe · Technical white paper · Edition 1.0.0**

A field called *Greeting* appears to be a small definition: a type, a name, a label, and a few settings. In a generated application, that definition participates in a database column, an editor, a list query, sorting, searching, language entries, and a machine-readable table description. Its use in a view adds further decisions: whether it is the title, where it appears, and which interactions it supports. Those consequences must agree without being specified independently in every destination.

Joomla Component Builder coordinates that work through a compiler. It retrieves definitions and their dependencies, interprets each use in context, distributes the results into specialised intermediate stores, retains work that must wait for other information, and binds completed material into native components, modules, and plugins. This publication explains that architecture at the level of its operations, mathematical structure, and observable products.

## Follow one definition through the system

The [Hello World example](https://architecture.joomlacomponentbuilder.com/markdown/examples/hello-world.md) connects a public blueprint repository to three generated extension repositories. The [Greeting field trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/field-trace.md) follows a stable field identifier into its form, database schema, language keys, list behaviour, and generated metadata. The [custom-code trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/custom-code-trace.md) follows deliberate markers from GUI-backed blueprint properties into their target methods and files.

These examples provide a concrete entry into the deeper account. A reusable definition is one object; its uses, accumulated consequences, and output locations are different objects. The architecture makes those distinctions operational.

```mermaid
flowchart TD
  A["Structured intent in the editor"] --> B["Local definitions and relationships"]
  R["Versioned blueprint repositories"] -->|discover and import| B
  B -->|export| R
  X["Existing installed extension"] -->|extrude represented structure| B
  B --> C["Resolve, classify, and retain context"]
  C --> D["Complete deferred work and bind in stages"]
  D --> E["Native component, module, and plugin products"]
  E -->|recover designated edits| B
```

The repository exchange, installed-extension extrusion, and marked-edit recovery paths perform different transformations. The compiler connects them by consuming the resulting definitions through the same generation machinery. [Lifecycle](https://architecture.joomlacomponentbuilder.com/markdown/foundations/lifecycle.md)

## Read the integrated argument

The [white paper](https://architecture.joomlacomponentbuilder.com/markdown/white-paper.md) presents the complete argument in one continuous article. The [reading guide](https://architecture.joomlacomponentbuilder.com/markdown/reading-guide.md) offers shorter routes through the same material.

The detailed chapters explain the [blueprint representation](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/representation.md), [local-first discovery](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/discovery.md), [compiler execution](https://architecture.joomlacomponentbuilder.com/markdown/compiler/execution.md), [semantic classification](https://architecture.joomlacomponentbuilder.com/markdown/compiler/classification.md), [intermediate stores](https://architecture.joomlacomponentbuilder.com/markdown/compiler/stores.md), [deferred work](https://architecture.joomlacomponentbuilder.com/markdown/compiler/deferred-work.md), and [binding stages](https://architecture.joomlacomponentbuilder.com/markdown/compiler/binding.md). Application-generation chapters follow those mechanisms into schemas, queries, interfaces, permissions, languages, routing, and packaging.

The [formal model](https://architecture.joomlacomponentbuilder.com/markdown/formal/notation.md) expresses identities, state transitions, dependency traversal, contextual interpretation, and staged substitution without depending on PHP syntax. The [implementation guide](https://architecture.joomlacomponentbuilder.com/markdown/engineering/implementation.md) shows how those operations can be represented in another language. The [source map](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md) reconnects the abstraction to the implementation.

## A development lifecycle, not a one-time scaffold

Blueprints can be exported, reviewed in Git, imported into another JCB instance, and compiled again. Existing extensions can supply recoverable structure through [extrusion](https://architecture.joomlacomponentbuilder.com/markdown/extrusion/overview.md). Reusable library definitions can be acquired when needed and placed according to their resolved namespaces. Compiler and target-rule changes can then be applied through [regeneration](https://architecture.joomlacomponentbuilder.com/markdown/engineering/regeneration.md), rather than repeated separately across every application.

JCB's own generated application is part of this account. [Self-generation and maintenance](https://architecture.joomlacomponentbuilder.com/markdown/engineering/regeneration.md) explains the relationship between its blueprint, reusable library inputs, compiler, and generated application layers. [Build measurements](https://architecture.joomlacomponentbuilder.com/markdown/engineering/performance.md) distinguish blueprint size, supplied reusable code, output size, and elapsed compilation time.

**The subject is how these operations fit together.** The implementation gives the account its substance; the abstraction makes the approach available for examination and reuse beyond Joomla.

Every article has an exact Markdown equivalent. Authorship, source revisions, implementation coverage, and publication conventions are recorded in the [edition](https://architecture.joomlacomponentbuilder.com/markdown/reference/edition.md) and [citation](https://architecture.joomlacomponentbuilder.com/markdown/reference/citation.md) pages.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/white-paper.md

# Joomla Component Builder: Contextual Compilation Architecture

**Structured intent, portable definitions, and coordinated application generation**  
**Llewellyn van der Merwe · Vast Development Method**  
Technical white paper · Edition 1.0.0 · 16 September 2026

## Abstract

Joomla Component Builder transforms a structured application model into complete native components, modules, and plugins. Its compiler coordinates information that becomes available at different times and contributes to different output concerns. Reusable definitions are acquired by identity, interpreted in their occurrence contexts, and distributed into specialized intermediate stores. Deferred operations retain work until its prerequisites are established. Ordered binding and code injection then complete staged artifacts under target-specific conventions.

This paper describes that implemented architecture and expresses its operations in language-neutral terms. The account connects GUI-authored intent, database definitions, repository blueprints, local-first dependency discovery, contextual compilation, installed-component extrusion, designated-code recovery, and regeneration. A public Hello World blueprint and its three generated products provide inspectable traces. A field's properties and association roles are followed into its database schema, form, list behavior, language entries, and generated metadata; marked code is followed from its source property to its generated location.

The formal treatment distinguishes definitions, occurrences, contributions, and artifacts; models ordered effects; establishes finite guarded traversal under stated conditions; specifies exact binding semantics; and defines the equivalences relevant to blueprint transport and reconstruction. These abstractions make the design available for examination and implementation outside Joomla without discarding the behaviors that make its coordination work.

## 1. The problem is coordinated detail

A field called *Greeting* can be described with a type, name, label, database properties, and a few interface settings. Its use in a view adds decisions such as title status, list visibility, search, sorting, and placement. A working application needs the consequences of those decisions in several places: schema, queries, forms, model methods, language catalogues, list headers, metadata, and sometimes permission-sensitive data paths.

The difficulty is not producing one form element. It is keeping the related implementations consistent while definitions are reused, contexts change, dependencies are discovered, and different output stages execute. A developer should not have to repeat one decision independently in every destination or manually reconstruct the relationship between its effects after a platform change.

I developed JCB to make that recurring work explicit and reusable. The original implementation grew from solving the application-building problem directly. Its responsibilities were subsequently separated into specialized services while preserving the coordinated flow of definitions, intermediate results, and generated products. The public source lineage begins on 30 January 2016; this edition gives the implemented architecture a systematic account. [Development and provenance](https://architecture.joomlacomponentbuilder.com/markdown/foundations/provenance.md)

The core subject is **contextual compilation**: reuse identified design knowledge, interpret each use under its actual context, retain its different consequences, and complete each output operation at the point its required information is available. Export, import, extrusion, and recovery connect that compiler to a continuing development lifecycle. [C01–C07](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c01)

## 2. Structured intent is an executable design description

JCB's GUI represents application intent through typed choices and relationships. Field types describe reusable kinds of controls; fields configure them; view associations establish their roles; views define data retrieval and presentation; components select those views and associated extensions. Authored code occupies designated roles where application-specific behavior is needed.

The GUI is an authoring surface, not the semantic definition of compilation. The same represented intent can enter through a repository blueprint or recovered model. The database stores a local editable form of it. Normalization and interpretation connect that form to the compiler's rules. [Structured intent](https://architecture.joomlacomponentbuilder.com/markdown/foundations/structured-intent.md)

Let an authoring input $u$ be normalized into design $D=N(u)$. For concern $k$ and target $T$, the compiler computes a projection

$$
P_{k,T}(D,\Gamma),
$$

where $\Gamma$ supplies the relevant occurrence context. The result can be structured data, code, a requirement, or no contribution when the selected feature is inactive. A searchable flag, for example, requests known search behavior; the compiler supplies its implementation conventions rather than inferring an unstated business rule from the field's label.

A compact blueprint is effective because reusable knowledge also resides in the compiler, templates, target rules, Powers, and supplied libraries. Generated size therefore measures the materialized combination of design and reusable implementation knowledge, not information produced from the blueprint alone.

## 3. Four objects must remain distinct

A **definition** is reusable knowledge. An **occurrence** is its use under an association and context. A **contribution** is a result retained for a particular generation concern. An **artifact** is a staged or completed output.

A portable identity is a typed request

$$
u=(t,k,v),
$$

where $t$ is the entity type, $k$ its identifying field, and $v$ its normalized value. Many entities use GUIDs; custom code can use a function-name alias; owned children can use a parent relationship key. A local database primary key is a realization of that identity, not necessarily its portable value.

An occurrence can be represented as

$$
o=(u,p,a),
$$

with use position $p$ and association settings $a$. Its context includes target, extension, view or use-site, generation role, language destination, active bindings, and additional settings. JCB carries these dimensions through records, service arguments, configuration, and scoped store keys. The mathematical tuple describes the role without requiring a matching allocated object. [Identity](https://architecture.joomlacomponentbuilder.com/markdown/foundations/identity.md), [context](https://architecture.joomlacomponentbuilder.com/markdown/foundations/context.md)

Interpretation produces an ordered contribution sequence:

$$
J(d,\Gamma)=\langle c_1,\ldots,c_m\rangle,
\qquad c_i=(s_i,k_i,\omega_i,v_i).
$$

Each contribution identifies a store, key, update operation, and value. A title binding can be set; a searchable field can be appended; a language key can be filled; a code fragment can be concatenated; an operation can be deferred. These are different updates, even where the physical stores use similar registry machinery.

The output relation is many-to-many. One field can affect several files; one model file can combine many fields, joins, policies, and custom fragments. Counting definitions, occurrences, contributions, and artifacts as if they were the same objects would hide the architecture's actual expansion.

## 4. Portable blueprints form a discoverable graph

A blueprint repository contains authoritative payloads and supporting distribution material. Payloads carry design properties, code, associations, and dependency descriptors. Indexes locate those payloads. Generated Markdown describes them. Assets supply referenced content. The entire repository is not counted as if every README paragraph were another compiler input decision. [Blueprint representation](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/representation.md)

Export selects a root and traverses its supported relationships. Type-specific configuration determines identifying fields, portable properties, child records, encoding, indexes, and asset targets. Installation-specific fields can be omitted. The writer then creates or updates payloads, readable item descriptions, and merged indexes in eligible repositories. Writes have per-item and per-repository outcomes rather than an assumed global transaction. [Export](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/export.md)

Import follows the opposite representation boundary. Ordinary initialization first preserves an acceptable local definition. Where missing, it selects an applicable configured repository entry, retrieves and maps its payload, persists it locally, and follows discovered dependencies. Reset is an explicit refresh operation. Incoming owned child records and outgoing reusable references can follow different recursive reset policies. [Import and reset](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/import.md)

The inspected entity catalogue contains 45 canonical types: components and their associations, modules, plugins and class-related definitions, admin and site views, fields, field types, validation rules, layouts, templates, Dynamic Gets, custom code, libraries, placeholders, Powers, repositories, and snippets. File/folder content has separate handlers. This common acquisition structure is broader than Power retrieval alone. [Entity catalogue](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/discovery.md), [B01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b01)

“Global” discovery is bounded by the configured sources. Their order, branches, channels, and indexes determine selection. The inspected lookup selects an index match before fetching its payload; a failed selected payload does not automatically imply that every later repository will be tried. Once accepted, the definition becomes local editable knowledge, not transient text available only to one template.

## 5. Dependency completion is controlled discovery

Resolving one request can reveal others. A component points to view associations; an association points to a view; the view points to fields; fields point to types and rules. Recognized code references, nested subforms, templates, layouts, and assets add further edges.

Let $R_0$ be root requests and $\operatorname{deps}(u)$ the relation extracted by the supported resolver. The reachable set satisfies

$$
R_{i+1}=R_i\cup\bigcup_{u\in R_i}\operatorname{deps}(u).
$$

For a finite reachable universe, this reaches the least dependency-closed set containing the roots. The production traversal uses nested handlers and queue drains. It retains attempted-request state so a shared or cyclic dependency does not cause endless reacquisition. [Dependency traversal](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/dependencies.md)

A small operational form is:

```text
pending := normalized roots
attempted := empty
while pending is not empty:
    request := remove the next request
    if request has not been attempted:
        mark it before recursive work can re-enter it
        acquire it under the selected local/repository policy
        record the actual outcome
        enqueue supported dependencies exposed by the result
transport accumulated file and folder requirements
```

If each handler completes and each first visit enqueues finitely many members of a finite universe $U$, the lexicographic measure

$$
(|U\setminus\mathrm{attempted}|,|\mathrm{pending}|)
$$

decreases: a first visit decreases its first component; a duplicate removal decreases the second. Cycles are compatible with termination. Successful completeness remains a separate condition: an attempted missing definition is not a resolved one, and local-preservation paths rely on their required dependencies already being available or discovered elsewhere. [Formal resolution](https://architecture.joomlacomponentbuilder.com/markdown/formal/resolution.md)

This closure describes acquisition, not every operation in the compiler. Later semantic processing includes replacement, removal, code effects, and context changes that should not be recast as one monotone fact-accumulation algorithm.

## 6. Compilation begins before the final run method

The complete execution includes service resolution and constructor work. The compiler starts timing, initializes its working state, and invokes content preparation before its final orchestration method runs. The initializer recovers designated edits from installed targets before rebuilding the component and resetting the working output. It then establishes component data, version settings, utility dependencies, and structures. [Execution](https://architecture.joomlacomponentbuilder.com/markdown/compiler/execution.md), [C01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c01)

Acquisition enriches raw records into compiler-ready data. Field loading connects ID and GUID forms, obtains type properties, processes XML and validation, and handles selected storage and history information. Returning cached field data can also invoke per-view custom-code processing. The base definition and its use-specific effects therefore have different reuse boundaries. [Acquisition](https://architecture.joomlacomponentbuilder.com/markdown/compiler/acquisition.md)

Physical structure can be created while later semantic work remains. Additional dependencies can appear during code expansion and final injection. The architecture's requirement is that an operation has the information it needs when it consumes it—not that one universal loading pass must finish before any file can exist.

```mermaid
flowchart TD
  A["Build request and target configuration"] --> B["Recover edits and acquire definitions"]
  B --> C["Prepare structures and shared bindings"]
  C --> D["Interpret occurrences and collect contributions"]
  D --> E["Complete deferred operations"]
  E --> F["Bind staged artifacts and resolve code references"]
  F --> G["Languages, metadata, repositories, and archives"]
  G --> H["Native products and diagnostic report"]
```

The arrows summarize the main responsibilities. Event handlers, nested acquisition, and extension-specific generation operate at their documented points within that order.

## 7. The central mechanism is semantic classification

A field's interpretation contributes to schema, keys, list membership, joins, title and alias roles, storage transformations, scripts, search, sorting, filtering, layout, language, and generated field metadata. Some branches are inactive for a particular field. Others depend on its view association rather than its reusable definition alone. [Classification](https://architecture.joomlacomponentbuilder.com/markdown/compiler/classification.md), [C05](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c05)

The Hello World Greeting field makes the process concrete. Its reusable definition selects a text field, the name `greeting`, label `Greeting`, database type `VARCHAR(255)`, nullable storage, and explicit-index value zero. Its form properties include maximum input length 50 and default text `Some text`. Its admin-view association marks it as the title, searchable, sortable, linked, and first in the selected list/edit positions.

The generated component contains the column, form field, qualified language key, list sorting, and a Table metadata entry carrying the same GUID. It also contains an ordinary index on `greeting` even though the explicit-index property is zero. The compiler derives that index from the field's title role under the applicable non-text branch. [Greeting trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/field-trace.md)

That result is not unexplained template inflation. The definition, occurrence, and rule together determine it. The schema emitter and metadata emitter consume the same interpreted key requirement, so the SQL and model metadata agree.

Fan-out and fan-in are both essential. One occurrence distributes several consequences. Later, a query combines selections, aliases, joins, filters, ordering, and custom code; a form combines field definitions, placement, conditions, policy, and labels. Intermediate stores connect these producers and consumers without forcing each emitter to rediscover the model independently.

## 8. Retained state has types, scope, and lifetime

JCB uses several kinds of retained information: acquired definitions; concern-specific builders; prepared code in dispensers; shared and contextual binding maps; deferred operations; and guards against repeated work. Their physical similarity does not make their contracts identical. [Intermediate stores](https://architecture.joomlacomponentbuilder.com/markdown/compiler/stores.md)

A store is modeled as a partial map $M_s:K_s\rightharpoonup V_s$. Its key can be a definition identity, view name, extension key, field name, or combined address. Its update can set, fill, append, concatenate, or remove. The current filename binding intentionally changes between files. A per-view script guard has a different lifetime from a portable field GUID.

Safe reuse depends on the inputs actually read by an interpretation. If deterministic $J$ depends on definition version $d$, context projection $\pi_J(\Gamma)$, and dependency observation $z$, a sufficient key is

$$
\kappa_J=(\operatorname{id}(d),\operatorname{version}(d),\pi_J(\Gamma),z).
$$

Equal keys then identify equal relevant inputs and equal results. Omitting a language prefix or target dimension is valid only where the interpretation does not depend on it. Repeating a cached effect is another question: concatenating the same script twice still duplicates it, so either idempotence or a correctly scoped contribution guard is required. [Contribution algebra](https://architecture.joomlacomponentbuilder.com/markdown/formal/classification.md)

These distinctions explain the useful “remember now, use later” behavior without a biological-memory claim. The compiler retains an identified representation and recalls or completes it at the consumer that has the required context.

## 9. Deferred work preserves a discovered obligation

Linked-view work can be recognized before the information needed to finish it is ready. The compiler records the operation and its arguments, completes the earlier admin and component work, and then replays the retained operations. Configuration fieldsets similarly have an explicit second pass after earlier contributions are available. [Deferred work](https://architecture.joomlacomponentbuilder.com/markdown/compiler/deferred-work.md), [C07](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c07)

For deferred work $w$, the semantic readiness condition is

$$
\operatorname{req}(w)\subseteq\operatorname{avail}(\Sigma).
$$

The production sequence establishes this through designated phases. It need not encode a machine-readable prerequisite set on every entry or run a generic scheduler. What matters is the producer–consumer ordering and retention of the required information.

Deferred execution, lazy acquisition, and late binding remain distinct. The first retains an operation, the second obtains a definition when needed, and the third supplies values in an appropriate output context. The compiler combines all three, but a single word such as *recursion* would not explain their different responsibilities.

A fixed ordered sequence can be repeatable even where reordering its operations changes the result. Confluence is stronger than determinism. The formal model therefore preserves the source's order rather than demanding that every pair of updates commute. [Staging](https://architecture.joomlacomponentbuilder.com/markdown/formal/staging.md)

## 10. Binding completes text in its destination context

Shared bindings carry component-wide values and fragments. Contextual bindings carry view- or extension-specific material. Prepared custom code can remain parameterized until retrieval from the dispenser applies the current placeholders. Per-file processing supplies another ordered sequence of shared binding, contextual binding, selected code expansion, events, and Power injection. [Binding](https://architecture.joomlacomponentbuilder.com/markdown/compiler/binding.md)

Within a pass, JCB uses ordered replacement. For $P=\langle(k_1,v_1),\ldots,(k_n,v_n)\rangle$,

$$
s_0=s,\qquad s_i=\operatorname{replaceAll}(s_{i-1},k_i,v_i).
$$

Later entries can process text introduced by earlier ones. The filtered action first removes map entries absent from the original input and then performs those ordered replacements. For `A → B`, `B → x`, ordinary replacement of `A` produces `x`, while filtered replacement produces `B`. For original input `A B`, both entries survive filtering and the result is `x x`.

The exact distinction matters to another implementation. Simultaneous substitution or indefinite recursive expansion would be different semantics. The [executable companion](https://architecture.joomlacomponentbuilder.com/markdown/engineering/reference-model.md) tests the introduced-token cases directly.

Multiple stages let a prepared fragment acquire its destination's name, namespace, language key, or role. They also establish an ordering obligation: a token introduced by one stage needs an applicable consumer after that stage if it is intended to be resolved during the build. The operation that owns that completion must be identifiable.

## 11. Managed code joins identity to placement

A Power reference identifies a reusable code definition without requiring the author to fix every file-local alias and output path at the reference site. The loader obtains the definition locally or through configured repository acquisition, prepares its relationships, and guards recursive loading. Injection resolves the qualified name, existing imports, short-name collisions, and required import statements in the destination file. [Powers](https://architecture.joomlacomponentbuilder.com/markdown/compiler/powers.md)

The three identities are different: portable Power identity, target-qualified class name, and file-local symbol. Namespace and placement settings also determine whether code belongs in a reusable library location or an extension source role. A complete-class override is a deliberate ownership choice distinct from inserting a method fragment into a generated class.

Joomla Powers add target-sensitive platform mappings. The same logical platform reference can select a namespace and type appropriate to the compile target. Architecture services separately select target-specific controller, model, view, module, plugin, and other emitter implementations. The host running JCB and the platform targeted by the output are not collapsed into one version variable. [Target selection](https://architecture.joomlacomponentbuilder.com/markdown/compiler/targets.md)

Custom code also includes GUI-linked regions, reusable aliases, and explicitly accepted external resources. Preparation can expand those references and discover more Powers or language entries. The code is part of the compiler's information flow, not simply pasted into an arbitrary file after generation has finished. [Custom code](https://architecture.joomlacomponentbuilder.com/markdown/compiler/custom-code.md)

## 12. Generation coordinates complete application concerns

Schema generation retains normalized types, defaults, nullability, keys, storage treatment, and history-derived update information. Query generation retains source/result aliases, joins, predicates, result roles, and runtime filter structure. Form and layout generation combines field properties, occurrence order, tabs, conditions, validation, and nested presentation dependencies. Each uses decisions established elsewhere in the build. [Schemas](https://architecture.joomlacomponentbuilder.com/markdown/generation/schema.md), [queries](https://architecture.joomlacomponentbuilder.com/markdown/generation/queries.md), [forms](https://architecture.joomlacomponentbuilder.com/markdown/generation/forms-layouts.md)

Permissions show why those interactions matter. Field-level options can alter form controls, remove fields, or select hidden treatment under their specific branches. Separately configured strict result handling can redact selected retrieved values. Save generation must distinguish a missing submitted value that should be cleared from a value absent because the current user was not allowed to edit it. Policy therefore affects declarations, presentation, result handling, and persistence together. [Permissions](https://architecture.joomlacomponentbuilder.com/markdown/generation/permissions.md)

Language processing connects emitted keys to source strings and target catalogues. Translation maintenance reuses available records and applies selected inclusion thresholds. Router generation connects views to keys, aliases, and data sources. API and AJAX paths reuse established view identity, policy, input definitions, and authored method roles while retaining their own runtime integration contracts. [Languages](https://architecture.joomlacomponentbuilder.com/markdown/generation/languages.md), [entry surfaces](https://architecture.joomlacomponentbuilder.com/markdown/generation/routing.md)

Components, modules, and plugins have distinct data, structure, context, content, and packaging paths. The Hello World module combines structured redirect configuration with authored redirect behavior; the compiler supplies its native module structure. The plugin's stored name contains a component placeholder; compilation resolves it under the component occurrence into its final plugin identity. [Extension trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/extension-trace.md)

Materialization completes staged files, resolves late code dependencies, supplies autoloading, writes language and installation metadata, and constructs archives. The output is a native application product. Normal application requests do not ask JCB's authoring GUI to interpret the blueprint again. [Materialization](https://architecture.joomlacomponentbuilder.com/markdown/generation/materialization.md)

## 13. Extrusion returns existing structure to the model

The integrated extrusion machinery accepts component roots and schema material, discovers relevant artifacts, and reads their represented structure without executing the application. Schemas, form XML, manifests, language files, table metadata, classes, and presentation files supply overlapping but different evidence. [Extrusion](https://architecture.joomlacomponentbuilder.com/markdown/extrusion/overview.md)

Property resolution is explicit. Its default precedence is table metadata, SQL notes, XML, then derived schema information, with configurable ranks and a stable tie-break. Selection occurs per property and retains the winning value's origin. Zero and false are usable values; null and empty string are excluded by the selected rule. A database default and form default remain different properties. [Artifact analysis](https://architecture.joomlacomponentbuilder.com/markdown/extrusion/analysis.md)

Harvest, candidate presentation, and writing are separate operations. Pairing decisions select create, update, or ignore. Sharing can consolidate compatible fields before associations are written. Writers follow dependency order so later records can refer to identities established earlier. Reports retain deliberate skips and unresolved details.

Class extrusion locates supported named declarations, extracts their bodies, resolves namespace/path relationships, reconstructs supported imports and Power connections, and reverses applicable component or language specialization into reusable representations. The recovered definition then uses the ordinary compiler's acquisition, namespace, binding, and placement services. [Class recovery](https://architecture.joomlacomponentbuilder.com/markdown/extrusion/classes.md), [pairing](https://architecture.joomlacomponentbuilder.com/markdown/extrusion/pairing.md)

Extrusion is not the unique inverse of every possible program. The same ordinary index can have arisen from an explicit index choice or from a title role; SQL alone cannot tell which. Additional metadata and review decisions select a usable model. The recovered model becomes explicit design knowledge for subsequent compilation and export. The [edition record](https://architecture.joomlacomponentbuilder.com/markdown/reference/edition.md) identifies this implemented integrated capability separately from the older core source pin.

## 14. Transport, recovery, and regeneration preserve different things

Let $\beta(D)$ be the normalized blueprint-relevant projection of local design. Define

$$
D_1\equiv_B D_2\quad\Longleftrightarrow\quad\beta(D_1)=\beta(D_2).
$$

A loss-preserving export/import pair, complete required dependencies and assets, consistent identity mapping, and an accepting existing-item policy preserve this relation. Local numeric IDs and intentionally omitted installation state can differ. Regenerated artifact equality additionally depends on target rules, reusable inputs, hooks, and environment observations. [Transport model](https://architecture.joomlacomponentbuilder.com/markdown/formal/transport.md)

Designated-code recovery has another domain. GUI addresses and contextual fingerprints locate eligible authored regions. When a regenerated file's context still identifies the intended placement, the compiler restores the code there. Where an existing file's location cannot be established, it retains commented recovery material and reports the file and recorded location for repositioning. A missing target file has a separate diagnostic.

For uniquely identified non-overlapping regions whose admitted bodies are preserved, extraction after emission returns the same region map. Where generation specializes text and recovery reverses it, the law concerns the canonical representation those transformations preserve. This is a local property of the selected recovery mechanism, not raw equality of entire arbitrarily edited applications.

Regeneration connects these flows. A blueprint transported to another installation can be edited and compiled. A recovered model can join the same process. An authored region can re-enter the next build. The compiler remains the common operation that turns their resulting design knowledge into coordinated products.

## 15. Self-generation and the maintenance multiplier

JCB builds its own application from its blueprint and reusable inputs. Its generated application layers outside the library collection provide the authoring and Joomla integration through which definitions are managed and compilation invoked. The libraries include substantial supplied implementation, including compiler services. [Self-generation](https://architecture.joomlacomponentbuilder.com/markdown/engineering/regeneration.md)

The self-build is

$$
A_J=\operatorname{compile}(B_J,L_J,\Theta_T,C,H),
$$

where $B_J$ is the application blueprint and $L_J$ the reusable library/Power input. Their different origins remain visible; the compiler coordinates their inclusion rather than authoring every library body during the build.

The same separation supplies a maintenance multiplier. A change to a shared target rule can reach each model that consumes that rule on regeneration. A platform mapping can update references across several applications. A field decision can update several artifacts within one application. The propagation is determined by actual dependencies and ownership: authored complete-class replacements and arbitrary embedded code retain their own maintenance responsibilities.

This effect can be inspected directly: identify the changed rule or definition, identify its consumers, regenerate, and compare the affected products. It does not need an invented labor estimate or a market-superiority assertion.

## 16. Measurements and the cost of coordination

Repeated maintained self-builds compile an approximately 30,000-line JCB blueprint into an application exceeding one million lines in approximately 60–64 seconds on the demonstrated setup. The compiler timer includes initialization and content preparation through the successful final packaging path. Reusable rules, templates, Powers, libraries, and assets are additional inputs. [Performance record](https://architecture.joomlacomponentbuilder.com/markdown/engineering/performance.md)

The smaller public Hello World snapshot has 33 payload JSON files, 65,600 serialized bytes, and 1,298 physical payload lines. Its three generated repositories contain 32,988 physical text lines across 286 text files. Indexes, descriptions, binary assets, and repository metadata are counted separately. Escaped newlines inside JSON strings mean physical payload lines are not a measure of decoded program statements or manual effort. [Accounting](https://architecture.joomlacomponentbuilder.com/markdown/examples/accounting.md)

A useful cost model separates acquisition, normalization, contextual interpretation, deferred completion, binding, writing, packaging, and effects. Reuse can replace repeated acquisition cost $na$ with one acquisition plus lookups while retaining the distinct contextual work. It does not remove the cost of writing $B$ required output bytes, which is at least $\Omega(B)$ in a byte-charging model.

Retained state trades acquisition or recomputation against memory and lifecycle obligations. Ordered substitution can repeatedly scan intermediate strings; later expansion can change their size. Repository and local-cache conditions define different workloads. The paper's measurement method records those boundaries instead of using one output ratio as a universal performance conclusion.

## 17. Operational semantics and reusable implementation boundaries

The complete state can be represented as

$$
\Sigma=(q,D,K,O,M,W,P,A,X,\Delta),
$$

covering control position, local design, request state, occurrences, stores, deferred work, bindings, artifacts, external observations, and diagnostics. A transition changes its specified parts. A complete trace includes event handlers and external reads, not only built-in generation functions. [Operational state](https://architecture.joomlacomponentbuilder.com/markdown/formal/state.md)

For fixed initial state, fixed relevant observations, deterministic operations, and a prescribed control policy, corresponding states remain equal by induction through the execution. This establishes repeatability of the explicit model without requiring all mutations to commute. The model also permits explicit failure, partial artifacts, and recovery diagnostics.

An implementation in another language needs the same responsibility boundaries: typed model normalization; portable identity and resolution policy; contextual interpretation; typed contribution operations; scoped stores; deferred prerequisites; target dispatch; explicit binding semantics; staged artifacts; and separate transport/reconstruction contracts. It can use syntax trees instead of fragments, records instead of PHP registries, and another module system instead of PHP namespaces. [Implementation guide](https://architecture.joomlacomponentbuilder.com/markdown/engineering/implementation.md)

A small complete vertical slice is the practical starting point. One field should produce consistent schema, form, query, and metadata; its portable identity should survive transport; changing its context should affect only the intended projections; and a missing dependency should produce a specific result. The executable companion makes selected mechanisms directly testable before a complete application generator is built.

## 18. Intellectual context and conclusion

Model-driven engineering explains the separation of intent and platform implementation. Attribute grammars and JastAdd provide close context for inherited, synthesized, referenced, and demand-evaluated information. MPS mapping labels exemplify retaining input-to-generated relationships for later consumers. Build-system research separates dependencies, scheduling, and rebuilding; memoization addresses repeated computation; modularity addresses change boundaries; bidirectional transformations and protected regions address selected update paths. [Related mechanisms and bibliography](https://architecture.joomlacomponentbuilder.com/markdown/reference/bibliography.md)

These are retrospective connections to established work. They clarify the independently developed JCB architecture without erasing its provenance or treating every similar mechanism as the same complete system.

The resulting account is a compiler-centered composition. Portable identities make definitions discoverable and reusable. Context gives each occurrence its proper interpretation. Specialized stores preserve distinct consequences. Deferred work separates discovery from readiness. Ordered binding and target-aware placement complete native products. Export, import, extrusion, and designated recovery return useful information to the same editable model.

The public traces expose that composition at a small inspectable scale; the generated applications and maintained self-build expose its larger operational use. The mathematics names the relationships that make it coherent. Together they provide a basis for understanding the current implementation, reproducing its architectural choices elsewhere, and studying where a subsequent implementation can improve them.

The [reading guide](https://architecture.joomlacomponentbuilder.com/markdown/reading-guide.md), [source map](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md), [formal vocabulary](https://architecture.joomlacomponentbuilder.com/markdown/formal/notation.md), and [verification guide](https://architecture.joomlacomponentbuilder.com/markdown/engineering/verification.md) provide the detailed continuation. Every article is available as its own exact Markdown source.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/reading-guide.md

# Reading guide

The publication can be read as a white paper, an architectural reference, or a worked investigation. All three routes meet at the same object: the transformation of structured development intent into a coordinated set of application artifacts.

## Begin with a visible result

Read the [Hello World overview](https://architecture.joomlacomponentbuilder.com/markdown/examples/hello-world.md), then the [Greeting field trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/field-trace.md). A compact field definition and its view association explain the generated column, form input, language entries, list features, and table metadata. The distinction between a definition and its use becomes visible before it is formalised.

Continue with [custom-code markers](https://architecture.joomlacomponentbuilder.com/markdown/examples/custom-code-trace.md) and [module/plugin generation](https://architecture.joomlacomponentbuilder.com/markdown/examples/extension-trace.md). These traces show how stored code, contextual names, component relationships, and extension-specific emitters participate in the same build.

The [accounting chapter](https://architecture.joomlacomponentbuilder.com/markdown/examples/accounting.md) identifies exactly what belongs to the blueprint, what belongs to its repository description, and what belongs to the generated products. It is useful when reading any size or expansion figure.

## Read the continuous white paper

The [white paper](https://architecture.joomlacomponentbuilder.com/markdown/white-paper.md) is the main narrative. Its chapters introduce the model, follow the lifecycle, explain the compiler's coordinating mechanisms, and derive the mathematical account from those mechanisms. Follow its links when a particular operation needs more detail.

No knowledge of Joomla class names is required for the main argument. The glossary defines the few product terms retained because they identify specific JCB concepts: *Power*, *Dynamic Get*, *Infusion*, *blueprint*, and *extrusion*. [Glossary](https://architecture.joomlacomponentbuilder.com/markdown/reference/glossary.md)

## Understand the implementation architecture

Start with [structured intent](https://architecture.joomlacomponentbuilder.com/markdown/foundations/structured-intent.md), [identity](https://architecture.joomlacomponentbuilder.com/markdown/foundations/identity.md), and [context](https://architecture.joomlacomponentbuilder.com/markdown/foundations/context.md). Then read [compiler execution](https://architecture.joomlacomponentbuilder.com/markdown/compiler/execution.md) in order. Initialization, data acquisition, content preparation, file updating, and packaging have separate responsibilities; work performed while constructing the compiler must be included in the trace.

The core sequence is [acquisition](https://architecture.joomlacomponentbuilder.com/markdown/compiler/acquisition.md), [classification](https://architecture.joomlacomponentbuilder.com/markdown/compiler/classification.md), [stores](https://architecture.joomlacomponentbuilder.com/markdown/compiler/stores.md), [deferred work](https://architecture.joomlacomponentbuilder.com/markdown/compiler/deferred-work.md), and [binding](https://architecture.joomlacomponentbuilder.com/markdown/compiler/binding.md). Read the generation chapters alongside this sequence to see which accumulated information feeds schemas, queries, forms, permissions, languages, routing, and extension packaging.

[Target selection](https://architecture.joomlacomponentbuilder.com/markdown/compiler/targets.md) separates the Joomla installation hosting JCB from the Joomla generation targeted by the output. [Events](https://architecture.joomlacomponentbuilder.com/markdown/compiler/events.md) describes extension hooks as part of execution rather than invisible background behaviour.

## Follow portable definitions and recovered structure

The blueprint chapters explain [representation](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/representation.md), [discovery](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/discovery.md), [dependency traversal](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/dependencies.md), [export](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/export.md), [import and reset](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/import.md), and [assets and repositories](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/assets.md).

Read [extrusion](https://architecture.joomlacomponentbuilder.com/markdown/extrusion/overview.md) after that sequence. An exported blueprint explicitly carries JCB definitions; an installed extension carries artifacts from which particular definitions can be recovered. Their import paths share a destination but do not have identical information content or correctness conditions.

## Read or implement the mathematics

Begin with [notation](https://architecture.joomlacomponentbuilder.com/markdown/formal/notation.md) and the [state model](https://architecture.joomlacomponentbuilder.com/markdown/formal/state.md). The remaining formal articles cover [resolution](https://architecture.joomlacomponentbuilder.com/markdown/formal/resolution.md), [classification](https://architecture.joomlacomponentbuilder.com/markdown/formal/classification.md), [staging](https://architecture.joomlacomponentbuilder.com/markdown/formal/staging.md), and [transport equivalence](https://architecture.joomlacomponentbuilder.com/markdown/formal/transport.md).

Each mathematical construction has an operational meaning. A graph edge identifies a dependency or relationship; a context selects the interpretation of a use; a store update records a particular kind of contribution; a transition changes a specified part of build state. A proposition states its assumptions before deriving its conclusion.

The [implementation guide](https://architecture.joomlacomponentbuilder.com/markdown/engineering/implementation.md) and [executable reference mechanisms](https://architecture.joomlacomponentbuilder.com/markdown/engineering/reference-model.md) turn that account into a practical starting point. They use a small vocabulary rather than attempting to reproduce every Joomla emitter.

## Check a statement against its source

The [source map](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md) groups the implementation paths by responsibility. The [edition record](https://architecture.joomlacomponentbuilder.com/markdown/reference/edition.md) identifies the inspected revisions and the integrated capability scope. The [bibliography](https://architecture.joomlacomponentbuilder.com/markdown/reference/bibliography.md) credits the established work used to describe related mechanisms.

A source trace, a recorded build measurement, and a proof about a stated mathematical model answer different questions. The publication identifies which one is being used without requiring the reader to interrupt the architectural explanation at every paragraph.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/foundations/architecture.md

# The architectural object

JCB compiles a structured application description. The description is distributed across reusable entities, relationships, configuration, custom code, and assets. It is assembled for a particular build rather than read as one undifferentiated source string.

The architectural object is therefore a **contextual application model together with its generation environment**. A database stores one representation of that model. Repository JSON stores a portable representation. Generated source files store the application's implementation for a target platform. The compiler connects these representations through explicit operations.

## Definitions, uses, contributions, and products

A definition supplies reusable information. A use attaches that information to a particular application context. Processing the use produces contributions to several concerns. Those contributions are later assembled into artifacts.

For a definition $d$ and context $\Gamma$, write

$$
J(d,\Gamma)=\langle c_1,c_2,\ldots,c_m\rangle.
$$

Each $c_i$ is a contribution with a destination store, a key, an update operation, and a value. Some contributions are code fragments. Others are schema descriptions, flags, aliases, language mappings, requirements, or deferred operations. A value need not be executable text to affect the generated application.

For the Greeting field, the reusable definition describes its type, label, and database properties. Its admin-view association marks it as a title, searchable, sortable, and visible in the list. Processing that association creates consequences beyond the form input itself. [Field trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/field-trace.md)

## A graph rather than a flat list

Let $G=(V,E)$ be the resolved definition graph. Vertices are typed entities. Edges identify references, ownership relationships, associations, or asset requirements. The same vertex can participate in several uses; an occurrence expansion supplies those uses without pretending that shared definitions have become unrelated copies.

The artifact graph is different from the definition graph. Several definitions can contribute to one file. One definition can contribute to several files. A component relation can include a module or plugin whose own data and emitters produce another extension tree.

Consequently, no general one-definition-to-one-file correspondence is assumed. The useful relation is

$$
\mathcal{R}\subseteq \mathcal{O}\times\mathcal{C}\times\mathcal{A},
$$

where $\mathcal{O}$ denotes contextual occurrences, $\mathcal{C}$ contributions, and $\mathcal{A}$ artifacts. A trace records which contribution from which occurrence participates in which artifact.

## The generation environment supplies reusable knowledge

A complete build includes more than the project blueprint. It includes compiler rules, skeletons and templates, reusable libraries and Powers, target conventions, configuration, and relevant environment values. A compact blueprint is effective because those inputs already embody recurring implementation decisions.

Write a build input as

$$
I=(D,R,\Theta,T,C,H),
$$

with local definitions $D$, configured repository responses $R$, generation rules and supplied reusable material $\Theta$, target $T$, build configuration $C$, and relevant host environment $H$.

This expression identifies dependencies of the computation. It does not require JCB to serialize all of them into a single immutable object before compilation. The actual execution can acquire more definitions and produce filesystem state while other semantic work is still in progress. [State model](https://architecture.joomlacomponentbuilder.com/markdown/formal/state.md)

## The compiler is the coordinating centre

JCB's orchestration acquires component data, enriches its children, prepares shared and context-specific output material, performs deferred work, and updates staged files. The implementation uses a shared service container, specialised builders, code dispensers, and target-specific architecture services. These are concrete representations of the model's responsibilities. [C01–C06](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c01)

The contribution of this account is to make that coordination explicit enough to study and reproduce. Another implementation could use records, typed maps, graph nodes, functions, or a different persistence layer while preserving the same separation of identities, contexts, contributions, ordering, and outputs.

The next chapters examine [structured intent](https://architecture.joomlacomponentbuilder.com/markdown/foundations/structured-intent.md), [identity](https://architecture.joomlacomponentbuilder.com/markdown/foundations/identity.md), and [context](https://architecture.joomlacomponentbuilder.com/markdown/foundations/context.md) before following the [complete lifecycle](https://architecture.joomlacomponentbuilder.com/markdown/foundations/lifecycle.md).


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/foundations/structured-intent.md

# Structured intent as compiler input

The JCB editor lets a developer express many implementation decisions as structured choices. A field has a type and storage description. Its placement in an admin view can give it list, title, alias, search, sorting, filtering, alignment, and tab roles. A component selects views, extension relationships, configuration, namespace, target, and packaging behaviour. Custom code supplies the parts that are intentionally expressed as code.

These choices form a domain-specific application description. The GUI is one authoring surface for it; the database is a working representation; a repository blueprint is a portable representation. Compilation depends on the represented intent, not on whether a person originally entered it by clicking a control or importing a definition. [B01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b01), [E01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#e01)

## A small decision can have several precise consequences

In Hello World, a field association sets `title`, `sort`, `search`, and `link` alongside the field identifier. Each flag addresses a distinct concern. The compiler records title behaviour, sortable ordering, searchable query participation, and link presentation while retaining the field's common identity and name.

The important economy is **not repeated textual compression**. The developer specifies a decision once, and established generation rules carry that decision into the relevant implementation locations. The rule knowledge already resides in the compiler and its supplied material.

Let an editor submission $u$ be normalized into a model $N(u)$. For a concern $k$ and target $T$, an interpretation rule computes

$$
P_{k,T}(N(u),\Gamma).
$$

The result can be a fragment, a structured record, a requirement, or no contribution when the feature is disabled. The same normalized choice can therefore feed several concern-specific projections without assigning it several inconsistent meanings.

## Representation is not the same as natural-language inference

The editor's intent is constrained and explicit: identifiers, selected options, structured relationships, templates, and authored code. For example, a searchable flag authorizes generation of known search behaviour; it does not infer an unspecified business rule from the word *Greeting*.

This distinction explains both the compactness and the repeatability of the input. A developer need not restate Joomla's controller and model conventions for every field, because the compiler supplies them. Application-specific choices remain represented in the blueprint or custom code.

The architecture thus combines declarative configuration with imperative escape points. A model can express conventional behaviour compactly while retaining a route for domain-specific methods, views, scripts, libraries, and services. [C05](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c05), [C09](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c09)

## Selection, validation, and interpretation are separate

An editor can constrain which values are entered. Persistence can normalize and encode those values. Compilation interprets their relationships under a target and a use-site context. Runtime code then applies the generated behaviour to application data and users.

These are four different moments. A compiler permission to import a blueprint, for example, is not the runtime permission of a future user to edit a generated record. Similarly, a field's database width and its form input's maximum length are distinct properties. The Hello World Greeting field uses a database width of 255 and an input maximum of 50; the compiler preserves their different roles. [Field trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/field-trace.md)

## A language-neutral implementation

An implementation in another technology needs an explicit model schema and a normalization layer, not a replica of JCB's PHP forms. It can offer a browser editor, command-line authoring, an API, or file-based definitions. All should produce the same typed model for the compiler.

The essential interface is:

```text
normalize(authoring_input) -> model or diagnostics
resolve(model_roots, repositories) -> available definition graph
interpret(definition_use, context) -> ordered contributions
materialize(contributions, target_rules) -> application artifacts
```

Validation remains attached to these boundaries. References must identify supported entity types; generated names must satisfy target rules; feature combinations must be interpreted consistently. The interface does not turn arbitrary incomplete input into a complete application.

Model-driven engineering and structured language work provide the established vocabulary for this arrangement. The relevant correspondence is the separation of domain intent from repeated target-platform implementation, not a claim that every GUI is a compiler. [R01–R03](https://architecture.joomlacomponentbuilder.com/markdown/reference/bibliography.md#r01)


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/foundations/identity.md

# Identity across representations

Identity allows a definition to survive changes in storage, use, and physical location. It also determines what can safely be reused. JCB's lifecycle contains several identities, and the distinctions between them explain much of its behaviour.

## Portable entity identity

A portable request is represented as

$$
u=(t,k,v),
$$

where $t$ is an entity type, $k$ its identifying field, and $v$ the value of that field. Many entities use a GUID. Other supported entities use an alias or a relationship key. The custom-code example `readMEcontributors` is identified by its function name; it is not a GUID-shaped exception to be discarded. [B01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b01), [E01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#e01)

The type matters. A field identifier, a view identifier, and a Power identifier are not interchangeable merely because their values have the same lexical form. The key field matters for the same reason: a numeric database primary key is not automatically a portable identifier.

Repository indexes map portable identities to payload locations. Payloads retain their entity references, and dependency descriptors specify the target type and identifying field. This permits a request to be resolved without embedding the destination installation's row number in every relationship.

## Local database identity

A local installation can assign a numeric primary key to a record whose portable identity remains unchanged. Denote the local realization in installation $i$ by

$$
\lambda_i(u)=\text{local record identity}.
$$

Two installations can have $\lambda_1(u)\ne\lambda_2(u)$ while referring to the same portable definition. Imported relationships must therefore be interpreted through their declared identity representation, not copied under the assumption that all local row numbers coincide.

JCB's field loader indexes acquired definitions by both ID and GUID. Its editor-linked code markers can also contain local table, property, and numeric-record information. Those markers are useful local addresses for recovery; they should not be mistaken for the enduring identity of the application design. [C04](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c04), [C09](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c09)

## Occurrence identity

A shared field may occur in more than one view. A view definition may be attached under different component settings. The occurrence is the use, not another independently authored definition.

Write

$$
o=(u,p,a),
$$

where $u$ identifies the definition, $p$ identifies its place in an association or expansion, and $a$ contains occurrence-specific settings. The context $\Gamma(o)$ supplies the surrounding extension, target, view, role, and other relevant values.

An implementation need not allocate a permanent occurrence object for every such tuple. JCB often carries these distinctions in association records, loop variables, view names, configuration, and store keys. The tuple makes the distinction explicit for analysis without claiming that the production code uses that exact data type.

## Artifact and region identity

A generated artifact has a role and a destination. A file path is often a convenient location but is not equivalent to the identity of the definition that contributed to it. One definition can affect several paths; several definitions can affect one path.

Designated editable regions add another address. GUI markers associate recovered code with a stored property. Hash-based custom-code records also retain contextual placement information. These are different mechanisms, and a filename alone is not enough to describe both. [Custom code](https://architecture.joomlacomponentbuilder.com/markdown/compiler/custom-code.md)

## Consequence for reproducibility

A blueprint transfer can preserve the application description while installation-local row numbers differ. Generated editor markers, dates, and similar metadata can consequently differ even when application structure and behaviour are preserved. Byte equality is a stronger comparison that requires those output-affecting values to be fixed or normalized under a declared rule.

The [transport model](https://architecture.joomlacomponentbuilder.com/markdown/formal/transport.md) makes that equivalence explicit. It does not weaken the purpose of portable blueprints; it identifies which identity must remain stable for their purpose to be achieved.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/foundations/context.md

# Context and interpretation

A definition does not determine all of its generated uses by itself. Its interpretation depends on where it is used and what is being built. A field label acquires an extension and view language prefix; a reusable class acquires a resolved namespace and destination; a code block receives the placeholders active at the point of use.

Represent the relevant environment as

$$
\Gamma=(T,e,v,r,\ell,P,a),
$$

where $T$ is the generation target, $e$ the extension, $v$ the view or other use-site, $r$ the generation role, $\ell$ the language destination, $P$ the binding environment, and $a$ additional occurrence settings. This tuple is a semantic description, not a requirement to copy the entire environment into every cache key.

## Context is carried in several forms

In JCB, context can be carried by a service argument, an association record, a view-scoped store key, or the shared build configuration. `ContentOne` supplies shared file bindings; `ContentMulti` partitions bindings by view or extension key. The custom-code dispenser stores prepared material and applies the active placeholders when retrieving it. Field-specific processing tracks which field scripts have already contributed to a view. [C04](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c04), [C06](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c06), [C09](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c09)

These mechanisms cooperate. A globally reusable field definition does not require every derived fragment to be globally reusable. Some of its properties can be cached by definition identity, while other consequences must be established for each use-site.

## Reuse depends on the information actually read

For an interpretation $J$, let $\pi_J(\Gamma)$ denote the dimensions of context on which it depends. A sufficient reuse condition is

$$
\pi_J(\Gamma_1)=\pi_J(\Gamma_2)
\quad\Longrightarrow\quad
J(d,\Gamma_1)=J(d,\Gamma_2),
$$

provided the definition and other read inputs are also the same.

A database-column description may depend on different dimensions than a language key or namespace. Treating them as separate contributions allows their reuse boundaries to differ. The [classification model](https://architecture.joomlacomponentbuilder.com/markdown/formal/classification.md) develops this as a dependency contract.

This condition is used to explain correct reuse, not to assert that every production callback has been proved context-independent. An extension hook that reads an additional value extends the actual dependency set. The operational trace must include that read.

## Ordered context changes

A shared configuration can be updated as generation moves from an administrator view to a site view, module, or plugin. Such a design requires the correct context to be established before each consumer runs. Where a service temporarily changes a value and restores it, both actions belong to its behaviour.

The module and plugin infusers, for example, establish their build target, language target, and language prefix before assembling their content. Target architecture services select implementations using the requested output Joomla version. [C17](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c17), [C18](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c18), [C21](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c21)

A language-neutral implementation may express these boundaries using explicit immutable context arguments instead. That is a representation choice; preserving the visible interpretation and ordering is the architectural requirement.

## Build context and runtime policy

The user running the compiler is not the user who will later operate a generated application. Build-time access controls govern operations such as reading local data and accepting external code. Generated access-control rules govern later application operations.

The compiler processes the *definition* of runtime policy. It emits checks, action declarations, and interface behaviour that Joomla evaluates against runtime users and assets. Conflating those contexts would make an architectural explanation of field permissions incorrect. [Permissions](https://architecture.joomlacomponentbuilder.com/markdown/generation/permissions.md)

The same separation applies to host and target versions. The Joomla installation executing JCB supplies host services; the chosen compile target determines output conventions. [Target selection](https://architecture.joomlacomponentbuilder.com/markdown/compiler/targets.md)


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/foundations/lifecycle.md

# The complete development lifecycle

The compiler sits inside a development lifecycle with several entry and exit paths. Keeping those paths distinct explains how JCB can accept design information from an editor, a repository, or an existing extension without treating all three as the same source format.

## Authoring and durable definitions

A developer authors fields, views, relationships, configuration, and code through JCB's editor. These become local records. Referenced definitions can already be present or can be acquired from configured repositories through supported resolution paths.

The local database is an editable working representation. It contains design information as well as installation-local state. Export selects the portable parts rather than treating every database column as part of a blueprint. [Structured intent](https://architecture.joomlacomponentbuilder.com/markdown/foundations/structured-intent.md), [Blueprint representation](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/representation.md)

## Blueprint exchange

Export traverses selected entities and their relationships, prepares portable payloads and dependency descriptors, and writes their repository representations. Indexes make those representations discoverable; generated documentation makes them understandable in the repository and JCB interface.

Import resolves selected identities, preserves local definitions under ordinary initialization, acquires missing definitions, and follows discovered dependencies. Reset is an explicit refresh operation with a different overwrite policy. Assets have their own acquisition and placement path. [Export](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/export.md), [Import](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/import.md)

Thus, export and import connect two representations of design knowledge. A generated Joomla installation package is a different product: it contains runtime implementation rather than the editable JCB model.

## Compilation and deployment products

Compilation enriches the selected component graph, produces concern-specific contributions, prepares artifact structures, binds content in ordered stages, and produces extension trees and archives. Components, modules, and plugins share services and conventions while using extension-specific generation paths.

The resulting application runs using its Joomla target and included dependencies. It is not a browser facade that must consult the authoring GUI whenever a generated field is displayed. The compiler has already placed the relevant implementation in the product. [Extension generation](https://architecture.joomlacomponentbuilder.com/markdown/generation/extensions.md)

## Extrusion from an existing extension

Extrusion starts from an installed or unpacked component's artifacts. It discovers schemas, forms, language material, manifests, permissions, classes, and view-related material. Readers recover represented facts; resolvers combine them; the developer reviews candidate mappings; writers create or update JCB definitions.

This differs from blueprint import. The artifacts do not necessarily encode every original design decision, and some decisions can be represented in more than one way. Extrusion therefore includes selection, precedence, pairing, and retained source context. [Extrusion](https://architecture.joomlacomponentbuilder.com/markdown/extrusion/overview.md)

## Marked-code recovery

Generated files can also contain designated code regions connected to stored custom code or GUI properties. Before the next build resets its working output, the recovery machinery inspects eligible installed files and retrieves those marked edits. Fingerprint-based placement later seeks the intended location in regenerated files; an unresolved placement in an existing file has an explicit commented recovery path and warning.

This is a bounded editorial feedback mechanism, not the same operation as broad installed-component extrusion. [Custom code](https://architecture.joomlacomponentbuilder.com/markdown/compiler/custom-code.md)

## Regeneration as the connecting operation

The next build consumes the updated definitions and current generation rules. Reusable definitions and compiler changes can therefore propagate across multiple applications through compilation. Target-specific rules can carry platform adaptations while the model retains application intent.

Formally, distinguish the transformations:

$$
\operatorname{export}:D\to B,\qquad
\operatorname{import}:(D,B)\to D',
$$

$$
\operatorname{compile}:(D,\Theta,T,C,H)\to(A,\Delta),
$$

$$
\operatorname{extrude}:A\to\text{candidate definitions},\qquad
\operatorname{recover}:A\rightharpoonup\text{designated edits}.
$$

Here $\Delta$ includes diagnostics and other recorded build effects. These functions have different domains and policies. Their combination is useful precisely because the representation boundaries remain explicit. [Formal state](https://architecture.joomlacomponentbuilder.com/markdown/formal/state.md), [Transport equivalence](https://architecture.joomlacomponentbuilder.com/markdown/formal/transport.md)


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/foundations/provenance.md

# Development and provenance

Joomla Component Builder originated as my independently developed response to the recurring work of building complete Joomla extensions. The objective was practical: express application intent in manageable definitions, reuse implementation knowledge, and repeatedly produce the detailed code and structure that Joomla applications require.

I developed the original approach without awareness of several of the compiler and model-driven engineering systems discussed in this publication. The connections to attribute grammars, staged generation, memoization, and other established work were identified retrospectively. They help describe the architecture accurately; they are not an invented account of what influenced its beginnings.

**Llewellyn van der Merwe**

## The public implementation record

The official source lineage begins with commit `ecf47809f960bd057af8a414168fada6fe22c5f7`, titled “first commit of free version,” recorded on **30 January 2016 at 20:28:43 UTC**. The compiler in that revision already uses specialised builder arrays, static and dynamic content stores, component-data loading, structure construction, and a later file-update sequence. [C23](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c23)

That source is evidence of an implemented architecture at that date. It does not date every later capability, the present service layout, or this mathematical exposition to the same point in time. The source header also records an earlier creation date, while the author's development account describes work preceding public release. These are distinct kinds of historical record.

## From a large compiler to specialised services

The early compiler concentrated substantial behaviour in large classes. Over subsequent years, responsibilities were separated into services and object-oriented collaborators: component data, field processing, specialised builders, placeholders, language services, Power handling, architecture-specific emitters, and file-updating utilities.

The continuity lies in the dataflow and its responsibilities, not in preserving one class arrangement. Definitions are acquired, their consequences are organised, context is established at use-sites, and output is assembled through ordered work. Refactoring can change where a responsibility lives without changing the architectural purpose it serves.

The current [source map](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md) names the inspected implementation paths. Historical and contemporary paths are kept separate so that the publication's references remain reproducible.

## Authorship and prior work

The architecture described here is my work and this is my white paper, supported by research and editorial assistance. Joomla, reusable third-party libraries, and the research cited in the bibliography retain their own authorship.

Independent development and historical priority are different statements. A mechanism can have been independently derived in JCB while corresponding to a principle published earlier. Giving that earlier work its proper credit makes the explanation more useful: readers can connect the implementation to a larger body of knowledge without erasing the actual development history.

The [related mechanisms in the bibliography](https://architecture.joomlacomponentbuilder.com/markdown/reference/bibliography.md) therefore identify precise correspondences. A shared store resembles some aspects of blackboard coordination; context-sensitive attributes resemble aspects of attribute-grammar evaluation; marked-edit recovery relates to round-trip engineering. None of those observations requires that JCB implement another system's complete formalism.

## The purpose of this edition

This edition collects the implemented mechanisms into an architectural account that can be read independently of the PHP codebase. It supports three activities: understanding how JCB works, implementing its architectural choices in another technology, and studying the resulting model when considering future work.

The edition documents the present mechanism before proposing changes to it. Its mathematical vocabulary is a way to expose relationships, state changes, and ordering—not a substitute for the implementation record. [Edition and sources](https://architecture.joomlacomponentbuilder.com/markdown/reference/edition.md)


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/blueprints/representation.md

# Blueprint representation

A JCB blueprint is a portable description of development intent. It contains the definitions and relationships from which the compiler constructs an extension. A blueprint repository also contains material that makes those definitions discoverable and readable. The distinction matters: an index describing a component is not another copy of the component's design, and a generated README is not additional compiler input simply because it lives beside that design.

## Five parts of a repository representation

**Entity payloads** carry properties such as field types, view settings, query definitions, custom code, extension configuration, and stable identifiers. **Association payloads** carry relationships and use-specific settings: which field appears in a view, which view belongs to a component, or which module accompanies a component. **Dependency descriptors** identify other required entities or assets. **Indexes** map identities to discoverable payload locations and descriptive metadata. **Documentation** presents the same items to readers and repository browsers. Binary or textual **assets** supply referenced images, files, and folders.

The Hello World snapshot contains 33 JSON payload documents: 24 root `item.json` records and nine child relationship/configuration documents. It also contains 22 index JSON files and four transported assets. The accounting method and complete inventory are provided in [blueprint and product accounting](https://architecture.joomlacomponentbuilder.com/markdown/examples/accounting.md). These categories are counted separately.

## The payload is a model projection

Export uses each entity's configuration to decide what to read, normalize, retain, and omit. For a component, the configuration identifies the component payload path and its index, declares child entities, and excludes installation-specific fields such as selected server records and particular export or translation-service credentials. The portable representation is therefore not a raw dump of every column in a local database. [B01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b01), [B05](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b05)

Let $D$ be local working data and $t$ an entity type. Its portable projection is

$$
B_t=\operatorname{encode}_t(\operatorname{project}_t(D)).
$$

Projection and encoding do different work. Projection selects design properties and relationships. Encoding represents them in a transport form, including decoded code and normalized nested structures where the entity's mapper specifies those transformations. Local numeric record IDs and editing metadata need not be reproduced as application identity.

The projection is type-specific. The publication does not assume that every property named similarly across tables has identical export semantics. The configured maps and model services are the authority for the actual representation.

## Dependencies are explicit transport instructions

A payload can include a reserved `@dependencies` member. For example, the Hello World admin view identifies its field-association child using the view's GUID:

```json
{
  "key": "admin_view",
  "value": "65116558-be67-4931-95be-727fbfb16db7",
  "entity": "admin_fields",
  "table": "#__componentbuilder_admin_fields",
  "direction": "in"
}
```

The descriptor says how to find a dependent record. It is not a runtime application table definition. The reserved member separates transport relationships from ordinary persisted entity properties. [B03](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b03), [E01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#e01)

An outgoing reference uses the target entity's identifying field, commonly `guid`. An incoming child relation uses the owning entity's identifier as a relationship key. File descriptors additionally carry information such as target area and repository pointer. These distinctions govern traversal, import, and reset policy.

## Identity is not always a GUID

The portable key is the typed triple $u=(t,k,v)$ introduced in [identity](https://architecture.joomlacomponentbuilder.com/markdown/foundations/identity.md). GUID-addressed fields and views are common, but custom code can be addressed by its function name. Hello World's `readMEcontributors` item is one such definition. Child payloads can be addressed by their parent relationship rather than by an independent GUID.

An implementation that blindly assumes every repository item has the shape `(guid, file)` would lose part of this model. The identifying field, entity type, and relationship direction are operational data.

## Repository layout is a representation choice

The component configuration uses `index/joomla-component.json` for discovery and `src/joomla_component` for payloads. Other entity types have their own configured names and paths. The index supplies paths to settings and readable item material. [B01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b01)

The compiler does not need Markdown prose to discover the meaning of a field. The JSON and its associated dependency and asset definitions carry that meaning. The generated documentation is valuable because it lets a developer inspect the same portable design without opening JCB.

A language-neutral implementation can use another serialization format while retaining the architecture: typed identity, explicit relationships, normalized design properties, separately described assets, and an index that locates the authoritative payload. The [export](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/export.md) and [import](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/import.md) chapters explain the operations over this representation.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/blueprints/discovery.md

# Local-first entity discovery

Repository discovery is not confined to Powers. JCB applies a common acquisition architecture across component definitions, their relationships, fields, views, templates, layouts, queries, code definitions, and other supported entities. A definition can be absent from the current installation yet available through a configured source. Once acquired, it becomes locally managed working data and can participate in ordinary compilation.

“Global” discovery means discovery across the repositories configured for the operation. It does not mean an unbounded web crawl or a broadcast to every repository on the Internet. Repository order, channel, branch, index, and entity identity determine the search. [B01–B04](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b01)

## The supported entity catalogue

The inspected factory identifies 45 canonical entity types. Its catalogue includes both reusable root definitions and relationship/configuration records:

| Family | Entity types |
| --- | --- |
| Component and component children | `joomla_component`, `component_admin_views`, `component_custom_admin_views`, `component_site_views`, `component_router`, `component_config`, `component_placeholders`, `component_updates`, `component_files_folders`, `component_custom_admin_menus`, `component_dashboard`, `component_modules`, `component_plugins` |
| Modules | `joomla_module`, `joomla_module_updates`, `joomla_module_files_folders_urls` |
| Plugins | `joomla_plugin`, `joomla_plugin_group`, `joomla_plugin_updates`, `joomla_plugin_files_folders_urls` |
| Views and view relationships | `admin_view`, `admin_fields`, `admin_fields_relations`, `admin_fields_conditions`, `admin_custom_tabs`, `custom_admin_view`, `site_view` |
| Reusable application definitions | `template`, `layout`, `dynamic_get`, `custom_code`, `field`, `validation_rule`, `fieldtype`, `library`, `library_config`, `library_files_folders_urls`, `class_method`, `class_property`, `class_extends`, `placeholder` |
| Code and distribution definitions | `power`, `joomla_power`, `repository`, `snippet` |

File and folder transport has separate handlers. The catalogue should not be read as a statement that every compiler lookup automatically performs a remote search, or that every type uses the same key and serializer. The factory and service container select the applicable handler; entity configuration supplies its precise contract. [B01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b01)

## Ordinary acquisition preserves local working knowledge

For an ordinary initialization request, an existing local definition satisfies the request. A missing definition can be obtained from a configured repository, mapped into the local representation, and stored. Dependencies exposed by that payload are queued for acquisition. This policy allows a developer to retain local edits rather than having a remote copy overwrite them on every lookup.

The broad operation is:

```text
initialize(request):
    normalize the entity type and identifying value
    if this request has already been attempted in this operation:
        return its recorded state
    record that the attempt has begun
    if an acceptable local record exists:
        record LOCAL
        return the local record
    select a configured repository whose index contains the request
    retrieve and map its payload
    persist the mapped definition
    enqueue its declared dependencies and assets
    record the operation's result
```

This pseudocode exposes the roles. The actual handlers determine error handling and persistence behaviour; marking an attempt is not the same event as successful retrieval. [B02](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b02), [B06](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b06)

## Repository selection and payload retrieval are distinct

The repository search services cache and consult indexes for the appropriate entity channel. They search configured sources in order and select an index match. The selected entry then supplies the payload location and identifying information.

In the inspected retrieval path, selecting the first index match does not guarantee automatic fallback to every later repository if that selected payload is malformed or unavailable. Index selection and payload failure are separate states. A reader implementing the architecture should make that policy explicit instead of treating a lookup as an unspecified “search everywhere until something works.” [B04](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b04)

A repository's read branch and write branch also have different purposes. A developer can consume reviewed definitions from one branch while publishing changes to another. The request's effective source therefore includes repository configuration and branch selection, not just an entity GUID.

## Discovery extends the local model

The architectural consequence of retrieval is local ownership of an editable representation. Acquiring a field is not simply fetching transient text for one output file. Its definition is stored, can be inspected in the GUI, can be revised, and can be reused by subsequent requests and builds. Powers follow this same broad pattern while adding code-specific dependency and namespace processing.

The field loader demonstrates an embedded use of the mechanism: after local lookup fails for a valid GUID, a guarded remote attempt can add the field and allow the loader to retry. Other acquisition paths invoke the package builder explicitly. Both connect portable identity to local data; neither requires every consumer to know the repository's physical file layout. [C04](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c04)

## Scope and repeatability

A request guard bounds repeated work within an operation. A stable source snapshot and fixed repository precedence make acquisition repeatable for the same requests. Changing a repository branch, a local record, or selection policy changes the effective input.

The [dependency chapter](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/dependencies.md) explains how newly discovered requests are drained. The [import chapter](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/import.md) distinguishes ordinary initialization from an explicit reset, and the [formal resolution model](https://architecture.joomlacomponentbuilder.com/markdown/formal/resolution.md) states the conditions under which traversal terminates and resolves a complete requested graph.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/blueprints/dependencies.md

# Dependency traversal and bounded discovery

Selecting a component does not identify all of its required information immediately. Its configuration points to relationship records. Those records identify views, fields, modules, or plugins. Code and markup can introduce additional references to reusable definitions. The package machinery discovers this graph as it processes its vertices.

JCB's dependency resolver extracts several classes of relation in one operation: outgoing entity references, incoming owned children, references in supported dynamic content, nested subform fields, validation rules, files, and folders. Each class has its own interpretation. [B03](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b03)

## Direction records the relationship's role

An outgoing dependency says that the current entity refers to another definition. A field refers to a field type; a view association refers to a field. An incoming dependency identifies a child record by its parent relationship: a component has a `component_admin_views` record, and an admin view has an `admin_fields` record.

Both directions must be traversed to transport the relevant design. They are not equivalent for every operation. In particular, resetting a parent can require refreshing its owned child configuration without overwriting every separately maintained reusable definition it references. [Import and reset](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/import.md)

Represent a dependency as

$$
e=(u_s,u_t,\delta,m),
$$

where $u_s$ and $u_t$ are typed source and target identities, $\delta$ records the relationship direction or role, and $m$ carries transport metadata. This is a labelled graph: retaining the edge label preserves decisions that an unlabelled set of GUIDs would discard.

## References can be embedded in structured fields and code

Many relationships are available from schema metadata. Others appear in supported code conventions: custom-code references, Power keys, placeholders, template aliases, layout aliases, or field definitions embedded in subforms. The resolver inspects the configured fields and extracts the references that those conventions represent.

This is not a claim to solve arbitrary program analysis. A supported literal reference is discoverable because its syntax and interpretation are known. An identifier computed by arbitrary runtime code may not be recoverable by a static reference scan. The compiler's template/layout mechanism likewise recognizes supported literal call forms and follows their nested content. [Templates and layouts](https://architecture.joomlacomponentbuilder.com/markdown/generation/forms-layouts.md)

The important architectural choice is to route both explicit database relationships and recognized embedded references into the same typed dependency process. A consumer then receives an available local definition without needing a separate import procedure for every origin of the reference.

## Queue expansion separates discovery from dispatch

The dependency trait records requests in a tracker keyed by entity and identifying value. Entity dependencies and file/folder dependencies use different queues. The package builder selects a handler for each entity family, processes its current requests, and drains newly discovered work.

In the inspected implementation, a queued batch is removed before its recursive processing. This prevents the same pending batch from being re-entered as though it were new. Per-request attempt markers provide a second boundary around repeated acquisition. [B02](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b02), [B03](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b03)

A language-neutral description is:

```text
pending := normalized root requests
attempted := empty
while pending contains an entity batch:
    batch := remove one batch from pending
    for request in batch:
        if request not in attempted:
            attempted.add(request)
            result := selected_handler.acquire(request)
            record result
            pending.add(result.discovered_entity_requests)
transport the accumulated file and folder requests
```

The source uses nested service calls and tracker drains rather than requiring this exact loop. The pseudocode makes the traversal obligation visible.

## Cycles do not require repeated acquisition forever

A definition graph can contain shared references and cycles. If requests have stable identities, each newly processed request marks progress. With a finite reachable request universe and handlers that themselves complete, guarded traversal performs only finitely many distinct acquisition attempts.

The bound applies to attempts, not to successful resolution. A missing record, a failed payload, or a persistence error can leave an unresolved request. Completion of traversal and completeness of the resulting graph must therefore be recorded separately. [Formal resolution](https://architecture.joomlacomponentbuilder.com/markdown/formal/resolution.md)

Similarly, a flag set before recursion is a cycle guard, not evidence that the corresponding record is fully loaded. This distinction also appears in Power loading, where the loader can mark an item while recursively acquiring its related definitions. [Powers](https://architecture.joomlacomponentbuilder.com/markdown/compiler/powers.md)

## Completeness is relative to the dependency contract

Let $R_0$ be selected roots and $\operatorname{deps}(u)$ the dependencies declared or discovered by the supported resolver. The reachable set is the least set satisfying

$$
R_0\subseteq R^*,\qquad
u\in R^*\Longrightarrow\operatorname{deps}(u)\subseteq R^*.
$$

This expression explains the target of dependency traversal. It does not assert that the whole compiler is a least-fixed-point rule engine, or that undeclared external behaviour has been discovered. The resolver's schema and recognized conventions define the relation being closed.

Once those requests are available locally, compilation still has to interpret their contextual uses and generate their consequences. Dependency completion makes information available; it does not replace semantic classification, deferred work, or output binding.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/blueprints/export.md

# Exporting the design graph

Export turns selected local design knowledge into a repository representation that another JCB installation can consume. The operation combines graph traversal, type-specific projection, serialization, asset transport, and publication metadata. It is not equivalent to compressing the current database or copying the generated Joomla extension tree.

The author can select a component as the root. The exporter then follows the relationships and supported embedded references needed to represent that component, writes the corresponding definitions, and constructs the repository indexes and readable descriptions. The Hello World repository is the resulting kind of product. [B02](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b02), [E01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#e01)

## Select, normalize, discover, publish

The package builder obtains each selected entity through its configured identifying field. Its remote-set service maps the local item into the portable form and extracts dependencies before attempting repository writes. Newly discovered entity work is accumulated and drained through the same family of handlers. Files and folders are handled after the entity traversal.

A useful decomposition is

$$
\operatorname{export}(R_0,D)=
\operatorname{publish}\bigl(\operatorname{encode}(\operatorname{project}(D|_{R^*}))\bigr),
$$

where $R^*$ is the supported dependency closure of the selected roots. The notation separates the conceptual operations; it does not impose an all-or-nothing transaction over the repository network.

Projection is important for both portability and clarity. For example, the component configuration omits selected installation-specific access, server, export, and translation-service fields while retaining the design information intended for transport. Referenced files such as the component image and compiler BOM material have declared destinations. [B01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b01)

## One definition can be published to several approved destinations

Repository configuration determines whether an item can be written and to which branch. The writer considers eligible, approved repositories with usable write-branch settings. Reading a definition and authorizing its publication are separate operations.

For each destination, the exporter can create or update the item payload, its readable item description, and its index entry. It can also update the repository's aggregate README or entity catalogue. Those descriptive files are generated from the same design record rather than maintained as an independent hand-written blueprint. [B05](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b05)

This organization makes a repository simultaneously a machine-consumable distribution surface and an inspectable design record. A user can read the exported descriptions, inspect the payload, and import the item by its stable identity.

## Change detection avoids unnecessary writes

The writer retrieves existing metadata when needed and compares the prepared representation with the remote state. It uses repository content identifiers for updates and can skip an unchanged item. The comparison is more specific than simply comparing raw local database rows: portable fields are normalized, and dependency descriptors are normalized for comparison.

In the inspected dependency comparison, order normalization does not erase multiplicity: repeated descriptors remain repeated records. A language-neutral implementation should distinguish set equality, multiset equality, and sequence equality instead of assuming that all three are interchangeable. [B05](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b05)

Generated indexes are merged with existing index content. Exporting one selected component therefore need not discard unrelated definitions already published in the same repository.

## Publication has observable intermediate states

The implementation writes items and supporting files through repository operations. A successful write of one item is not a proof that every later item, asset, or index update also succeeds. Likewise, publication to one approved destination can succeed while another destination reports a failure.

This is the actual operational granularity: selected entities, per-repository writes, metadata updates, and diagnostics. The architecture remains useful without describing those operations as a distributed transaction. A reviewable publication record identifies which outputs were written and which requests failed.

The distinction also explains why an index and its payload should be kept aligned. An index entry is a locator for authoritative settings; a payload that is missing or malformed at that location is a retrieval error, not a second valid interpretation of the entity.

## Export is not compilation

The exported field retains its model properties. It does not contain every generated form element, query clause, model method, language declaration, or database statement that the compiler will derive from those properties. Those consequences arise when an imported or local definition is interpreted in a concrete build context.

Conversely, custom code deliberately authored as part of a definition remains part of the portable design. The blueprint can therefore mix declarative settings with reusable code bodies. The export boundary does not require an application to be describable solely through a fixed set of graphical controls.

The [Hello World field trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/field-trace.md) shows this difference directly. The blueprint specifies a field and its use; the generated component contains the coordinated implementation. The next chapter follows the portable design back into local working data.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/blueprints/import.md

# Import, initialization, and reset

Import makes portable design knowledge available in a JCB installation. The critical question is not only how to deserialize JSON. It is which identity the payload represents, how its relationships are restored, what should happen to an existing local definition, and which additional entities or assets must accompany it.

JCB separates ordinary initialization from reset. That separation protects editable local knowledge while still providing an explicit route for refreshing it from a repository. [B02](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b02), [B06](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b06)

## Initialization is local-first

An ordinary initialization request first checks whether the requested local record already exists. When it does, the operation can retain that record and report it as local. When it does not, the selected remote payload is retrieved and mapped into the table-aware local representation. Its dependency descriptors add further requests to the tracker.

A portable identifier is therefore resolved through the local installation's data model. The destination need not share the source installation's numeric primary keys. Relationship descriptors and table metadata identify how references are to be stored or resolved. [Identity](https://architecture.joomlacomponentbuilder.com/markdown/foundations/identity.md)

The local result is a managed definition. A user can subsequently open it in the GUI, revise its properties or code, compile it, and export it again. Import is not merely a temporary network read performed by a string template.

## Reset is an explicit different operation

Reset requests fresh repository material for the selected entity even where a local representation exists. The package builder also distinguishes owned incoming child records from outgoing references to shared definitions.

The inspected recursive reset path forces the refresh of dependencies marked `direction: in`. Those records represent children identified through the selected parent. Outgoing dependencies continue through ordinary acquisition unless explicitly selected for reset themselves. [B02](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b02)

This policy has a concrete purpose. Resetting a component's association record should refresh that component's selected field or view settings. It should not, merely by following a reference, silently overwrite every reusable field or library that another local project also uses.

In a language-neutral implementation, the edge role participates in refresh policy:

$$
\operatorname{mode}(e)=
\begin{cases}
\operatorname{reset}, & \text{selected parent reset and }e\text{ is an owned incoming relation},\\
\operatorname{initialize}, & \text{ordinary referenced dependency}.
\end{cases}
$$

An explicitly selected root can of course request its own reset. The formula describes the inspected recursive distinction, not a universal rule for every import tool.

## Persistence and traversal have separate state

The retrieval services record request guards, local hits, remote results, dependency queues, and diagnostics. The table-aware item service performs the local insert or update. Attempting retrieval, mapping a payload, persisting it, and completing all of its dependencies are different events.

The package builder aggregates result buckets such as local, added, and not found across nested operations. Those collections describe the operations performed; they are not a substitute for a globally transactional success certificate. A record can have been involved in more than one request path, and an acquired parent can still expose a dependency that cannot be resolved.

A precise operational model therefore retains both request state and data state. The [formal resolution chapter](https://architecture.joomlacomponentbuilder.com/markdown/formal/resolution.md) uses `attempted`, `resolved`, and `failed` as separate concepts. They make the source's guards understandable without implying that a guard flag proves a complete record exists.

## Repository dependencies and assets complete the imported design

A component payload may depend on its admin-view associations, site-view associations, module and plugin links, router configuration, and other child records. Views add fields, conditions, relations, tabs, query definitions, and referenced reusable material. Files and folders add the images or code assets named by those records.

The resulting local graph is what compilation consumes. An index file alone cannot reconstruct it. Nor does downloading only the component's root `item.json` guarantee that all its required definitions are already available.

The [Hello World lifecycle](https://architecture.joomlacomponentbuilder.com/markdown/examples/hello-world.md) identifies its root, association records, externally supplied field types, and generated extension products. That trace makes dependency completion inspectable rather than hiding it behind the word *import*.

## The preservation relation

For the supported design projection, export and import aim to preserve entity meaning and references while allowing installation-local storage details to differ. Let $\equiv_B$ denote equality of the normalized blueprint-relevant model. A round trip has the intended relation

$$
\operatorname{import}(\operatorname{export}(D))\equiv_B D
$$

when the selected design graph and required assets are transported, references resolve consistently, and the selected initialization/reset policies admit that result.

This is not raw database equality: omitted credentials, local IDs, editing metadata, and unrelated records need not match. It also is not automatically byte equality of generated output, because output-affecting dates, local GUI markers, target rules, and supplied dependencies are separate inputs. The [transport model](https://architecture.joomlacomponentbuilder.com/markdown/formal/transport.md) states those conditions explicitly.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/blueprints/assets.md

# Assets and repository coordination

An application blueprint includes more than database-shaped records. Definitions can refer to images, compiler input files, library folders, scripts, and other material whose content lives in the filesystem. JCB gives those resources a transport path rather than assuming that every destination installation already contains them.

Repository definitions are themselves managed information. They identify where a particular channel of reusable material can be read and, where authorized, written. The same overall lifecycle therefore coordinates both development definitions and the locations from which definitions are obtained. [B07](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b07), [B08](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b08)

## Asset references retain both identity and destination

An exported file dependency can carry a repository key, a normalized pointer, its original value, an entity kind such as `file`, and a target area. Hello World's admin-view icons demonstrate this directly: an image referenced by the view becomes a transported file dependency associated with the images target.

The content's repository identity and its destination path serve different purposes. A normalized key locates the published content. A target plus a value tells the importer where the content belongs in the local environment. Treating the two as one unconstrained filename would obscure both portability and path handling.

The normalization and content services map those values into the configured targets. Ordinary acquisition can retain an existing local file; forced retrieval can refresh it. The operation records diagnostics for resources that cannot be obtained or placed. [B07](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#b07)

## Files and folders are not ordinary entity rows

Entity payloads are mapped through table-aware persistence. Asset content is written through filesystem services. The package builder drains entity dependencies and then invokes file/folder transport for the accumulated asset requests.

This separation allows the graph to contain both kinds of requirement without pretending they have identical storage semantics. A database insert, an image write, a directory transfer, and an index update can fail independently. Their status belongs to the operation's report.

For a definition graph $G$, write its complete transport requirement as

$$
\operatorname{requirements}(G)=V_G\cup A_G,
$$

where $V_G$ is the selected entity set and $A_G$ the asset set. The union is typed: it does not erase the difference between an entity request and an asset request. A complete import must satisfy each request using its appropriate handler.

## Channels select the appropriate repository contract

The ecosystem separates component packages, Super Powers, Joomla Powers, field types, snippets, and repository definitions into corresponding distribution surfaces. Their indexes have different item schemas and their contents serve different compiler responsibilities.

The public repositories supplied with this edition illustrate those roles. `joomengine/packages` and `joomengine/joomla-packages` distribute application blueprints. `joomengine/super-powers` distributes reusable code definitions. `joomengine/joomla-powers` supplies target-sensitive Joomla class mappings. `joomengine/joomla-fieldtypes` supplies field-type definitions. `joomengine/snippets` carries reusable interface material. `joomengine/repoindex` describes repository targets. [E06](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#e06)

These are examples of the distribution architecture, not a restriction to a centrally owned catalogue. The configured repository list determines which sources a particular installation uses.

## Read and write policy are separate

A read branch supplies definitions for acquisition. A write branch identifies the destination for publication. Entity approval and repository eligibility determine which writes are attempted. Index caching reduces repeated acquisition of the same catalogue within an operation.

The distinction is useful in a review workflow. A developer can consume an accepted definition, make local changes, and publish those changes to an appropriate review destination without redefining the item's portable identity. The branch and revision remain part of the source configuration when reproducibility matters.

The repository API also returns content identifiers used for updates and unchanged-content checks. Those identifiers support repository operations; they should not be confused with proof of authorship or execution safety for the downloaded code.

## External code is another, distinct path

JCB also supports explicit external-code references embedded in code. That mechanism reads a specified resource and applies its own change-history and authorization behaviour. It is not interchangeable with importing a managed Power or field definition from an entity index. [Custom code and external material](https://architecture.joomlacomponentbuilder.com/markdown/compiler/custom-code.md)

The white paper keeps these paths separate because they have different identities, trust decisions, and local persistence. Their shared purpose is to make required material available to compilation; their operational contracts determine how that availability is achieved.

## Reuse beyond the original representation

An implementation in another language can preserve the same architecture with object storage, a package registry, or another versioned transport. It needs typed resource identities, target-aware placement, explicit source selection, and a clear distinction between metadata and executable or display content.

The portability lies in those relationships and operations. It does not depend on retaining JCB's repository folder names or using a particular Git hosting provider. The [implementation guide](https://architecture.joomlacomponentbuilder.com/markdown/engineering/implementation.md) develops that separation while keeping the source-specific behaviour visible in the [source map](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md).


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/compiler/execution.md

# Compiler execution from entry to package

The compiler's execution begins before its final `run` method. Resolving and constructing the compiler service starts timing, initializes the component, and invokes inherited content preparation. The later `run` method completes file updates, custom-code placement, language material, repository output, and packaging. A trace that begins only at `run` omits much of the compilation. [C01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c01)

This distinction is the starting point for the architectural model. The compiler is a coordinated sequence of operations with shared state, not a function name attached to the last filesystem pass.

## Entry and service construction

The authoring interface and command-line entry paths select build configuration and obtain compiler services through the factory and dependency-injection container. Shared services give producers and consumers access to the same build configuration, definition stores, specialised builders, and output-binding environments. Resolving a service can itself construct collaborators whose initialization has effects.

The relevant boundary is therefore the complete build request, including service resolution. A language-neutral implementation can expose a more explicit `prepare` operation, but it must not omit the work performed by the source implementation during construction. [C02](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c02)

## Initialization establishes the working design

The initializer has a once-only guard. Its visible sequence establishes language and field-building settings, recovers designated code from installed targets, loads and enriches the selected component, processes version information, resets the build directory, acquires utility Powers, and builds the required structures.

The order of recovery and reset is significant. Existing designated edits are inspected before the working output is cleared for the new build. Component acquisition also precedes several structure decisions, because the selected views, modules, plugins, and libraries determine which structures are required.

Events bracket parts of this sequence and can modify the effective input. They belong to the operational account, not an unmodeled background layer. [Events and effects](https://architecture.joomlacomponentbuilder.com/markdown/compiler/events.md)

## Content preparation distributes semantic consequences

The content-preparation phase, named *Infusion* in the implementation, establishes shared component bindings and then works through admin views, custom admin views, component-wide aggregates, deferred admin work, configuration fieldsets, site views, and associated extension content.

Its operations do more than fill final text slots. They call creators and architecture services that interpret definitions, collect schema and query information, prepare names and language entries, generate method fragments, and accumulate requirements for subsequent consumers. The [classification](https://architecture.joomlacomponentbuilder.com/markdown/compiler/classification.md), [stores](https://architecture.joomlacomponentbuilder.com/markdown/compiler/stores.md), and [deferred-work](https://architecture.joomlacomponentbuilder.com/markdown/compiler/deferred-work.md) chapters examine this phase in detail.

```mermaid
flowchart TD
  A["Build request and service resolution"] --> B["Start timer and initialize"]
  B --> C["Recover edits and acquire component graph"]
  C --> D["Prepare structures and initial bindings"]
  D --> E["Interpret views and accumulate concern-specific state"]
  E --> F["Complete deferred work and extension content"]
  F --> G["Update staged files and inject resolved code"]
  G --> H["Languages, metadata, repository output, archives"]
  H --> I["Diagnostics and completion timing"]
```

The diagram summarizes semantic responsibilities. It does not imply that all acquisition finishes before the first file is created. Skeleton construction occurs while later semantic work remains, and additional dependencies can be acquired during file updating.

## Final file processing

The final orchestration initializes temporary, backup, and repository paths, applies configured site/API cleanup, and triggers the pre-update event. It then invokes the extension file updater.

The updater handles the relevant static, dynamic, module, plugin, and Power files. Per-file content processing applies shared and contextual bindings, conditional custom-code processing, events, and Power injection before writing. Later custom-code placement can use stored location fingerprints. [Binding](https://architecture.joomlacomponentbuilder.com/markdown/compiler/binding.md), [Custom code](https://architecture.joomlacomponentbuilder.com/markdown/compiler/custom-code.md), [Materialization](https://architecture.joomlacomponentbuilder.com/markdown/generation/materialization.md)

After file updates, the compiler builds language file data, reports language and asset-table messages, handles update XML destinations, generates README material, and writes configured local repository outputs. Component, module, and plugin archives are then produced through their respective paths.

## Completion is a report over several operations

The main orchestration returns failure on a failed extension-file update or component archive operation. Module and plugin packaging have their own processing and messages. Warnings about language mismatches, external code, or recoverable placement remain meaningful even where the principal build returns success.

The paper therefore models a result as artifacts together with diagnostics and effects:

$$
\operatorname{compile}(I)=(A,\Delta,\tau),
$$

where $A$ is the artifact collection, $\Delta$ the diagnostic result, and $\tau$ the relevant execution trace. A single Boolean is useful to the calling interface but does not express every detail of those outcomes.

On the successful path, the timer stops after the final packaging and notices. The elapsed measurement consequently includes initialization and content preparation, not merely the last placeholder replacement. [Build measurements](https://architecture.joomlacomponentbuilder.com/markdown/engineering/performance.md)

## What the sequence explains

The sequence makes the compiler's coordination visible. Definitions become available before their dependent interpretation; some interpretations contribute facts that later creators require; contextual bindings are established before their consumers; physical files pass through several stages before becoming packaged products.

That is why the implementation cannot be adequately explained as one loop over templates. Its behaviour depends on the state accumulated across those responsibilities and on the points at which incomplete work becomes ready to finish. The [formal state model](https://architecture.joomlacomponentbuilder.com/markdown/formal/state.md) expresses the same execution as transitions over identified state components.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/compiler/acquisition.md

# Acquiring and enriching the application model

The database representation is not already arranged in the form required by every generator. Component records refer to child configurations and views; views refer to fields and query definitions; fields refer to types, rules, and custom behaviour. Acquisition follows those relationships and enriches the records into forms that the compiler can use.

JCB combines root queries, nested loading, reusable definition caches, normalization, history processing, and conditional remote retrieval. The result is a contextual application model, not merely a list of rows copied from the database. [C03](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c03), [C04](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c04)

## Root acquisition and enrichment

The component-data service loads the selected component together with related configuration and then applies a sequence of modeling operations. These establish identity and naming information, version and history state, files and libraries, admin and site view relationships, custom code, configuration, update material, modules, plugins, and routing choices.

The sequence matters. A component's selected admin views determine field-related and generated-table work that later operations consume. Module and plugin relationships determine which additional extension data and structures must be prepared. Code fields may need decoding and custom-code processing before they can be retained for later use.

The enriched model is stored through the component service. Consumers can retrieve its established properties without repeating the original joined acquisition for every output fragment. This is reuse at the component-data boundary, not a claim that all subsequent interpretation is context-free.

## A view association is more than a view identifier

An association identifies the reused view and carries the settings of its use in the component. The view's own settings in turn identify its field associations, conditions, relations, tabs, scripts, and other behaviour.

This nested organization lets common definitions remain reusable while particular uses supply their own roles. It also means the acquisition graph and the occurrence structure must not be confused. Loading a field definition once can be correct even when the compiler still needs to process that field under several view contexts. [Identity](https://architecture.joomlacomponentbuilder.com/markdown/foundations/identity.md)

## Field data separates base identity from contextual consequences

The field loader supports lookup by ID or GUID and maintains an index connecting both forms to an acquired field object. When a valid GUID cannot be found locally, a guarded package-retrieval attempt can populate the local data and allow a retry.

The retrieved field is enriched with its field-type information, decoded XML, validation-rule handling, storage treatment, history, and other compiler settings. Subsequent retrieval also invokes field-specific custom-code handling with the current single and list view names. [C04](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c04)

The distinction is important: the cached object is not a frozen, completely context-free semantic value. The implementation can update and interpret it as part of retrieval. Its architecture is better represented as a reusable base definition plus controlled contextual processing than as a pure memoized function of the field GUID alone.

A language-neutral decomposition is

$$
d=\operatorname{loadBase}(u),\qquad
(d',c)=\operatorname{prepareUse}(d,\Gamma),
$$

where $c$ contains any additional contributions and $d'$ the prepared representation used by the next stage. Whether $d'$ shares physical storage with $d$ is an implementation choice that must be understood when reasoning about mutation.

## Guards distinguish repeated work from repeated meaning

Field custom-code processing records which field scripts have already contributed to a view. It also tracks decoding and prepares scripts through the dispenser. Those guards avoid duplicate contributions while still permitting the same field to participate in another view.

Power acquisition similarly has load-state guards around recursive references. Package acquisition has attempt guards and queues. These mechanisms share a purpose—controlling repeated work—but have different keys and lifetimes. One cannot infer their exact semantics from the word *cache* alone. [Stores](https://architecture.joomlacomponentbuilder.com/markdown/compiler/stores.md), [Powers](https://architecture.joomlacomponentbuilder.com/markdown/compiler/powers.md)

For a reusable operation $f$, the cache key must cover the inputs whose changes can alter $f$'s result. For an effectful operation that adds scripts or language entries, the guard must also match the intended contribution scope. The [classification model](https://architecture.joomlacomponentbuilder.com/markdown/formal/classification.md) separates those cases.

## Absence can trigger work

A missing local definition is sometimes an instruction to acquire it, rather than an immediate terminal failure. A missing derived value can trigger preparation or a default. A missing optional feature can mean no contribution should be generated. These are different interpretations of absence.

The source's guards and branch conditions determine which case applies. For example, a remote field retry is limited by identity and attempt state. A configuration default is selected by a different path. The formal model uses distinct transitions instead of treating every missing value as a single generic recollection operation.

## The acquisition boundary remains open where the implementation requires it

Some dependencies become visible only while processing code, templates, or Power references later in compilation. The architecture therefore does not require one universal acquisition pass that resolves every possible dependency before output preparation begins.

The practical rule is narrower: a consumer must obtain the information it actually requires at the point its operation uses that information. Early acquisition and shared caches reduce repeated work; late discovery handles dependencies exposed by later interpretation. [Deferred work](https://architecture.joomlacomponentbuilder.com/markdown/compiler/deferred-work.md), [Binding](https://architecture.joomlacomponentbuilder.com/markdown/compiler/binding.md)

The [source map](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md) links these responsibilities to their services. The next chapter follows acquired definitions into the concern-specific contributions that constitute the compiler's central semantic work.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/compiler/classification.md

# Semantic classification and routing

The compiler's central operation is to examine a definition in context and distribute its consequences to the places that will need them. This is semantic classification and routing: deciding what the definition means for each concern, retaining the relevant result under an appropriate key, and allowing later consumers to assemble the final artifacts.

The operation is more than sorting values into an order. A field contributes different information to a schema, a form, a list, a query, a language catalogue, and a runtime metadata map. Those contributions share an origin but are not interchangeable copies. [C05](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c05)

## One field, several interpretations

JCB's field-building collaborators handle database properties and keys, list membership, joined fields, history, aliases, titles, field relations, hidden and integer fields, storage conversion, categories, tags, custom field links, scripts, sorting, searching, filtering, layouts, language strings, and the generated component-field map.

Not every field activates every branch. Its type, configuration, view association, target, and selected features determine the contributions. The Greeting example activates a small but visible subset: column definition, title and list behaviour, sorting, search participation, form attributes, language entries, and table metadata. [Field trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/field-trace.md)

The architectural value is that these effects are derived together from the same identified use. The developer does not need to remember every destination and manually restate the decision in each generated file.

## Contributions have different types and update rules

Represent the interpretation as an ordered sequence

$$
J(d,\Gamma)=\langle c_1,\ldots,c_m\rangle,
\qquad c_i=(s_i,k_i,\omega_i,v_i).
$$

Here $s_i$ selects a store, $k_i$ a key, $\omega_i$ an update operation, and $v_i$ a value. An update may replace a known binding, append a list member, concatenate a fragment, set a requirement flag, or enqueue a later operation.

The operation is part of the contribution's meaning. Replacing a title binding is not equivalent to appending a searchable field. Concatenating method fragments is not equivalent to deduplicating a set of dependencies. The mathematical representation retains those distinctions rather than turning every intermediate store into a set of facts.

The accumulated state after interpreting a use is

$$
M'=\operatorname{apply}(\langle c_1,\ldots,c_m\rangle,M).
$$

When two contributions update the same key, their prescribed operation and sequence determine the result. The source uses explicit orchestration; it does not require arbitrary reordering to be harmless.

## Fan-out and fan-in are both present

A field's consequences fan out into several stores. Later, a schema emitter combines contributions from many fields into one table definition. A list model combines selected columns, joins, filters, search clauses, ordering rules, and custom methods. A form combines standard fields, application fields, fieldsets, conditions, permissions, and layout choices.

This is a many-to-many relationship between definitions and outputs. A registry is the physical representation of part of that relationship, not its complete explanation.

```mermaid
flowchart LR
  F["Field definition and view association"] --> S["Schema and keys"]
  F --> Q["Selection, search, and ordering"]
  F --> U["Form and layout roles"]
  F --> L["Labels and language entries"]
  F --> P["Configured permission behaviour"]
  S --> A["Coordinated generated artifacts"]
  Q --> A
  U --> A
  L --> A
  P --> A
```

The diagram shows possible concern families. A specific build follows only the branches enabled by its definitions and rules.

## Derived names retain use-site context

A field's logical name can require normalization and collision handling within a view. JCB's naming services track names within their scope and allocate suffixes where repeated uses would otherwise collide. The resulting name is then reused by downstream schema, query, form, and metadata consumers. [C04](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c04)

The scope is crucial. Two unrelated views may each use a field named `title` without needing a globally unique application-wide field name. Conversely, two conflicting occurrences in the same generated scope may need distinct names even when their reusable definitions are individually valid.

A language-neutral implementation should retain the resolved name as a contribution of the occurrence. Recomputing it independently in each emitter risks selecting different suffixes or prefixes.

## Relations can transform values or presentation

The documented field-relations feature distinguishes model-side processing from view-side composition. Combining raw values before or after model treatment is different from combining the generated presentation of those fields. The latter can include links, formatting, and permission-related structure. [D01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#d01), [C05](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c05)

This is another example of contextual classification. The same referenced field is interpreted under the role selected for the relation. Calling every relation “a join” would obscure whether the operation changes the query, the modeled value, or the final display fragment.

## What consistency means here

The compiler aims to keep projections of one design decision aligned. A resolved field name should agree across its form and data paths. A storage treatment should agree between save and load logic. A language key emitted into a form should have the intended catalogue entry. A target-specific class reference should agree with its namespace and imports.

These are concrete cross-artifact relationships, not a claim that every generated application has been formally verified. The [formal classification chapter](https://architecture.joomlacomponentbuilder.com/markdown/formal/classification.md) states how such relationships can be expressed and checked. The public worked examples show selected relationships in actual output.

Classification makes a compact blueprint effective because repeated implementation knowledge already resides in the compiler's rules. Its output is not information created from nothing: it is the contextual assembly of design choices, generation knowledge, reusable code, and supplied assets.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/compiler/stores.md

# Intermediate stores and information lifecycle

JCB retains information in several kinds of intermediate store. Their physical representations often use arrays or registry services, but their architectural responsibilities differ. Understanding those responsibilities explains what is remembered, how it is addressed, and why it remains available to a later consumer.

A shared map is useful because it connects producers and consumers. A complete explanation must additionally name the value's origin, scope, update operation, readiness, and lifetime. [C02](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c02), [C06](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c06)

## A taxonomy of retained state

| Store role | Typical retained value | Why it is retained |
| --- | --- | --- |
| Definition cache | Acquired field, view, or Power data | Avoid repeated acquisition and preserve identity |
| Concern-specific builder | Schema properties, searchable fields, language requirements, aliases, or method contributions | Collect information for a later generator |
| Contextual code dispenser | Prepared custom code indexed by role and use-site | Delay retrieval-time binding until the correct context exists |
| Output-binding environment | Shared and view/extension-specific placeholder values | Supply a defined stage of file materialization |
| Deferred-work collection | Operation identity and arguments | Complete work after other contributions become available |
| Processing state | Attempted requests, per-view contribution guards, loaded-state flags | Prevent repeated work or recursive re-entry |

These roles can coexist in one build. They should not be collapsed into a universal cache or a single undifferentiated “memory.” The same implementation type can serve different roles, and a role can be implemented by another data structure in a different language.

## Keys express the intended scope

Some stores use a definition ID or GUID. Others use a view name, extension key, target area, field name, or a combination. `ContentOne` models shared content keys as placeholder keys. `ContentMulti` separates a view or extension scope from the placeholder name through its key convention.

This permits a shared component binding and a view-specific method fragment to be retrieved differently even if both are ultimately inserted into text. A schema field list and an output placeholder map are also distinct: one describes what must be rendered, while the other supplies already prepared material to a binding stage. [C06](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c06)

For a store $M_s$, write its address space as $K_s$ and its value space as $V_s$:

$$
M_s:K_s\rightharpoonup V_s.
$$

The partial function means an address may not yet have a value. It does not prescribe physical memory addresses, heap allocation, or a particular registry library.

## Updates are not all monotone accumulation

The registry abstraction supports operations such as setting, getting with a default, checking existence, removing values, and adding content according to the configured operation. Builders can append members or concatenate fragments; other consumers replace bindings as they move to another file or context.

For example, file content processing sets the current filename binding before handling a file. That is an intentional state change associated with the current artifact. It is not a newly discovered immutable fact that should remain true for every later file.

Consequently, an accurate state model includes replacement and removal as well as accumulation. A finite monotone closure model can describe a bounded dependency set, but it cannot by itself describe every production registry update. [Formal state](https://architecture.joomlacomponentbuilder.com/markdown/formal/state.md)

## Readiness belongs to the producer-consumer relationship

A value can be present without being ready for every possible use. A prepared custom-code fragment can still contain context-sensitive placeholders. A partial aggregate can exist before all of its member contributions have been processed. A recursive load guard can be present while its definition is still being prepared.

The relevant condition is

$$
\operatorname{ready}(v,o,\Sigma),
$$

meaning that value $v$ is ready for operation $o$ in state $\Sigma$. JCB often enforces readiness through the sequence of calls and phases rather than attaching an explicit readiness type to every stored value.

The [deferred-work chapter](https://architecture.joomlacomponentbuilder.com/markdown/compiler/deferred-work.md) shows the case where that sequence is made especially visible: work is retained precisely because its consumers' prerequisites are not yet complete.

## Retrieval can perform interpretation

The dispenser retrieves code under active placeholders, adds requested surrounding text, and can remove an entry after use. A field loader can perform per-view code processing when returning a cached field. Retrieval is therefore sometimes an operation, not merely a raw map lookup. [C04](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c04), [C09](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c09)

This behaviour explains the recollection analogy in ordinary engineering terms. The system retains an identified representation, then recalls and interprets it when a particular consumer needs it. No claim about biological memory is needed to describe that useful separation.

## Lifetime and shared services

The service container ensures that the relevant producers and consumers share instances during the build. Per-build definitions, guards, bindings, and aggregates should be understood within that lifecycle. Reusing a compiler container across independent build configurations requires the reset discipline of the calling workflow; otherwise, target selection and retained state can outlive their intended context.

A portable implementation can choose explicit context objects and build-owned store collections instead. It still needs the same answers: who writes a value, who reads it, which key identifies it, when it becomes authoritative for that consumer, and when it is replaced or discarded.

Intermediate stores make the coordination economical. They also consume memory and create ordering obligations. The [cost account](https://architecture.joomlacomponentbuilder.com/markdown/engineering/performance.md) and [implementation guide](https://architecture.joomlacomponentbuilder.com/markdown/engineering/implementation.md) examine those tradeoffs without assuming that retaining every value is always preferable.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/compiler/deferred-work.md

# Deferred work and staged readiness

Some generation work becomes known before all information needed to finish it is available. JCB records that work and completes it at an appropriate later point. The operation is not forgotten, and the compiler does not have to restart the entire build merely because one relationship depends on later interpretation.

Linked admin views and configuration fieldsets provide concrete examples. They expose the difference between the time a requirement is discovered and the time its output can be completed. [C07](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c07)

## A requirement can be discovered early

While processing an admin view, the compiler can discover that a linked view requires further generation. Information about the other views, names, fields, or related fragments may still be under construction. Completing the linked-view output too early could use an incomplete aggregate or lack the necessary interpretation of the linked target.

The inspected implementation retains deferred admin work in `secondRunAdmin`, grouped by the operation to call and its argument arrays. After the earlier admin and component-content work, Infusion iterates those stored operations and invokes them. This is an explicit replay point in the actual execution sequence.

The architectural unit being retained is therefore not only a value. It is **an operation with the information needed to perform it later**.

## The phase boundary supplies the readiness guarantee

For a deferred operation $w$, define $\operatorname{req}(w)$ as the information it needs. Let $\operatorname{avail}(\Sigma)$ denote information established for the relevant use in state $\Sigma$. Its execution condition is

$$
\operatorname{req}(w)\subseteq\operatorname{avail}(\Sigma).
$$

The mathematical condition describes the dependency. In the source, the orchestrated replay point supplies the intended readiness: the earlier passes have processed the structures on which the later work relies. JCB does not require a generic scheduler that repeatedly tests every arbitrary task until it becomes runnable.

A corresponding language-neutral sequence is:

```text
for each admin-view occurrence:
    establish its local interpretation
    emit immediately available contributions
    retain linked work whose later inputs are not yet complete
complete component-wide admin aggregates
for each retained operation in the defined order:
    complete its linked contribution
continue with the next generation phase
```

This preserves the source's staged organization. A different implementation could use explicit task dependencies, but that would be a representation choice rather than evidence that JCB already uses such a scheduler.

## Configuration fieldsets have a deliberate second pass

Infusion prepares configuration fieldsets earlier and calls the fieldset creator again with its second-pass selector after deferred admin work. It temporarily sets the language target to the admin area for this operation and restores the prior value afterward.

The second call is not an accidental duplicate. It gives the fieldset machinery a point at which information accumulated during the earlier build can participate in completion. Its argument identifies the intended pass. [C07](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c07)

This illustrates a useful distinction: **repeating a selected operation under a later readiness condition** is different from indiscriminately repeating the whole compiler until output stops changing.

## Deferred work, lazy acquisition, and late binding differ

Deferred work postpones an operation. Lazy acquisition obtains a definition when first needed. Late binding substitutes a value when the appropriate output context is available. All involve time, but they solve different problems.

A Power discovered during file processing may require late acquisition. A prepared custom-code block may wait for view-specific placeholders before retrieval. A linked admin-view operation may be queued until other view information is established. Combining them under one word such as *recursion* would hide the actual contracts.

The [acquisition](https://architecture.joomlacomponentbuilder.com/markdown/compiler/acquisition.md), [stores](https://architecture.joomlacomponentbuilder.com/markdown/compiler/stores.md), and [binding](https://architecture.joomlacomponentbuilder.com/markdown/compiler/binding.md) chapters explain the other cases. The complete compiler uses these mechanisms together.

## Ordering remains meaningful

If two retained operations update the same store, their order and update semantics can affect the result. The source's replay order is therefore part of its operation. A mathematical account can establish repeatability for a fixed sequence without claiming that every possible permutation has the same result.

For operations $f$ and $g$, schedule independence would require an appropriate commutation property such as

$$
f(g(\Sigma))=g(f(\Sigma)).
$$

Where that property has not been established, the specified order remains the contract. The white paper does not confuse deterministic orchestration with unrestricted confluence.

## Why this mechanism matters

Deferred work allows the compiler to preserve locality of discovery without demanding premature completion. The code that recognizes a relationship can record what must be done; a later stage can complete it once the broader context exists. Intermediate state carries the connection across that interval.

This is one of the clearest examples of the architecture's “remember now, use later” behaviour. Its value lies in the explicit relationship between identity, stored arguments, prerequisite information, and the point of consumption—not in the mere existence of another loop.

The [formal staging model](https://architecture.joomlacomponentbuilder.com/markdown/formal/staging.md) and [reference mechanisms](https://architecture.joomlacomponentbuilder.com/markdown/engineering/reference-model.md) make the same distinction executable on a small example.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/compiler/binding.md

# Binding in ordered stages

A reusable code fragment can contain names that depend on the extension, view, or target where it will be used. JCB retains such material and applies the appropriate binding environment when that context is available. It also fills file skeletons using shared and context-specific content accumulated by earlier generation work.

These are staged binding operations. The stages matter because a value inserted by one operation can still contain tokens handled by another. The exact replacement semantics determine what happens within each stage. [C06](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c06), [C08](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c08)

## Shared bindings and use-site bindings

`ContentOne` supplies shared material such as component identity, author information, versions, and common generated fragments. `ContentMulti` supplies bindings associated with a view or extension key. The per-file writer sets the current filename and applies shared content before the selected contextual content.

Prepared custom code can also be bound when retrieved from the dispenser. This allows one stored fragment to use the placeholders active for its destination rather than fixing all names at initial storage time. [C09](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c09)

For a staged artifact $a_i$ and binding environment $P_i$, write

$$
a_{i+1}=\sigma(a_i,P_i).
$$

The environment is authoritative for that stage. The complete artifact is produced by a defined sequence of these operations together with other transformations such as code expansion, header processing, and dependency injection.

## Replacement within a pass is ordered

The inspected placeholder service uses array-based ordered string replacement. For a map presented as the ordered sequence

$$
P=\langle(k_1,v_1),\ldots,(k_n,v_n)\rangle,
$$

its ordinary replacement is

$$
s_0=s,\qquad
s_i=\operatorname{replaceAll}(s_{i-1},k_i,v_i).
$$

Later entries can therefore replace tokens introduced by earlier entries. This differs from simultaneous substitution, where all matches are selected from the original input and replacements are not revisited during that pass.

JCB's implementation gives the operation three action modes. The ordinary mode performs replacement. A presence-check mode skips work when none of the keys occurs. The filtered mode first removes entries whose keys do not occur in the original input, then performs ordered replacement with the remaining entries. [C08](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c08)

## Filtering the map changes introduced-token behaviour

Consider the ordered map `A → B`, `B → x`.

| Input and mode | Selected entries | Result |
| --- | --- | --- |
| `A`, ordinary replacement | Both entries | `x` |
| `A`, original-input filtering | Only `A → B` | `B` |
| `A B`, original-input filtering | Both entries | `x x` |

The filtered mode does not remove unknown placeholders from the output. It removes unused entries from the replacement map before applying that map. This distinction is essential when describing later binding stages or testing an implementation in another language.

The [reference mechanisms](https://architecture.joomlacomponentbuilder.com/markdown/engineering/reference-model.md) exercise these cases directly. A reimplementation that silently substitutes a simultaneous or recursive replacement algorithm would change the represented semantics.

## File processing has several ordered transformations

The per-file service reads the staged file, processes its PHP header and BOM convention, applies shared bindings, applies contextual bindings when a context is supplied, conditionally updates custom code, triggers the pre-write event, resolves Power and Joomla Power references, and writes the result. Power source files have a selected bypass around the ordinary shared binding path. [C19](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c19)

The sequence can be represented as a composition:

$$
\operatorname{write}\circ\operatorname{inject}\circ\operatorname{event}
\circ\operatorname{custom}\circ\sigma_{\Gamma}\circ\sigma_{\mathrm{shared}}.
$$

Each operation has its own condition and input. The expression captures the inspected order; it is not an assertion that all of these operations are pure functions. Events, dependency retrieval, counters, and file writes have effects recorded in the [state model](https://architecture.joomlacomponentbuilder.com/markdown/formal/state.md).

## Newly exposed work belongs to a later operation

A custom-code expansion can expose a Power reference. A template can introduce a placeholder handled by a subsequent binding environment. A file update can require a library definition that was not previously active. JCB's sequence gives such work designated processing points.

This explains why generation need not be a single substitution over a complete final dictionary. The compiler can prepare some values early, keep other fragments contextual, and perform selected discovery and injection later.

The corresponding ordering obligation is straightforward: a token or dependency must have an applicable consumer after the operation that introduces it. Repeating replacement indefinitely is a different algorithm with different termination and escaping behaviour. The paper describes the actual selected stages instead. [Formal staging](https://architecture.joomlacomponentbuilder.com/markdown/formal/staging.md)

## Contextual names make reuse concrete

The Hello World plugin definition uses a component placeholder in its name. When included under the component context, the generated plugin receives the corresponding resolved identity and files. Custom code similarly reaches its designated model, controller, view, or installer position with the destination's active names. [Extension trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/extension-trace.md), [Custom-code trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/custom-code-trace.md)

The reuse is therefore semantic as well as textual: the same stored representation can be interpreted for its use-site. The compiler's naming, namespace, and role decisions must already agree with the environment supplied to that stage.

Staging gives this process an inspectable order. It also explains where a value remains unresolved and which operation is responsible for completing it. That is the useful abstraction to carry into another implementation language.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/compiler/custom-code.md

# Custom code, dispensers, and recovery

JCB combines structured generation with explicitly authored code. A developer can place code in defined GUI areas, refer to reusable custom-code records, include selected external material, or preserve designated modifications in installed output. These paths meet the compiler at different points and retain different kinds of identity.

The architecture does not treat custom code as an unstructured exception pasted onto the end of a generated application. It prepares, indexes, contextualizes, and places that code through services connected to the same build state used by the generators. [C09](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c09)

## Preparation and later retrieval

The dispenser's setter can decode stored content, process custom and external references, add GUI-linked markers, process dynamic hashing and encoded-string conventions, and retain the resulting script under role and use-site keys. Its update policy can replace or append content.

Retrieval is a later operation. The dispenser applies the currently active placeholders, adds requested prefix, note, and suffix material, and can remove the stored entry after consumption. A fragment can consequently be prepared before all destination-specific names are fixed.

Write this as

$$
q=\operatorname{prepare}(c,\kappa),\qquad
M[r,o]\leftarrow q,
$$

$$
c'=\operatorname{decorate}(\sigma(q,P_\Gamma),\eta).
$$

Here $\kappa$ selects preparation options, $(r,o)$ identifies role and occurrence, $P_\Gamma$ is the retrieval-time environment, and $\eta$ selects surrounding material. The state update and later interpretation are separate responsibilities.

## Reusable custom-code records

A custom-code reference can identify a record by numeric ID or function-name alias. The service retains resolved alias-to-ID information and supports argument-bearing references. It loads the selected code and substitutes it according to the configured convention.

Hello World's README design refers to `readMEcontributors`. Its portable identity is the function name, and its generated contribution appears inside the final README rather than in an executable class. That example demonstrates that the same code-distribution machinery can contribute to documentation as well as runtime source. [Custom-code trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/custom-code-trace.md)

The custom-code update sequence processes external content, reusable custom-code references, language extraction, and discovery of Power and Joomla Power references. Expansion can therefore expose further dependencies that join the compiler's existing acquisition and injection paths.

## GUI-linked regions retain a local editing address

When marker generation is enabled and the required configuration is present, GUI code can be wrapped with a marker identifying its table, property, and local record ID. These addresses allow subsequent recovery to reconnect an edited region to the corresponding GUI-backed value.

A GUI marker is a local recovery address. Its numeric record component need not be identical in two installations containing equivalent portable blueprints. The field or view GUID and the GUI region's local address serve different purposes. [Identity](https://architecture.joomlacomponentbuilder.com/markdown/foundations/identity.md)

The public examples deliberately place recognizable comments in several GUI code areas. The generated outputs show those comments at the intended model, controller, view, or installer locations. Their trace is stronger than a generic claim that “custom code is supported,” because it connects a particular stored property to its actual consumer.

## Recovery precedes the new build's reset

The initializer invokes custom-code extraction before rebuilding the component and resetting the build directory. The extractor scans eligible file types in active installed targets, recognizes its marker families, delegates GUI-region recovery, and captures code together with location information and surrounding fingerprints.

Captured content is reverse-transformed where required before being stored back in local records or update buffers. This can restore reusable placeholder forms rather than preserving only the fully specialized names from the previous output. The exact marker family and reverse operation determine the representation retained. [C01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c01), [C09](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c09)

This path differs from installed-component extrusion. Recovery follows designated code addresses established by the generation workflow; extrusion analyzes a broader set of artifacts to reconstruct candidate definitions. [Extrusion](https://architecture.joomlacomponentbuilder.com/markdown/extrusion/overview.md)

## Placement includes an explicit recovery fallback

Stored custom-code placement uses recorded location context and fingerprints to find an insertion or replacement position in newly generated files. When the surrounding structure still matches, the code can be placed at that position despite changes elsewhere in the file.

If the required context cannot be matched in an existing target file, the compiler invokes its escaped-code path: it retains the code as commented material and emits a warning naming the file and recorded location. The developer can reposition the code, remove the comments, and compile again. A missing target file has a separate diagnostic path. [C09](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c09)

The mechanism distinguishes automatic executable placement from recoverability. It avoids treating an uncertain location as permission to execute a fragment in an arbitrary place. The fallback is part of the operational design, not an undefined failure outside the model.

## External resources have their own acceptance policy

An explicit external-code reference identifies a URL or local path and can specify a line-cutting convention. The service caches fetched content within the active operation and compares its hash with recorded history.

In the inspected implementation, new or changed external content requires administrative authorization. Authorized acceptance updates the recorded hash and emits a notice; an unauthorized new or changed resource is excluded with an error. This is change detection and acceptance policy. The hash is not a digital signature or proof that the source is safe. [C09](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c09)

This path is distinct from importing a managed entity through a repository index. The identity is a resource reference, and the acceptance decision concerns its content history.

## The preservation relation is bounded and explicit

For an admitted marker structure, recovery can be described as a partial extraction function

$$
X:A\rightharpoonup M,
$$

where $A$ is an artifact collection and $M$ the recovered designated code. Marker identity, supported syntax, reverse transformation, and target availability define the domain.

A round-trip law must name the representation being preserved. Exact body equality is appropriate only when no intervening transformation changes the body. Where generation specializes placeholders and recovery reverses them, equality concerns the corresponding canonical code representation. [Formal transport](https://architecture.joomlacomponentbuilder.com/markdown/formal/transport.md)

The useful capability is a controlled path for authored decisions to re-enter regeneration. It operates alongside declarative model changes, dependency reuse, and target-aware generation, while the compiler remains the coordinating centre.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/compiler/powers.md

# Powers, namespaces, and code placement

A Power is a managed reusable code definition. Its stable identifier allows application code and other definitions to refer to it without fixing every physical namespace, import alias, and destination at the point of reference. The compiler resolves the definition, interprets its dependencies and context, and places the resulting code where the generated application needs it.

The mechanism joins repository distribution to compilation. Acquiring a Power supplies local editable knowledge; compiling it resolves how that knowledge participates in a particular product. [C10](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c10)

## Acquisition and recursive preparation

The Power loader checks its active and processing state, attempts to load the GUID-addressed definition from local data, and can invoke repository retrieval when that definition is missing. A successful acquisition permits a guarded retry after local persistence.

Preparation processes namespace information, inheritance and interface relationships, imports, load selections, headers, main code, and relevant packaging or reusable-library metadata. References can lead to other Powers. A processing marker is established around recursive work so that a cycle does not simply re-enter the same definition forever.

The state distinction is essential: an item being processed and an item whose preparation has completed are different states. The [resolution model](https://architecture.joomlacomponentbuilder.com/markdown/formal/resolution.md) expresses this without pretending that a single Boolean proves all dependencies are ready.

## Reference identity is separated from the final symbol

A Power key embedded in a code fragment identifies a reusable definition. During injection, the compiler scans for those keys, resolves the corresponding definitions, examines the file's existing import statements and trait uses, and constructs a per-file replacement map.

The resulting local symbol can reuse an existing alias or receive a distinct name where another import already occupies the desired short name. The injector then adds required import statements and replaces the Power keys. Its per-file maps are reset for each file, because import naming is a file-level context. [C10](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c10)

Formally, let $u$ identify a Power and $F$ the destination file context:

$$
\operatorname{resolveSymbol}(u,F)=
(\text{qualified name},\text{local name},\text{required import}).
$$

The qualified name and local alias need not be equal. Retaining that distinction allows two classes with the same final short name to participate in one file through explicit aliases.

## Namespaces also determine physical placement

The Power's namespace and placement settings are processed into output paths. Structure building creates the required directories, skeleton source files, and supporting material, records those files for later content updates, and avoids rebuilding already handled Powers.

Some Powers live in reusable library locations. Source-oriented placement can target the extension's own source namespace, supplying an additional class or a deliberate replacement for a generated class. The official documentation describes the relationship between component, module, or plugin namespace roots and their generated source trees. [C10](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c10), [D01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#d01)

A complete-class replacement is a different ownership choice from a small marked method insertion. When a definition supplies the whole class, the author controls that class's implementation. Future changes to the default emitter do not automatically rewrite the replacement's internal logic. This is a consequence of the selected extension mechanism, not a contradiction of regeneration.

## Joomla Powers resolve target-platform references

Joomla Powers represent references to Joomla classes and their version-sensitive namespace/type mappings. The loader selects a mapping for the compile target, with the configured default where applicable. The identifier can therefore remain stable while the generated import follows the target's class arrangement.

This separates three things: the application's intent to use a particular platform capability, the class mapping for the selected Joomla generation, and the local name used in a particular emitted file. [Target selection](https://architecture.joomlacomponentbuilder.com/markdown/compiler/targets.md)

The mapping data is itself distributed in the public `joomengine/joomla-powers` repository. Reusable code definitions and platform-reference mappings are related distribution concepts, but their payloads and generation responsibilities differ. [E06](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#e06)

## Dependencies can be discovered late

Custom-code expansion and final file processing can expose Power keys after earlier model acquisition. The file updater and associated Power services perform the additional preparation and output work needed by those discoveries.

The important invariant is consumer readiness: the final symbol and required supporting code must be resolved for the output that uses them. The architecture does not require every possible Power to be loaded before the first skeleton file exists.

This is why the compiler's acquisition and materialization boundaries overlap in time. It can preserve early reusable work and still respond to dependencies revealed by later interpretation. [Execution](https://architecture.joomlacomponentbuilder.com/markdown/compiler/execution.md), [Binding](https://architecture.joomlacomponentbuilder.com/markdown/compiler/binding.md)

## Managed reuse is more than copying source

The combined operation includes stable identity, repository selection, local persistence, editable definitions, recursive relationships, namespace resolution, import collision handling, source placement, and output registration. Copying a source file provides only one part of that process.

A language-neutral implementation can use another module system, linker model, or package representation. It needs an equivalent separation between definition identity, target-qualified implementation, file-local symbol selection, and physical inclusion. The [implementation guide](https://architecture.joomlacomponentbuilder.com/markdown/engineering/implementation.md) uses those roles rather than requiring another language to imitate PHP namespaces literally.

The public Power and Joomla Power repositories supply inspectable instances of this managed-reuse model, while the official compiler shows how the definitions become part of generated applications.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/compiler/targets.md

# Host, target, and architecture selection

JCB runs inside a Joomla installation and generates extensions for a selected Joomla target. These are distinct contexts. The host supplies services used to execute the compiler; the target determines the conventions of the generated application.

The architecture makes this distinction operational through configuration, templates, architecture services, and version-sensitive mappings. The inspected compiler contains target families for Joomla 3, 4, 5, and 6. Individual features and emitters follow their supported target contracts. [C21](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c21)

## One model, selected implementation rules

A blueprint can retain the application's fields, views, relationships, queries, and custom intent while the compiler selects target-specific generation rules. For a normalized model $D$ and target $T$, write

$$
A_T=\operatorname{compile}(D,\Theta_T,C,H),
$$

where $\Theta_T$ denotes the selected target rules and supplied target material. Changing $T$ changes the implementation conventions applied to the same represented application intent.

This does not imply that arbitrary target-specific custom code automatically becomes portable. A blueprint that embeds platform-specific calls still contains those calls unless a mapping or transformation handles them. Target portability is strongest where the model uses the compiler's represented abstractions and version-aware references.

## Logical services select concrete emitters

The architecture service providers register concrete implementations for supported Joomla generations and expose logical services to consumers. When a consumer requests a model, controller, view, module, or plugin operation, the provider selects the implementation using the compile-target configuration.

The module architecture provider, for example, registers version-specific services and resolves its logical operation against the configured Joomla version. This keeps a consumer's responsibility separate from the details of each target implementation. [C21](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c21)

A language-neutral description is

$$
\operatorname{service}(r,T)=\Theta_T[r],
$$

where $r$ is a generation responsibility. The responsibility remains stable while its implementation changes with the target.

## Shared service lifetime matters

Target-specific service selection can be cached in shared provider state. The selected target must therefore be established before those services are resolved, and independent builds must respect the calling workflow's reset boundaries.

An implementation should not assume that changing a configuration value after target services have already been created will reconstruct all of them automatically. The source's service lifecycle is part of the execution model. [Stores](https://architecture.joomlacomponentbuilder.com/markdown/compiler/stores.md), [Events](https://architecture.joomlacomponentbuilder.com/markdown/compiler/events.md)

This is a general lesson of configuration-driven dispatch: a target is both an input value and a selection boundary for the objects or functions that implement it.

## Symbol mappings complement emitter selection

Joomla Powers select the appropriate namespace and type for a stable platform-reference identifier. Templates and emitters select structural conventions. Together, these mechanisms handle different dimensions of target adaptation.

A generated plugin may need a particular service-provider arrangement as well as the correct imported platform class. A model may need a target-specific method body and a target-appropriate form or routing convention. A single textual version placeholder cannot express all of those differences; distinct architecture responsibilities can. [Powers](https://architecture.joomlacomponentbuilder.com/markdown/compiler/powers.md), [Extensions](https://architecture.joomlacomponentbuilder.com/markdown/generation/extensions.md)

## Build area is another axis

Within a component, administrator, site, and API areas have different responsibilities. Modules can target their configured client. Plugins belong to a group and have their own extension context. The compiler establishes build and language targets as it moves through those areas.

The complete context is therefore more informative than a Joomla version number alone. It includes the extension kind, area, namespace, view role, and applicable configuration. The [context model](https://architecture.joomlacomponentbuilder.com/markdown/foundations/context.md) records those dimensions separately.

## Regeneration carries shared platform knowledge

When a target emitter or reusable mapping is updated, applications that use that represented mechanism can receive the change on regeneration. The implementation decision is maintained in the compiler or reusable definition rather than repeated by hand in each generated project.

The maintenance effect is conditional on the application's ownership choices. Default-generated regions follow the changed rules. Deliberate complete-class overrides and arbitrary embedded code remain authored material with their own maintenance obligations. [Regeneration](https://architecture.joomlacomponentbuilder.com/markdown/engineering/regeneration.md)

The architecture thus multiplies a shared implementation change across the models that use it. The effect follows from the separation between application intent and target implementation; it does not require a claim of automatic semantic migration for every possible external program.

For another technology, the same structure can select database dialects, framework versions, deployment platforms, or language backends. The portable principle is explicit dispatch by a complete target context, with stable model meaning and clearly owned target-specific rules.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/compiler/events.md

# Extension hooks and observable effects

JCB exposes extension hooks around acquisition, modeling, content preparation, and file processing. They allow additional behaviour to participate at identified points in compilation. Several hooks receive mutable arguments or access shared build services.

The compiler's operational account includes those hooks. An execution diagram that follows only the built-in creators while ignoring event handlers would describe a different effective program whenever extensions are active. [C01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c01), [C02](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c02)

## Hooks have a location and an effect boundary

The initializer triggers events around component acquisition. Field data exposes query and modeling events. View preparation exposes content events. Per-file processing exposes file-read and pre-write events. Each location determines which information is already available and what later consumers will observe.

A hook can alter a query before acquisition, modify an enriched definition, contribute generated content, or transform the string about to be written. Those operations have different consequences. Their place in the sequence is part of their meaning.

For an event $h$ at stage $i$, model its action as

$$
\Sigma_{i+1}=h(\Sigma_i,x_i),
$$

where $x_i$ represents any external values read by the handler. The built-in transition sequence continues from the resulting state.

## Determinism concerns the complete effective input

A fixed ordered program can be deterministic even when it mutates state. Determinism asks whether the same complete inputs and prescribed operations produce the same result. It does not ask whether every possible reordering of those operations would also produce that result.

For compiler output, the relevant input includes the selected definitions, target rules, repository responses, active event handlers, their configuration, and any environment values they are permitted to use. Dates, locale, filesystem content, or network material can be output-affecting inputs.

If a handler reads a changing external resource, that read changes the effective build input. If two runs fix the same input and handler behaviour, the ordered state transformations can still be repeatable. [Formal state](https://architecture.joomlacomponentbuilder.com/markdown/formal/state.md), [Formal staging](https://architecture.joomlacomponentbuilder.com/markdown/formal/staging.md)

This is a more useful description than either treating hooks as automatically nondeterministic or ignoring them when making a repeatability claim.

## Read and write sets expose dependencies

For an operation $o$, let $\operatorname{read}(o)$ and $\operatorname{write}(o)$ identify the state locations it consumes and changes. A hook that writes a view's name before classification affects the downstream keys and output. A hook that changes the final file string affects materialized bytes without necessarily changing the earlier model.

Two operations can be reordered safely only under an appropriate independence or commutation argument. Disjoint write sets alone are insufficient if one operation reads what the other writes. The [formal classification chapter](https://architecture.joomlacomponentbuilder.com/markdown/formal/classification.md) states a sufficient noninterference condition for the small model.

The implementation commonly establishes this dependency discipline through explicit sequence. The mathematical account makes that discipline inspectable without asserting an automatic effect checker in production.

## Side effects extend beyond output files

Compilation can read and update local data, recover code, process version history, retrieve remote material, prepare folders, write generated files, synchronize configured repository locations, construct archives, and enqueue user-visible messages. Those effects are part of the lifecycle described by the paper.

A pure mathematical projection can be useful for a particular emitter, but the complete compiler is an effectful process. The [state model](https://architecture.joomlacomponentbuilder.com/markdown/formal/state.md) therefore separates durable definitions, intermediate stores, staged artifacts, external observations, and diagnostics.

This separation also prevents an architectural mistake: interpreting a physical file write as proof that all of the file's semantic stages have completed. Skeleton files can exist before later bindings and injections are applied.

## Diagnostics preserve operational information

Warnings and errors communicate more than a final Boolean. They can identify missing definitions, failed external material, language mismatches, uncertain custom-code placement, or packaging problems. The specific path determines whether processing stops, continues with a fallback, or records an item for manual attention.

The custom-code placement fallback is a concrete example: commented recovery material plus a file/location warning carries information that would be lost in a result reduced to “success” or “failure.” [Custom code](https://architecture.joomlacomponentbuilder.com/markdown/compiler/custom-code.md)

## A portable implementation boundary

Another implementation can represent hooks as registered functions with explicit context arguments and effect permissions. It can record repository responses, external resource digests, and diagnostic events in a build trace. These are practical ways to preserve the same extension boundary and make it easier to inspect.

The publication does not require those additional records to exist in every JCB build. Its source account names the actual events and effects; its language-neutral model supplies a vocabulary for reasoning about them. The [verification chapter](https://architecture.joomlacomponentbuilder.com/markdown/engineering/verification.md) distinguishes source correspondence, executable mechanism tests, artifact traces, and full runtime build tests.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/generation/schema.md

# Schemas, storage, and update history

A field's database description is one projection of its design. The compiler decides whether the occurrence is persisted, normalizes its type and default information, derives index requirements, and retains the result for SQL and metadata generation. The same field can also produce form and runtime storage logic.

The schema is therefore coordinated with the application model rather than authored as an unrelated second description. [C05](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c05), [C13](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c13)

## Persistence is an occurrence decision

The field builder determines whether a field participates in database storage from the configured use. The inspected non-database mode bypasses schema contributions while still allowing the field to participate in the relevant interface behaviour.

A field definition and a column are consequently different objects. A spacer, display-only field, or deliberately non-persisted control need not create a database column simply because it has a field identity.

Write the persistence decision as $p(d,o)\in\{0,1\}$. A schema contribution exists only when the selected type and occurrence rules require it:

$$
C_{\mathrm{schema}}(d,o)=
\begin{cases}
\operatorname{column}(d,o), & p(d,o)=1,\\
\varnothing, & p(d,o)=0.
\end{cases}
$$

The empty contribution does not erase the other possible contributions of the field.

## Normalization precedes emission

The builder records datatype, length, default, nullability, local and portable identity, and key-related information. Numeric defaults are normalized according to the implemented numeric type rules. Text/blob families follow a different length and default path from ordinary length-bearing columns.

The intermediate description is consumed by SQL generation and by the component-field metadata builder. The latter combines type and length into a normalized database type and retains properties such as key and unique-key status. [C05](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c05), [C22](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c22)

This is an example of two emitters consuming a shared interpretation. The SQL and metadata output should reflect the same normalized column decision, even though their syntax differs.

## Key requirements can be derived from a field's role

The Greeting field's blueprint sets its explicit index option to zero, yet the generated table has an index for that column. The reason is visible in the builder: a non-text field used as a title, alias, or category can require a normal key even when the field definition did not independently request one. Hello World's field association marks Greeting as the title. [Field trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/field-trace.md)

For the inspected branch, let $x$ mean an excluded text/blob family, $i$ the explicit index selector, and $a$, $t$, $c$ the alias, title, and category roles. The selected key kind is

$$
\operatorname{keyKind}=
\begin{cases}
\mathrm{unique}, & \neg x\land i=1,\\
\mathrm{ordinary}, & \neg x\land i\ne1\land(i=2\lor a\lor t\lor c),\\
\mathrm{none}, & \text{otherwise}.
\end{cases}
$$

The equation preserves the branch precedence. It explains a generated consequence that is not obvious from the field's isolated JSON record. The occurrence settings and compiler rule supply the missing context.

## Storage treatment spans save and load paths

Fields can select storage treatments such as JSON representation, encoded strings, or configured encryption/custom processing. Classification records which fields require each treatment. Later model-generation operations consume those builders when preparing save and retrieval logic.

The architectural requirement is coordination: a representation written by one path must be interpreted appropriately by the corresponding read path. A storage selector therefore affects more than the database column declaration. It can require imports, helper services, initialization fragments, and permission-sensitive handling of omitted values. [C05](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c05), [C14](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c14)

The paper describes those generated responsibilities without equating an encoding option with a security guarantee. The concrete selected implementation determines the actual transformation.

## History generates migration information

The history/modeling services compare selected previous and current component, view, and field-related information. New associations and changed properties contribute to update-SQL state. The update service handles supported old repeatable and newer subform representations and records additions or old/new values under identified keys.

The compiler later uses those contributions to prepare update artifacts. Recording a schema change during compilation is distinct from executing the migration against a deployed application's database. Installation and update processing consume the generated artifacts at a later lifecycle stage. [C13](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c13)

The relevant relation is a supported design delta:

$$
\delta=\operatorname{compare}(D_{\mathrm{previous}},D_{\mathrm{current}}),
\qquad U=\operatorname{emitUpdate}(\delta,T).
$$

The domain of `compare` is the set of properties and relationships handled by the implementation. It is not a general semantic differencer for arbitrary external databases.

## Generated metadata reconnects output to design

JCB emits a component-field map containing field identity, label, type, title status, list, storage treatment, tab, database properties, and represented links. Hello World's generated Table class contains this map alongside the runtime application.

That metadata makes parts of the design explicit in the product and provides useful input to tools that inspect or recover structure. It is one reason the architecture's forward and reverse paths can share vocabulary. [Extrusion analysis](https://architecture.joomlacomponentbuilder.com/markdown/extrusion/analysis.md)

The resulting maintenance mechanism combines portable intent, normalized schema decisions, history-derived updates, and complete generated application code. A change is represented once and propagated through the concerns that the compiler knows depend on it.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/generation/queries.md

# Queries, selections, and result structure

A generated view needs more than a form or template. It needs a defined way to obtain application data, name the selected values, apply filters and ordering, and expose the result to presentation code. JCB represents much of that work through Dynamic Get definitions and field-derived list builders.

The query definition is compiled into the generated application's model. The runtime application executes that generated query logic; it does not need to consult JCB's authoring GUI to rediscover the design. [C12](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c12), [D01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#d01)

## Query intent has several dimensions

Dynamic Get definitions select a primary source, additional tables or views, selected columns and aliases, join relationships, filters, predicates, grouping, ordering, and result cardinality. The documented get roles distinguish a main item or list query from additional single or multiple-result methods.

The source can be a modeled backend view, a named database table, or an explicitly customized retrieval path. These choices determine how much structure the compiler can derive automatically and which parts remain authored code.

A compact abstract query is

$$
q=(S,J,\Pi,\Phi,G,O,L),
$$

where $S$ is the source, $J$ the joins, $\Pi$ the selection/alias map, $\Phi$ predicates and runtime filters, $G$ grouping, $O$ ordering, and $L$ limit/pagination behaviour. This tuple describes the represented query intent; the target emitter supplies the platform-specific query construction.

## Selection establishes names used later

The selection service distinguishes a direct database table from a modeled view table and resolves the corresponding table name. It parses selected expressions and aliases, records source-column-to-result-key relationships under a method key, and prepares query fragments.

For modeled view selections, it also retains mappings from the original field to its use in a particular site query. That information can later connect field treatment to the appropriate selected value. The result is not just SQL text: it includes a map between source meaning and result names. [C12](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c12)

Write that map as

$$
\alpha_q:(\text{source alias},\text{column})\mapsto\text{result key}.
$$

Downstream consumers should use $\alpha_q$ rather than independently guessing which name a joined column acquired.

## Wildcards still require structural knowledge

A wildcard selection can require the compiler to obtain the underlying columns so it can establish field and alias mappings. The emitted query may retain a wildcard in the cases where the source's rules permit it, while particular joined single-row cases produce explicit aliased selections.

This is another example of semantic preparation exceeding the final text. The compiler may inspect a richer description to emit a compact query expression while retaining the mappings needed by later generation.

Alias collision handling is scoped by the query/method and its source roles. The inspected selection code can prefix a joined view's result key under its conflict condition. That is a particular policy, not a claim that arbitrary SQL expressions are globally normalized into a unique relational schema.

## Field-derived list behaviour joins the same model

An admin field association can activate search, sorting, filtering, list display, or a joined display relation. Classification stores those decisions in distinct builders. Later list-model generation combines them with standard state, selected fields, custom code, and target conventions.

The Greeting field's association makes it searchable and sortable. Its generated list head and sort options use the same resolved column and language label that appear in the field trace. The coordinated behaviour comes from the association plus compiler rules, not from additional manually written query code in the blueprint. [Field trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/field-trace.md)

## Query execution and result modeling are separate

After retrieval, the generated model may transform stored representations, attach related results, process configured custom code, prepare display values, or apply selected permission handling. A field relation can act before modeling, after modeling, or in presentation.

A useful decomposition is

$$
R=\operatorname{execute}(\operatorname{emitQuery}(q,T),\rho),
\qquad R'=\operatorname{modelResult}(R,\Gamma),
$$

where $\rho$ supplies runtime values such as filters, user information, or request parameters. The compiler emits both operations; compilation itself does not execute every future application query.

This separation matters when interpreting the phrase “the compiler understands the query.” It understands the represented structure sufficiently to emit the selected query and its result-handling code. Runtime data remains runtime input.

## Cardinality shapes generated methods

Single-item, list, and supplementary-query roles affect generated method structure and the values exposed to a view. Joined single records and collections have different representation requirements. Pagination connects model state and query limits to view-side navigation.

Those are cross-file obligations. A pagination choice can require both model logic and presentation support. A result alias used in a template must agree with the model's selected key. A lookup filter must use the correct field and value source.

The public Hello World site views and Dynamic Get records provide a small example of these connections. The Service Directory extends the same mechanisms across a substantially larger generated application. [Hello World](https://architecture.joomlacomponentbuilder.com/markdown/examples/hello-world.md), [Service Directory](https://architecture.joomlacomponentbuilder.com/markdown/examples/service-directory.md)

## The portable architectural principle

A reimplementation needs a typed query description, an alias/result map, target-aware emitters, and a clear boundary between compile-time structure and runtime values. It can use a different database API or language while preserving those roles.

Relational algebra provides vocabulary for selection, projection, and joins; model-driven generation explains the compilation of their structured description into code. The paper uses those correspondences to clarify the implementation rather than claim a new query algebra. [Bibliography](https://architecture.joomlacomponentbuilder.com/markdown/reference/bibliography.md)


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/generation/forms-layouts.md

# Fields, forms, layouts, and nested presentation

A form is one visible result of several coordinated interpretations. Field-type definitions supply available properties and behaviour; field definitions select those properties; view associations establish placement and roles; the target supplies form and view conventions; permissions and conditions can modify generated behaviour.

The compiler retains those decisions in field, layout, script, language, and code stores before assembling the output. A form is therefore not an isolated template expansion detached from the application model. [C04](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c04), [C05](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c05)

## Field types and field instances

A field type describes a reusable kind of input or display element. A field instance supplies its configured name, label, properties, storage information, and custom behaviour. Its use in an admin view adds placement, ordering, tab, list, title, alias, filter, and related roles.

These layers let one field-type definition support many fields and one field definition participate in several contexts. The compiler resolves names and attributes under those contexts rather than assuming every reuse should share a mutable occurrence-specific result.

Hello World's Greeting field illustrates the distinction. Its database length is 255, while its form maximum is 50. Its title and list roles are carried by the view association. The generated schema and XML retain those different meanings. [Field trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/field-trace.md)

## Layout is an accumulated interpretation

The field builder determines a tab name from the view's tab mapping, recognizes selected standard placement cases, and records the field in the layout builder with its occurrence settings. Later form and view generation consumes the resulting arrangement.

For a view $v$, the layout can be modeled as an ordered grouping

$$
\mathcal{L}_v=\langle(\text{region}_i,\langle o_{i1},\ldots,o_{in_i}\rangle)\rangle.
$$

The grouping retains occurrence identity and order. It is not merely a set of field definitions, because the same definitions in another order or region can produce a different interface.

Conditional fields, custom tabs, and relation-specific scripts add further contributions. Their generated code depends on the same resolved names used by the form and data model. [C05](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c05), [D01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#d01)

## Validation and custom field behaviour

Field XML can identify a validation rule. The field-data path registers the rule, and later content preparation creates the required validation output when custom rule data is present. Custom field definitions can also require generated classes and supporting code.

A rule name, its implementation, the form reference, and the generated file are related outputs. Their alignment is another instance of the compiler's definition-to-contribution-to-artifact relationship.

Scripts associated with a field are prepared through the dispenser and guarded by field/view processing state. Reusing the field in a view need not append its script repeatedly; using it in another view can require a distinct contribution. [Acquisition](https://architecture.joomlacomponentbuilder.com/markdown/compiler/acquisition.md), [Stores](https://architecture.joomlacomponentbuilder.com/markdown/compiler/stores.md)

## Templates and layouts can reveal further dependencies

JCB's template/layout data service recognizes supported literal template-load and layout-render references in content. It resolves the corresponding alias, stores the acquired template or layout data, and scans the acquired HTML and view-code material for further references.

Templates are retained under a build-target, view, and template key. Layouts use a build-target and layout key. The scopes differ because templates and layouts have different reuse roles. When content is destined for both relevant language/build areas, the implementation can prepare layout data for the corresponding area as well. [C11](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c11)

The service stores a discovered item before traversing its nested content. This gives repeated or cyclic references a stable presence check and avoids treating every encounter as a new acquisition.

## Static recognition has an explicit domain

The template/layout scanner recognizes particular literal call forms, including the supported quote variants and Joomla Power layout reference convention. It follows those represented dependencies; it does not infer the value of every arbitrary runtime expression that might compute a template name.

For content $c$, let $\operatorname{refs}(c)$ be the references recognized by that grammar. Nested acquisition completes the reachable set under those references. The [dependency model](https://architecture.joomlacomponentbuilder.com/markdown/formal/resolution.md) applies with that explicitly defined relation.

The precision is useful to another implementer. It identifies which syntax must be recognized and how the result enters the shared acquisition machinery, rather than describing the feature as unrestricted source-code comprehension.

## Presentation and model concerns remain connected

A list-field relation can combine the presentation fragments of several fields, retaining their generated links and formatting. A model-side relation instead combines raw or modeled values. A template consumes the names and shapes established by its Dynamic Get. Permissions can change which form controls or result values are exposed under configured paths.

These connections make the generated interface part of the application, not merely its wireframe. The [queries](https://architecture.joomlacomponentbuilder.com/markdown/generation/queries.md) and [permissions](https://architecture.joomlacomponentbuilder.com/markdown/generation/permissions.md) chapters explain the corresponding model and policy work.

A portable implementation can use another UI technology while retaining the same sequence: resolve field kinds, interpret occurrences, establish names and data contracts, collect layout and behaviour contributions, resolve nested presentation dependencies, and emit the target's interface artifacts.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/generation/permissions.md

# Compiling access-control behaviour

JCB can represent access-control decisions in the model and generate the declarations and checks that a Joomla application evaluates at runtime. The compiler processes policy structure; the generated application applies it to users, groups, assets, and records.

This separation is essential. The permission of the person running JCB to import code is a build-time concern. The permission of a later application user to edit a record or interact with a field is generated runtime behaviour. [C14](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c14)

## Actions, scopes, and generated consumers

The permission creator builds mappings for view-specific and component/global actions, labels and descriptions, dashboard behaviour, and related access sections. Model and view generators use those mappings rather than independently inventing action names at every destination.

A runtime authorization request can be modeled as

$$
\operatorname{allow}(u,a,s),
$$

where $u$ is the runtime user, $a$ an action, and $s$ the relevant asset scope. The compiler emits the action and asset expressions; Joomla's runtime policy machinery supplies the result.

Existing-record operations can use a record asset, while creation paths can use the component asset where no record identity exists yet. Generated toolbar state, controller checks, form treatment, and model behaviour consume the appropriate action mappings. The exact consumer and scope determine the guarantee.

## Field-level policy changes form behaviour

The inspected form-generation path implements field options named `edit`, `access`, and `view`. Their generated behaviour is type-sensitive:

| Field option | Representative generated form behaviour |
| --- | --- |
| Edit | Disables and marks a field read-only when authorization fails; selected input types receive additional disabled styling; empty values receive type-dependent filtering or removal treatment |
| Access | Removes the field from the form when authorization fails |
| View | Removes spacer-like fields, or makes ordinary fields hidden with additional handling for empty or array values |

These are the actual roles of the selected options. A hidden input is a presentation and submission choice, not a confidentiality boundary by itself. The access and strict-result paths serve different purposes and must be configured and understood accordingly. [C14](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c14)

The source contains separate handling for view/record creation, deletion, editing, and state changes. Those record-level operations should not be casually renamed “delete a field” or treated as identical to the three field-form options.

## Strict result treatment is separately controlled

Where field-permission generation enables the relevant path, the generated model includes a runtime `strict_permission_per_field` setting, defaulting to inactive. When active, selected `access` or `view` authorization failures cause the corresponding retrieved field value to be replaced with an empty string in the result-processing loop.

This is post-retrieval result treatment. It is not the same operation as adding a database predicate that prevents the column from being read. The generated code checks the configured field action against record and component scope as represented in the emitted condition. [C14](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c14)

For the selected value treatment, write

$$
R'[i,f]=
\begin{cases}
\varepsilon, & \text{strict mode and the generated authorization condition denies }f,\\
R[i,f], & \text{otherwise}.
\end{cases}
$$

The equation exposes both the option and the runtime condition. It does not assert that every output path automatically has the same redaction policy.

## Storage handling must respect omitted fields

Permission-driven form treatment can remove a value from submitted data. The save generator accounts for that interaction in its JSON-item handling: it distinguishes an omitted value that should be cleared from an omitted value absent because the user lacks the relevant permissions.

That is a non-obvious cross-concern dependency. A storage transformation that always converted a missing field to an empty value could erase data that the current user was not allowed to edit. The compiler's permission-aware branch coordinates the form and save paths. [C14](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c14)

This example shows why access control belongs inside the architectural explanation rather than in a feature list. The permission definition affects declarations, controls, result treatment, and storage semantics together.

## The policy is generated, not decided at compile time

The compiler does not know every future application user or record. It emits expressions and branches that evaluate those values later. The design describes permitted operations; the runtime supplies the user and asset context.

A portable implementation should likewise separate policy declarations from policy evaluation and from the UI consequences of an authorization result. Hiding a control, rejecting a write, filtering a result, and declaring an action are distinct responsibilities even when driven by the same policy definition.

## Evidence and scope

The Hello World package demonstrates generated access sections and ordinary application action structure. It is not configured to exercise every field-level policy branch. The detailed field behaviour in this chapter is traced to the compiler's corresponding generation paths. [E02](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#e02), [C14](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c14)

This combination of source correspondence and concrete output keeps the account precise. The architecture supplies coordinated policy generation for its represented options; applications and extensions retain responsibility for the behaviour of custom code and independently added interfaces.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/generation/languages.md

# Language keys and multilingual output

A generated label has two connected representations: a key inserted into code or markup, and a value stored in an appropriate language catalogue. JCB prepares both while interpreting the application model. The same field can contribute labels to form, list, filter, and other output roles.

Language processing is therefore a cross-artifact coordination problem. A form's reference and a catalogue's entry must agree on identity and scope even though they are emitted at different points. [C15](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c15)

## Context supplies the key namespace

The compiler's language prefix and current target distinguish component, module, plugin, administrator, site, and related output areas. Field and view interpretation constructs role-specific keys from those settings and the represented names or source strings.

Hello World's Greeting label becomes `COM_HELLOWORLD_GREETING_GREETING_LABEL`. The generated form and list material refer to that key, and the language file supplies `Greeting` as its value. The original field description need not repeat the fully qualified language key at every use. [Field trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/field-trace.md)

For a label source $s$, role $r$, and context $\Gamma$, write

$$
k=\operatorname{languageKey}(s,r,\Gamma),\qquad
L[\operatorname{area}(\Gamma),k]=\operatorname{normalize}(s).
$$

The key-construction function and destination area are both part of the interpretation.

## Collection is shared, but destination remains explicit

The language service stores content by target and key. Its ordinary keyed setter fills an empty entry rather than blindly overwriting every previously established value. An explicit target setter can replace a whole target collection. String normalization trims content and, when configured, removes line breaks.

These are concrete update policies, not a general conflict-resolution engine. A reimplementation should state whether an entry is first-established, replaced, merged, or rejected when the same key is supplied again. [C15](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c15)

The compiler also extracts supported language references and source strings from custom content. Code preparation can consequently produce language contributions while it discovers custom-code and Power dependencies. A value that appears to be “just code” can affect several later products.

## Reusable translations connect source strings to targets

The multilingual services retrieve existing translation records and map available translations into the language output collections for the current extension and area. They update or insert source-string records and maintain their association with components, modules, or plugins.

The source string, its translated values, and the emitted placeholder key are related but distinct identities. A translation record can be reused where the same source string participates in another generated context, while each output still uses the appropriate extension-specific key.

The inspected language-maintenance path also updates relationships and handles strings no longer linked to the current target. This work occurs in local design/translation data; generated language files are later products of that maintained information. [C15](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c15)

## Translation completeness controls file inclusion

The translation checker compares a non-source language's available string count with the source-language total. Its configured percentage threshold determines whether that language file is included, with a selected debug mode affecting the threshold path. Inclusion and exclusion are reported through language messages.

For a nonempty source catalogue of size $N$ and an available translated count $n_\ell$, the comparison uses

$$
p_\ell=100\frac{n_\ell}{N}.
$$

This is an inclusion policy for generated language material, not an automatic translation process. The source language and translation records remain explicit inputs. [C15](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c15)

## Language changes follow generation context

Module and plugin infusers establish their own language targets and prefixes before generating provider, dispatcher, extension, template, fieldset, and manifest content. Shared custom code can be processed for multiple areas where the selected path requires it.

A language prefix must therefore be correct at the time the relevant contribution is generated. Applying an unrelated component prefix to a plugin's labels would be a context error even if every string replacement completed successfully. [Context](https://architecture.joomlacomponentbuilder.com/markdown/foundations/context.md), [Extensions](https://architecture.joomlacomponentbuilder.com/markdown/generation/extensions.md)

## Diagnostics are part of the result

The final compiler phases write language data and report inclusion, exclusion, and mismatch information. These messages help distinguish a successfully generated application tree from a complete translation set for every language.

The mathematical model treats those messages as output observations alongside the language files. It does not hide a missing translation behind an undifferentiated successful-build flag. [Events and effects](https://architecture.joomlacomponentbuilder.com/markdown/compiler/events.md)

## The reusable principle

Another compiler can adopt the same separation: collect source strings during semantic interpretation, assign context-qualified keys, reuse translation records, apply explicit destination and completeness policy, and emit both references and catalogues from the coordinated state.

The mechanism is valuable because language support is generated with the application's fields, actions, and views rather than added independently afterward. It is another concrete example of one design decision producing several mutually dependent artifacts.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/generation/routing.md

# Routing, API surfaces, and AJAX tasks

A generated application needs entry paths as well as data and presentation. JCB prepares routing configuration, view and request mappings, selected API artifacts, and AJAX task/controller/model material from the same application definitions and contextual names used elsewhere in the build.

These mechanisms connect external requests to generated application responsibilities. They are different delivery surfaces, with different platform contracts, rather than one interchangeable set of URLs. [C16](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c16), [C24](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c24)

## Router configuration follows represented views

The router model records the views, table relationships, keys, aliases, and selected construction modes needed by routing generation. The default constructor creator emits view registrations and adds a key where the represented view has the required key and alias information.

The router creator also reconciles certain default request keys with request mappings accumulated elsewhere in the build. A list view without an item key is not automatically treated as a single-record route merely because another view uses `id`. [C16](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c16)

Represent a route-view record as

$$
r_v=(v,k_v,a_v,t_v,m_v),
$$

where $v$ identifies the view, $k_v$ its item key where applicable, $a_v$ its alias, $t_v$ its data source, and $m_v$ the selected mode. The emitted router consumes that record rather than rediscovering the view's identity from its final template filename.

## Build and parse operations use the same mapping

For supported item views, generated methods can convert an item identifier to a route segment and resolve a segment back to an identifier using the selected alias and table. The no-ID configuration changes the segment representation and the corresponding lookup path.

The two directions need compatible keys and alias semantics. They are not a universal inverse for arbitrary strings: the database contents, alias uniqueness, selected view, and route configuration determine which segments resolve.

A precise correspondence is therefore restricted to admitted items and segments:

$$
\operatorname{parse}_v(\operatorname{build}_v(i))\sim i,
$$

under the selected router's representation and lookup conditions. The paper uses this as an explanatory relation, not as a proof about every custom route implementation.

## Default, configured, and authored routing paths

The router creator selects default generation, manually configured generation, or custom code from the dispenser according to its mode settings. Constructor material before and after the parent call and selected method bodies have separate preparation paths.

This preserves a useful ownership boundary. A developer can use the compiler's derived mapping or explicitly supply the part whose behaviour differs. The custom material still receives the surrounding application context and participates in staged output binding.

## API output reuses application identity and policy

The inspected API templates use the component namespace, single or list view identity, content type, target headers, and generated permission fragments. Infusion prepares the corresponding API controller and JSON-view bindings alongside the admin-view material.

The generation path supplies API-facing artifacts when the component's selected configuration and target support them. Endpoint registration, authentication, and deployment configuration remain the responsibilities of their selected Joomla integration and extension setup. The presence of an API controller template is not by itself an assertion that every possible route is publicly exposed. [C24](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c24)

The architectural point is reuse of the established application interpretation: view names, model responsibilities, and policy fragments do not need to be reauthored as an unrelated API model.

## AJAX separates declared input from authored work

The admin AJAX model processes selected AJAX input definitions and custom model methods. It records controller-input material in the dispenser, establishes flags that require AJAX structures, and ensures the relevant token contribution is available. A site-edit use can also cause the corresponding site AJAX path to be prepared.

Infusion later generates task registration, input handling, headers, and model method content for the appropriate area. The controller boundary is generated from represented input/task settings; the application-specific method body remains authored code. [C24](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c24)

This is a practical instance of structured intent plus imperative implementation. The developer supplies which task and data contract are needed and what the method should do. The compiler supplies the surrounding framework structure at its designated locations.

## Cross-surface consistency

Routing, API, and AJAX generation depend on names and policies established elsewhere. A renamed view, changed request key, moved namespace, or revised permission action has consequences across those surfaces.

The compiler's shared builders and contextual bindings carry those decisions to the relevant consumers. The resulting native application contains the entry code; JCB remains a development-time dependency rather than a request-time interpreter of the authoring GUI.

The [formal classification model](https://architecture.joomlacomponentbuilder.com/markdown/formal/classification.md) describes the common pattern: one resolved decision can contribute to several artifacts, each with its own syntax and runtime role. The [source map](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md) identifies the distinct implementations so that their behaviour is not conflated.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/generation/extensions.md

# Components, modules, and plugins

JCB can produce a component together with related modules and plugins. The outputs share reusable definitions and compiler services while retaining extension-specific structures, namespaces, entry points, language prefixes, and installation metadata.

The Hello World repositories make that distinction visible: one portable design graph is associated with a component, the Site Redirect module, and a Privacy plugin. Their generated repositories are different products of the compilation lifecycle, not three copies of the same template tree. [E01–E04](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#e01)

## Component generation coordinates application concerns

A component can include administrator, site, and selected API areas, models, controllers, views, forms, layouts, fields, validation rules, libraries, language files, installation/update SQL, manifests, and installer code. Which artifacts appear depends on the model and target configuration.

The component's selected views provide the occurrences from which much of this material is derived. Field classification, Dynamic Gets, permissions, routing, custom code, and layout relationships contribute to the resulting native application. [C01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c01), [C05](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c05), [C19](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c19)

The compiler's contribution is the coordinated implementation, including low-level details, rather than only the creation of empty controller or model files.

## Module generation has its own context

The module data service acquires the module definition and its related settings. Structure generation prepares the target's module files. Infusion establishes the module's build target, language target, and prefix, then prepares provider, dispatcher, Dynamic Get, helper, default-template, installer, fieldset, and manifest material according to the selected target and features.

These responsibilities are delegated to architecture services where target versions require different output conventions. The module shares placeholder, language, dependency, and file services without adopting the component's namespace and file layout indiscriminately. [C17](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c17), [C21](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c21)

For an extension occurrence $e$, the content environment is

$$
P_e=\operatorname{prepareExtension}(d_e,\Gamma_e,\Theta_T).
$$

The target-specific file writer then uses that environment for the module's artifacts.

## Plugin generation resolves group and class structure

A plugin definition identifies its plugin group, base-class information, methods, properties, custom code, and selected installation/configuration material. Those referenced class-related entities participate in acquisition and blueprint distribution.

The plugin infuser establishes plugin-specific placeholders, namespace information, build and language targets, and the language prefix. It then prepares the extension class, service-provider material, installer code, fieldsets, and main manifest through the applicable architecture services. [C18](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c18)

The Hello World plugin's blueprint name includes a component placeholder. The selected component context resolves that name into the final plugin identity. This is a particularly clear example of a reusable definition whose final naming is established by its occurrence. [Extension trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/extension-trace.md)

## Structure, content, and archive are separate stages

Each extension family has data acquisition, structure preparation, content preparation, file updating, and archive responsibilities. A directory can be created before all its content is bound. A content map can be prepared before its corresponding file is finally written. An archive is produced after the selected file operations.

This separation permits shared dependencies and late-discovered Powers to join the output process while the compiler retains the distinct artifact sets for components, modules, and plugins. [Materialization](https://architecture.joomlacomponentbuilder.com/markdown/generation/materialization.md)

It also makes diagnostics precise. A component archive result, a module archive result, and a plugin archive result are separate outcomes in the orchestration. The complete build report should preserve those distinctions.

## Native products retain their runtime contracts

The generated extensions use the target platform's extension structure and the dependencies included or referenced by the selected build. The authoring model has been compiled into those artifacts; normal runtime requests do not need the JCB editor to interpret the blueprint again.

Reusable Powers and other supplied classes are part of the generated/assembled product where selected. Their inclusion does not imply that the compiler authored those class bodies during each run. It resolves, contextualizes, places, and connects supplied knowledge as part of the application. [Powers](https://architecture.joomlacomponentbuilder.com/markdown/compiler/powers.md), [Accounting](https://architecture.joomlacomponentbuilder.com/markdown/examples/accounting.md)

## A shared model can drive a product family

The component's module and plugin relationships provide one way to define a related set of products. The same field types, code definitions, configuration patterns, and target rules can also be reused across independent projects.

This produces a maintenance multiplier: a correction to shared generation knowledge can be applied through regeneration wherever that knowledge is used. The effect is governed by each model's selected features and authored overrides. [Regeneration](https://architecture.joomlacomponentbuilder.com/markdown/engineering/regeneration.md)

For another language or framework, the corresponding product family might contain a server, client library, worker, migration set, or command-line tool. The transferable architecture is a shared definition graph interpreted through distinct product contexts and emitters—not a requirement that every product have Joomla's extension categories.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/generation/materialization.md

# Materialization, packaging, and repository output

Materialization turns prepared structure and content into physical artifacts. JCB can create skeleton files before every semantic contribution is complete, update those files through later stages, add reusable code and supporting assets, and finally construct installation archives and configured repository outputs.

The physical filesystem is therefore part of the build state. A file's existence is not equivalent to its semantic completion. [C19](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c19), [C20](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c20)

## Structure and content are related but distinct

Structure utilities select templates, create directories, copy or prepare skeletons, and record file details. The file inventory groups outputs by their processing role and context. Dynamic files are associated with the view or extension whose binding environment will complete them.

A conceptual artifact record is

$$
a=(\iota,p,r,\Gamma,S),
$$

where $\iota$ is its logical identity, $p$ its destination, $r$ its emitter role, $\Gamma$ its context, and $S$ its remaining stages. JCB represents these responsibilities through paths, file arrays, builder keys, and orchestrated service calls rather than necessarily allocating this exact record type.

The record explains why a destination path alone is not the whole artifact definition. Two files can use the same skeleton but different contexts; one file can receive several successive transformations.

## The updater follows an explicit family order

The inspected extension updater requires the relevant static and dynamic inventories, loads previously discovered Power requests, obtains BOM content, and processes static files, dynamic files, modules, plugins, and Powers. It then prepares autoloader material and performs the corresponding static-file autoloader update before removing the consumed dynamic inventory. [C19](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c19)

The sequence reflects dependencies between file content and the reusable code discovered while processing it. Autoloader completion belongs after the relevant Power information has been established.

This is a concrete example of staged readiness reaching the filesystem. The compiler does not merely write every output once from an already final map.

## Per-file processing establishes its local environment

For a file, the content service sets the current filename binding, reads the staged content, handles the configured header/BOM convention, applies shared bindings, and then applies the selected contextual bindings. Conditional custom-code expansion, a pre-write event, and Power/Joomla Power injection follow before the final write in that path.

The binding order and action mode determine how introduced tokens are handled. The [binding chapter](https://architecture.joomlacomponentbuilder.com/markdown/compiler/binding.md) gives exact examples rather than treating all replacement algorithms as equivalent.

Counters record generated work such as files, folders, Powers, and line occurrences according to their respective update points. Those internal counters should be interpreted using their measurement boundaries; a separately counted repository snapshot can have a different inventory after copying, packaging, or excluding metadata. [Build measurements](https://architecture.joomlacomponentbuilder.com/markdown/engineering/performance.md)

## Additional files and folders are part of the model

Component, module, plugin, and library settings can name extra files, folders, or URL-sourced material. Their configured targets and paths participate in structure preparation and installation/package metadata. Reusable Power structures also add their own source and support files.

These supplied artifacts are part of the complete build input. They should be counted separately from blueprint payloads and from text synthesized by a particular emitter. This separation makes an expansion or size measurement reproducible without denying the compiler's assembly work.

## Packaging follows file preparation

The final compiler orchestration handles language output and messages, update XML destinations, generated README material, and configured local repository synchronization before constructing the component archive and then associated module and plugin archives.

Packaging is a deployment representation of the generated product. A blueprint repository transports editable design knowledge; an installation archive transports the runtime extension and its installation metadata. Both are outputs in the larger lifecycle, but they serve different consumers. [Lifecycle](https://architecture.joomlacomponentbuilder.com/markdown/foundations/lifecycle.md)

The implementation's repository and server integrations are selected by configuration. The paper does not assume that every compilation publishes to a remote Git service or deploys an extension automatically.

## Failures have operation-specific consequences

A file read, write, dependency retrieval, content update, repository synchronization, or archive creation can fail at its own boundary. The compiler's return values and messages determine whether processing stops, continues, or records a recoverable result.

An archive produced at one stage does not prove that every optional publication integration completed. Likewise, a warning about recoverable custom-code placement carries different meaning from an unreadable required template. The formal model retains diagnostics alongside artifacts rather than flattening them into one undifferentiated output.

## Reproducibility has a declared comparison boundary

To compare two materialized builds byte for byte, the source definitions, target rules, reusable dependencies, active hooks, and output-affecting environment values must be controlled. Dates, local editing markers, path-dependent metadata, and archive metadata can otherwise differ while the application model remains equivalent.

The [transport model](https://architecture.joomlacomponentbuilder.com/markdown/formal/transport.md) distinguishes design equivalence, normalized artifact equivalence, and byte equality. The distinction is useful when importing the same blueprint into another instance or comparing generated repositories.

The resulting architecture provides a clear path from retained semantic information to a deployable product: plan the required structures, prepare contextual content, complete the ordered stages, preserve diagnostics, and package the resulting artifact set.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/extrusion/overview.md

# Extrusion from installed applications

Extrusion brings an existing application's represented structure into JCB's editable model. Its inputs can include component folders, explicit administrator and site roots, and a schema dump. It discovers relevant artifacts, reads their structure without executing the application, resolves the information they supply, presents candidates for pairing, and writes selected definitions into JCB.

The operation closes a useful development path: an application need not begin as a JCB blueprint to supply recoverable fields, schema, views, presentation material, or reusable classes. Once represented locally, the recovered definitions join the ordinary editing, export, dependency, and compilation workflows. [X01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#x01)

## Discovery, interpretation, and writing are separate

The component extruder exposes a harvest operation that gathers and assembles the source without writing definitions. Its candidates operation presents the recovered items against a selected component's existing definitions. The writing operation then applies reuse and pairing decisions before dispatching the appropriate writers.

This separation is architectural, not merely a confirmation dialog around an opaque import. The intermediate registries retain the inventory, source facts, resolved properties, proposed identities, decisions, and report. A caller can inspect what the system found before changing the destination model.

```mermaid
flowchart TD
  A["Component roots and schema material"] --> B["Bounded discovery and typed readers"]
  B --> C["Property candidates with origins"]
  C --> D["Precedence, identity, and sharing resolution"]
  D --> E["Review and pairing decisions"]
  E --> F["Ordered model writers"]
  F --> G["Editable local blueprint graph"]
  G --> H["Normal compilation and export"]
```

Class-library extrusion has a related but separate path: harvest class candidates, resolve their identities and namespaces, assemble Power definitions and relationships, and write the selected code definitions. [Class recovery](https://architecture.joomlacomponentbuilder.com/markdown/extrusion/classes.md)

## An installed component is evidence, not an original blueprint

A schema states columns, types, defaults, and keys. Form XML states controls and their configured attributes. Language files explain represented constants. A generated table-definition class can retain detailed model metadata. A manifest identifies the extension and its installation structure. Source files preserve authored code and presentation material.

Those artifacts overlap, but none must contain every decision that originally produced the application. Extrusion combines what each can state rather than assuming that one artifact is a complete inverse of compilation.

For source artifacts $A$, write

$$
H=\operatorname{harvest}(A),\qquad
Q=\operatorname{resolve}(H),\qquad
D'=\operatorname{write}(D,Q,V),
$$

where $H$ retains observed facts and origins, $Q$ contains resolved candidates, $V$ contains review decisions, and $D$ is the existing local model. The middle representation makes uncertainty, precedence, and identity available for examination before persistence.

## Multiple starting points use the same recovery machinery

An installed Joomla component can provide distinct administrator and site roots. An unpacked package can supply the equivalent source tree. A bare schema dump supplies less information but can still describe fields and candidate admin views. A folder and a dump can be combined.

The implementation accepts a component name explicitly; otherwise, manifest information has precedence over a name inferred from table prefixes. Where a name cannot be established, the report identifies the unresolved naming context rather than inventing an unrelated component identity. [X01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#x01)

Discovery supports Joomla layout profiles and bounded scanning. The inspected configuration defaults to a depth of 12 and a maximum of 20,000 files, with include/exclude selections and explicit administrator/site options. Those limits bound the examination; they are not claims about the size of every supported installation.

## Recovered content returns to ordinary compiler abstractions

The writer sequence creates or updates the component details, fields, admin views and their associations, conditions, Dynamic Gets, site views, and custom-admin view relationships in dependency order. Recovered presentation code belongs to the appropriate view or reusable presentation role rather than becoming an arbitrary extra file with no model connection.

The compiler can subsequently regenerate an application from those definitions using its existing rules. Extrusion therefore does not require a second compiler specialized for imported projects. It feeds the same modeled concerns through the existing pipeline.

## The operation reports its actual outcome

The report records artifacts read, views assembled, definitions written, reused identities, shared fields, skipped decisions, unresolved types, and other recovery details. A successfully completed operation can still contain explicitly reported shortfalls or deliberate skips.

For example, an unmapped field type can produce a custom-field candidate requiring configuration; a type that cannot be resolved at all can prevent that field from being written. A condition referring to a field managed implicitly by JCB may not be reconstructed as an ordinary field dependency. Those outcomes are part of the represented operation, not silently treated as recovered facts. [X01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#x01), [X04](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#x04)

The integrated extrusion capability described in this edition is identified in the [edition record](https://architecture.joomlacomponentbuilder.com/markdown/reference/edition.md). Its mechanisms are explained as implemented operations, with source responsibilities recorded separately from the older core compiler pin.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/extrusion/analysis.md

# Reading artifacts and resolving their meaning

Extrusion separates locating an artifact from accepting a particular interpretation of it. Discovery identifies possible manifests, schemas, table metadata, forms, language files, and views. Typed readers extract the facts those artifacts actually represent. Resolvers then combine those facts into candidate model properties.

This structure prevents a familiar reverse-engineering mistake: treating the first plausible value found in a file as authoritative for every purpose. [X02](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#x02)

## Readers do not run the inspected application

The source readers inspect text and represented syntax. Schema readers split and interpret supported SQL statements; the table reader obtains supported literal metadata; form readers parse XML; language readers parse catalogues; presentation readers retain and classify the supported template content. The Power reader uses lexical and parser services to recover declared type structure.

The recovery operation is therefore not an application execution trace. It does not run an arbitrary installer or evaluate class bodies to discover what they might do. Dynamic values that cannot be recovered from the supported representation remain outside that reader's result.

This boundary is useful in another implementation language: each reader has a defined accepted grammar and produces facts with source locations or origins. The resolver consumes those facts independently of the reader's physical syntax.

## Property precedence is finer than whole-file precedence

The inspected default order is **table metadata, SQL notes, form XML, derived schema information**. It is configurable. A field can take its datatype from one source and its label or presentation attribute from another, because selection happens property by property.

For property $p$, let its usable candidates be

$$
C_p=\{(v_i,t_i)\mid v_i\text{ is supplied by tier }t_i\}.
$$

The resolver selects the candidate with the smallest configured rank. Equal ranks are resolved by the fixed default tier order. A value is not usable when it is `null` or the empty string; numeric zero and Boolean false remain legitimate values.

$$
\operatorname{selected}(p)
=\mathop{\operatorname{argmin}}_{(v,t)\in C_p}
\bigl(\operatorname{rank}(t),\operatorname{defaultRank}(t)\bigr).
$$

The resolved record retains both the chosen value and its origin. A portable implementation should preserve that pair: a value without its origin no longer explains why it prevailed. [X02](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#x02)

## Similar-looking properties can have different meanings

A database default and a form default are not automatically the same property. The resolver records database-default information separately where schema and table metadata state it. Similarly, database width and maximum input length can be distinct, as the Greeting example demonstrates.

SQL column comments can carry supported scalar configuration in JSON. XML can carry a field type, label, options, validation, conditions, and other attributes. Language resolution can turn a represented constant into its text. Derived schema interpretation supplies a lower-priority answer where a stronger source has not stated one.

The result is not “pick one file and copy it.” It is a property-level assembly governed by explicit precedence and meaning.

## Generated boilerplate is not another authored field

JCB generates standard fields and view structures from its own rules. The extrusion configuration identifies the standard columns and template names that should not be duplicated as ordinary authored definitions. The GUID field is deliberately treated differently from the standard skipped-column list because it can be a modeled field with a recoverable identity.

Likewise, repeated files such as a generated list body's default template do not necessarily represent separate reusable templates with the same global name. Recovery needs the artifact's role and containing view, not only its basename. [X02](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#x02)

This distinction keeps the recovered model compact. Reconstructing every mechanically generated fragment as independently authored code would preserve bytes at the cost of losing the architecture that made regeneration useful.

## View scope influences classification

Administrator and site views can have similarly named files. Explicit roots and discovered layout context distinguish them. The reader first establishes the screen identified by its main template or class, then associates subordinate presentation material with that screen and role.

A view's presence is directly observable from its layout and artifacts. Its complete original configuration is not automatically recoverable from the fact that a class exists. The resolver uses available schema, form, metadata, and naming information to establish the supported model, while retaining code where the selected recovery path supports it.

The resulting candidate may be an admin view, custom-admin view, site view, template, layout, or related query definition. Those roles determine which writer and subsequent compiler consumer will handle it.

## Resolution produces a reviewable intermediate model

The assembled candidate retains its name, type, selected properties, source context, proposed identity, and applicable relationships. Field conditions and relations are connected after identities are established. Sharing resolution can consolidate repeated descriptions of the same field before candidates are presented.

The next stage therefore reviews semantic candidates, not a raw directory listing. The developer can see the model that would enter JCB and decide how it should relate to existing definitions. [Pairing](https://architecture.joomlacomponentbuilder.com/markdown/extrusion/pairing.md)

This is the reverse-side counterpart of contextual compilation: readers distribute observed facts into typed stores; resolvers establish meaning; later consumers use the retained decisions. Forward and reverse flows share architectural principles without being falsely described as exact inverses for every possible program.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/extrusion/classes.md

# Recovering classes as reusable definitions

Class-library extrusion recovers code into the same managed Power representation used by compilation. It identifies a declared type, retains its body and relevant metadata, resolves its namespace and import relationships, pairs it with an existing or new identity, and writes the resulting reusable definition.

The result is more than a copied source file. The class becomes locally editable and participates in JCB's dependency, placeholder, namespace, placement, export, and compilation mechanisms. [X03](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#x03)

## Harvest before writing

The Power extruder accepts selected library roots, bounds the scan, and constructs a tree of libraries, subfolders, and class candidates. Harvest can run without writing. Selection and existing-item policy determine which candidates proceed to assembly.

The writing path assembles the selected definitions, writes Powers, and records the relevant vendor/component values on the paired component so that later compilation can resolve the recovered placeholders back to their intended context.

A deliberate skip because every selected class already exists is a valid outcome. It differs from failing to find any usable declaration or filtering every candidate out unexpectedly. The report keeps those cases distinct.

## Lexical identity precedes body extraction

The class reader normalizes a UTF-8 BOM and line endings so lexical offsets and parser slices refer to the same text. It locates the first supported named declaration, distinguishing it from anonymous classes and `::class` constants. Namespace, declaration kind, inheritance, interfaces, documentation, imports, license material, and body are recovered through their corresponding paths.

Body extraction is checked against the located declaration. A body that cannot be matched to that declaration is not silently replaced with an empty body. An actually empty class and a failed extraction are different observations.

The reader can recognize syntax that the Power model does not represent completely. For example, the inspected stored type vocabulary does not preserve every modifier or declaration form. Selection and reporting must be interpreted against that vocabulary; lexical recognition alone is not a claim of lossless translation of arbitrary PHP. [X03](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#x03)

## Namespace and filesystem structure jointly inform placement

A class's declared namespace and the folders containing it often encode the same structure. The namespace resolver compares the relevant trailing segments and identifies the boundary between the retained vendor portion and the dotted stored path representation used by Powers.

A dotted library folder can explicitly identify its own namespace head. Otherwise, the namespace/path correspondence supplies the boundary, with a conventional fallback where a reliable path correspondence is unavailable.

The conceptual operation is

$$
\operatorname{placement}(n,p,c)=
(\text{stored namespace},\text{source role},\text{context bindings}),
$$

where $n$ is the declared namespace, $p$ the physical path information, and $c$ the class name. The three inputs constrain the answer. A short class name alone cannot determine its correct identity or owner.

## Concrete names become contextual again

Compilation specializes placeholder names into a particular application. Recovery reverses supported occurrences of those names into the stored placeholder representation. The namespace resolver records the concrete vendor and recognized component segments whose values must later be supplied by the paired component.

The class assembler also reverses supported language constants into their source text before storing code. Otherwise, a later compiler pass could generate a new language key from an already generated key. This is a concrete example of recovering the right *representation*, not merely preserving the visible output string.

The operation is bounded by the recognized naming and language conventions. It is not an arbitrary semantic renaming of every string that happens to resemble a component name.

## Imports and relationships use qualified identities

Class, function, and constant imports occupy different symbol namespaces. The assembler interprets the supported class imports, inherited types, and implemented interfaces using the declaration's namespace and existing aliases. It connects known identities to Power selections and preserves unresolved source relationships through the applicable code representation.

Existing Power matching uses qualified namespace information and the stored forms established by the resolver. Candidate selection and pairing remain separate from the textual similarity of two bodies. Reusing a class from another component merely because its short name is the same would not be a sound identity rule.

The [pairing chapter](https://architecture.joomlacomponentbuilder.com/markdown/extrusion/pairing.md) explains the selected-component context and explicit decisions. This edition records the implemented matching rules rather than treating every candidate suggestion as an infallible ownership proof.

## Recover, then use the ordinary compiler

Once written, a recovered Power is processed by the existing loader and injector. Its relationships can trigger dependency acquisition; its placeholders receive the destination context; its namespace and file-local aliases are resolved; its source is placed according to its role.

The reverse path is valuable because it reconnects existing code to those reusable mechanisms. It can preserve authored implementation while recovering enough structure for managed reuse and regeneration, rather than forcing a developer to re-enter every class manually.

For another language, the equivalent operation would parse supported module/type declarations, retain authored bodies, recover imports and ownership, map physical placement to the module system, and persist the result as reusable compiler input. The details of PHP syntax are replaceable; the identity and representation boundaries are not.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/extrusion/pairing.md

# Pairing, sharing, and ordered writes

Recovered structure must be connected to the destination model. Creating a fresh copy of every field or class would lose reuse. Updating an unrelated existing definition would corrupt another project's intent. Pairing therefore operates on identities, candidate kinds, and the selected component's relationships, with explicit decisions available before writing.

JCB retains those decisions in a separate registry. Writers consume them when selecting the identity and action for each candidate. [X04](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#x04)

## A candidate is not yet a database write

The candidate catalogue groups recovered items by kind and relates them to definitions associated with the selected component. GUID matches and scoped name matches can suggest an existing target. A recovered item with no suitable match can propose creation.

The proposal contains more information than a short name: its kind, source key, recovered properties, context, and proposed target matter. Candidates for fields, views, code definitions, and relationships have different matching responsibilities.

The developer's choices are represented by `create`, `update`, and `ignore`. An update identifies its selected target. An ignore prevents that candidate from being written. A create can derive a distinct stable identity rather than accidentally reuse the identity already held by another definition.

## Decisions have precedence over automatic settlement

The pairing resolver validates the action and the target identity. Its automatic settlement path does not overwrite a verdict already recorded by the caller. Sharing and reuse therefore use the same decision channel as human approval rather than introducing a hidden second authority.

For candidate $q$ and verdict $v$, the selected identity is

$$
\iota(q,v)=
\begin{cases}
\bot, & v=\mathrm{ignore},\\
\operatorname{target}(v), & v=\mathrm{update},\\
\operatorname{derive}(\mathrm{kind}(q),\mathrm{forcedNew},\iota_0(q)), & v=\mathrm{create},\\
\iota_0(q), & \text{no explicit verdict}.
\end{cases}
$$

Here $\bot$ means no write for that candidate, and $\iota_0$ is its derived or recovered identity. The source's deterministic derivation is a naming mechanism, not a proof that two arbitrary artifacts have identical semantics.

Decision keys preserve the boundary between view and column segments. Collapsing `invoice.line_total` and `invoice_line.total` into one flattened key would lose a real distinction; the resolver retains that separation.

## Shared fields are settled before association writes

Several recovered views can describe the same reusable field. Sharing resolution groups compatible candidates, selects a shared identity, and records how their views should link to it. Explicit decisions still take precedence.

The architectural objective is to recover the definition/occurrence distinction: one field definition can serve several associations. Consolidation is not simply deduplication by display label. The field's represented structure and the resolver's compatibility rules determine whether sharing is appropriate.

The report records shared and consolidated fields so that a smaller written count is explained rather than mistaken for silent loss. This is another reason a raw number of inserted rows is not a sufficient description of extrusion.

## Writing follows dependency order

The dispatcher writes component details first. When administrator modeling is enabled, fields precede admin views, their field associations, and conditions. Dynamic Gets precede the corresponding site-view and custom-admin-view relationships. Component links are completed after the definitions they reference.

This ordering permits later writers to use the identities established by earlier ones. Let $w_i\prec w_j$ mean writer $j$ requires an identity or record produced by writer $i$. The dispatcher supplies an execution order compatible with its supported dependency relation.

The source does not wrap every writer in a single global transaction. Individual write results and failures remain part of the report. A portable implementation must distinguish dependency order from atomic commit: one does not imply the other.

## Existing-item policy and review policy are different controls

The general `onExisting` selection governs supported skip, update, or replace behaviour. Pairing decisions select a candidate's target and whether it should be written. Dry-run selection allows the relevant writer paths to report intended work without persisting it.

These controls should not be collapsed into one Boolean called “overwrite.” They address different questions: which definition is this, what should happen where it already exists, and should this run apply the resulting writes?

## Diagnostics complete the recovery account

The extruder reports unreadable artifacts, unresolved field types, absent translations, duplicate candidate view names, dropped conditions, and deliberate skips. A completed run can therefore be useful without pretending that every property of every source artifact was recoverable.

The report's completion flag means the orchestration reached its defined completion path. It does not erase the per-item record. The same distinction is used by the forward compiler's artifacts and diagnostics. [Execution](https://architecture.joomlacomponentbuilder.com/markdown/compiler/execution.md)

Pairing completes the bridge back to normal development. The resulting local graph has explicit identities and relationships, can be edited in the GUI, can be exported as a blueprint, and can be compiled through JCB's ordinary generators. The architecture makes recovered information usable rather than leaving it as a disconnected source archive.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/examples/hello-world.md

# Hello World — blueprint to three products

The Hello World example makes the compiler's representation boundaries inspectable. Its blueprint repository contains exported JCB definitions, relationship records, dependency descriptors, indexes, generated descriptions, and assets. Its three output repositories contain the generated component, module, and plugin.

The example deliberately places recognizable comments in GUI-backed code properties. Those comments let a reader follow authored material through its stored property and into the generated method or file. Field identifiers and contextual names provide a second trace through the compiler's derived output.

## The four repositories

| Representation | Pinned source |
| --- | --- |
| Portable design | [Hello World blueprint](https://github.com/vast-development-method/hello-world-blueprint/tree/5802e7c1d9bfaac005c765ccda830a7d07cd7e12) |
| Component product | [Hello World component](https://github.com/vast-development-method/hello-world-joomla-component/tree/a81c0dd8b8f41905671a86796a3e5995685fdaba) |
| Module product | [Site Redirect module](https://github.com/vast-development-method/hello-world-joomla-module/tree/20be318a6163e253c2a9803434622467d6006709) |
| Plugin product | [Hello World Privacy plugin](https://github.com/vast-development-method/hello-world-joomla-plugin/tree/6a785145ee84212fec65a53b7c6c362ab0f8b408) |

The repository names identify their roles; the commits fix the examined snapshots. Subsequent repository changes do not silently change the examples in this edition.

## Start with the component identity

The root component is `3745af8f-f96b-4e17-831e-eb4062cd4389`. Its payload selects the name `HelloWorld`, namespace prefix `JCB`, component version `6.0.0`, and preferred Joomla target 6. Its dependencies identify component associations, configuration, reusable code, and assets.

The root is not the entire blueprint. Component child records connect it to its admin view, site views, module, plugin, routing, dashboard, and updates. The admin view then connects to field associations and custom tabs. Referenced fields point to their types; plugin definitions point to their group, base-class information, methods, and properties.

This is a typed graph, not a single JSON form whose every property maps to one output line. [Blueprint representation](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/representation.md)

## The main visible entities

| Entity | Portable identity |
| --- | --- |
| Hello World component | `3745af8f-f96b-4e17-831e-eb4062cd4389` |
| Greeting admin view | `65116558-be67-4931-95be-727fbfb16db7` |
| Greeting field | `75e830a6-a3a5-4327-9161-3f774a6f1591` |
| Site Redirect module | `21c9f6f5-3193-485d-94e7-f9c789a9fa2e` |
| Privacy plugin definition | `8aa96d76-94e3-47d1-8dd8-f430b72ed0f7` |
| Reusable README contribution | Function-name key `readMEcontributors` |

The repository contains five field definitions, two site views, two Dynamic Gets, and the code-related definitions required by its plugin example. Some required field types are supplied by the configured external field-type repository rather than duplicated into this blueprint snapshot. The local-first dependency process makes that distinction operational. [Discovery](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/discovery.md)

## What import reconstructs

An ordinary import resolves the selected root, creates missing local definitions, follows its supported dependency descriptors, and transports required assets. Existing local definitions can remain authoritative under initialization policy; an explicit reset requests the corresponding refresh behaviour.

The destination database assigns its own local record identities. Portable GUIDs and declared relationship keys preserve the design graph. The editor can then present the imported fields, views, code, and extension relationships as local working definitions.

Compilation consumes that local graph together with its target rules, templates, reusable libraries, and environment. The output is the native extension tree, not a runtime interpreter for the JSON blueprint. [Import](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/import.md), [Execution](https://architecture.joomlacomponentbuilder.com/markdown/compiler/execution.md)

## Three complementary traces

The [Greeting field trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/field-trace.md) follows a small declaration into its form, SQL, language entries, list behaviour, and generated metadata. The index derived from its title role is particularly instructive: it appears even though the field's isolated explicit-index property is zero.

The [custom-code trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/custom-code-trace.md) follows stored code properties into controller, model, view, and installer locations. It also explains why identical marker text in two properties must not be mistaken for one unique origin.

The [extension trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/extension-trace.md) follows module fields and code, plugin class relationships, component-sensitive naming, and target-specific file structures. It shows reuse across different product contexts rather than only across files in one component.

## What the example measures

The blueprint's 33 payload JSON files occupy 65,600 bytes and 1,298 physical text lines. The three product repositories contain 32,988 physical text lines across 286 text files, within 290 files in total. Indexes, documentation, supplied library code, and binary assets are separately identified in the [accounting chapter](https://architecture.joomlacomponentbuilder.com/markdown/examples/accounting.md).

These figures describe the pinned representations. They do not turn escaped JSON code strings into a claim about hand-written effort, and they are not the separate JCB self-build timing measurement.

The example's principal value is the trace itself: the same identified design choices can be seen before compilation and in their coordinated implementation afterward. The [formal transport model](https://architecture.joomlacomponentbuilder.com/markdown/formal/transport.md) explains what must be held fixed when repeating that lifecycle in another installation.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/examples/field-trace.md

# The Greeting field across the compiler

The Greeting field is a compact example of contextual compilation. Its definition does not explicitly contain a form file, SQL statement, list header, sort option, language catalogue, or table metadata class. It supplies properties which, together with its view association and compiler rules, produce those coordinated artifacts.

The field's portable identifier is **`75e830a6-a3a5-4327-9161-3f774a6f1591`**. The admin view using it is **`65116558-be67-4931-95be-727fbfb16db7`**. [Definition](https://github.com/vast-development-method/hello-world-blueprint/blob/5802e7c1d9bfaac005c765ccda830a7d07cd7e12/src/field/75e830a6-a3a5-4327-9161-3f774a6f1591/item.json)

## The reusable definition

The field selects a text field type, the logical name `greeting`, and the label `Greeting`. Its database properties describe `VARCHAR` with length 255, nullable storage, and no explicit index selection. Its XML properties include a displayed size of 10, a maximum input length of 50, and the default text `Some text`.

Database width, form width, maximum input length, and form default are different decisions. The compiler does not need to flatten them into one generic “field size.” The distinction remains visible in the generated artifacts.

The field type is another identified definition, `201327fe-3067-4316-a155-3fe2a52e05c0`, supplied through the field-type distribution mechanism. Its identity is not the identity of this particular Greeting field.

## The occurrence adds its roles

The [admin-fields association](https://github.com/vast-development-method/hello-world-blueprint/blob/5802e7c1d9bfaac005c765ccda830a7d07cd7e12/src/admin_view/children/65116558-be67-4931-95be-727fbfb16db7/admin-fields.json) supplies:

```json
{
  "field": "75e830a6-a3a5-4327-9161-3f774a6f1591",
  "list": "1",
  "order_list": "1",
  "title": "1",
  "sort": "1",
  "search": "1",
  "link": "1",
  "tab": "1",
  "alignment": 1,
  "order_edit": "1"
}
```

This is the use of the field in the Greeting view. The view maps its first tab to `Details`. The component supplies the extension name and language prefix. The target supplies the emitted Joomla conventions.

In the formal vocabulary, the field is $d$, the association is an occurrence $o$, and those surrounding values form $\Gamma(o)$. The generated contributions are $J(d,\Gamma(o))$.

## The generated projections

| Concern | Observed result | Output location |
| --- | --- | --- |
| Database column | `greeting VARCHAR(255)`, nullable with the emitted default | `admin/sql/install.mysql.utf8.sql`, line 8 |
| Database index | Ordinary `idx_greeting` key | Same SQL file, line 25 |
| Editor | Text field named `greeting`, maximum 50, default `Some text` | `admin/forms/greeting.xml`, lines 120–138 |
| Language | `COM_HELLOWORLD_GREETING_GREETING_LABEL` maps to `Greeting` | Administrator language catalogue |
| List sorting | The header and sort choices refer to the resolved `a.greeting` column and label | `admin/tmpl/greetings/default_head.php`; Greetings view class |
| Table metadata | Same GUID, title status, list `greetings`, tab `Details`, `VARCHAR(255)`, ordinary key | `libraries/jcb_powers/JCB.Joomla/src/Helloworld/Table.php`, lines 73–96 |

Inspect the [form](https://github.com/vast-development-method/hello-world-joomla-component/blob/a81c0dd8b8f41905671a86796a3e5995685fdaba/admin/forms/greeting.xml#L120-L138), [SQL](https://github.com/vast-development-method/hello-world-joomla-component/blob/a81c0dd8b8f41905671a86796a3e5995685fdaba/admin/sql/install.mysql.utf8.sql#L1-L30), and [table metadata](https://github.com/vast-development-method/hello-world-joomla-component/blob/a81c0dd8b8f41905671a86796a3e5995685fdaba/libraries/jcb_powers/JCB.Joomla/src/Helloworld/Table.php#L73-L96). The related administrator and site outputs share the interpreted model through their selected generation paths.

## Why an index appears without an explicit index request

The isolated field has its explicit index setting at zero. Its association makes it the title field. In the applicable non-text schema branch, the compiler gives title, alias, and category roles an ordinary index where a unique-key selection does not take precedence.

For this occurrence:

$$
\mathrm{explicitIndex}=0,\quad \mathrm{title}=1,\quad
\mathrm{textFamily}=0
\quad\Longrightarrow\quad\mathrm{ordinaryKey}=1.
$$

This is not unexplained extra code added by a template. It is a derived consequence of the field's contextual role, retained for both SQL and metadata emission. The [schema chapter](https://architecture.joomlacomponentbuilder.com/markdown/generation/schema.md) gives the branch structure and source correspondence.

## Names are completed in context

The blueprint's label `Greeting` becomes an extension- and view-qualified language key. The list query refers to the field under its source alias. The table metadata carries its portable GUID and role information. These representations differ because they serve different consumers, while still tracing back to the same identified use.

A reimplementation can use different syntax for the SQL, form description, or language catalogue. It should retain the relationship between the common field decision and each emitted projection.

## The architectural observation

A field does not become important by producing many lines. It becomes architecturally interesting when one represented decision must remain coherent across independent runtime concerns. Here the compiler coordinates storage, input, labels, listing, sorting, and generated metadata through retained intermediate interpretations.

The example is small enough to inspect completely and broad enough to show why the central operation is semantic classification rather than simple copying. [Classification](https://architecture.joomlacomponentbuilder.com/markdown/compiler/classification.md), [Formal classification](https://architecture.joomlacomponentbuilder.com/markdown/formal/classification.md)


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/examples/custom-code-trace.md

# Tracing GUI code to its destination

Hello World's blueprint deliberately contains recognizable comments in GUI-backed custom-code properties. The generated component retains those comments at the positions supplied by the corresponding compiler consumers. This lets the reader connect an editor decision to a model property, a preparation path, a binding context, and a final artifact.

The comments are diagnostic markers for this demonstration. Their presence is not a claim that the comments themselves implement application logic. The surrounding generated code shows where actual authored logic in the same property would participate.

## A property is a role, not an arbitrary paste location

The admin-view payload includes properties for post-save hooks, before-save code, save code, list-query preparation, item processing, document preparation, batch operations, access decisions, and JavaScript/CSS contributions. Each property has a defined consumer in the compiler.

The component payload also contains installer-related code properties. Other definitions, such as Dynamic Gets and site views, carry their own role-specific code. [Blueprint admin view](https://github.com/vast-development-method/hello-world-blueprint/blob/5802e7c1d9bfaac005c765ccda830a7d07cd7e12/src/admin_view/65116558-be67-4931-95be-727fbfb16db7/item.json)

## Selected exact correspondences

| Source property | Destination in the component snapshot |
| --- | --- |
| Component `php_preflight_install` | `HelloworldInstallerScript.php`, line 272 |
| Admin view `php_postsavehook` | `admin/src/Controller/GreetingController.php`, line 386; corresponding site controller, line 379 |
| Admin view `php_before_save` and `php_save` | `admin/src/Model/GreetingModel.php`, lines 606 and 611; corresponding site model, lines 613 and 618 |
| Admin-view document code | `admin/src/View/Greeting/HtmlView.php`, around line 385; corresponding selected site-edit view also contains the marker |
| List-query preparation code | `admin/src/Model/GreetingsModel.php`, in its generated query path |

The [installer](https://github.com/vast-development-method/hello-world-joomla-component/blob/a81c0dd8b8f41905671a86796a3e5995685fdaba/HelloworldInstallerScript.php#L260-L280), [controller](https://github.com/vast-development-method/hello-world-joomla-component/blob/a81c0dd8b8f41905671a86796a3e5995685fdaba/admin/src/Controller/GreetingController.php#L375-L392), and [save method](https://github.com/vast-development-method/hello-world-joomla-component/blob/a81c0dd8b8f41905671a86796a3e5995685fdaba/admin/src/Model/GreetingModel.php#L595-L620) provide inspectable output anchors. The [source map](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c09) identifies the code-preparation and dispenser responsibilities.

## Identical text is not unique provenance

The `php_before_save` and `php_save` properties deliberately contain the same comment. The generated method therefore contains two occurrences. The document marker is also reused in several source definitions, and similar query comments can occur in both admin-view and Dynamic Get records.

A text search proves that the marker appears; it does not alone prove which of several equal source values supplied a particular occurrence. The stronger trace combines the property role, enclosing generated method, source reference, and compiler consumer.

This is why the architectural relation records an occurrence and role rather than using the code body's hash as its sole identity. Equal text can have different intended positions; different contextual expansions can originate from the same reusable body.

## Preparation and binding are distinct steps

The dispenser can decode and prepare the code, expand supported custom or external references, add selected GUI markers, and retain it by role and context. The relevant creator later retrieves it under the active placeholder environment and adds the surrounding material required by that output position.

The trace is therefore

$$
\text{GUI property}\to\text{stored body}\to\text{prepared fragment}
\to\text{contextual retrieval}\to\text{generated method position}.
$$

The body can remain reusable while its surrounding namespace, view names, language keys, or component references are completed at the point of use. [Custom code](https://architecture.joomlacomponentbuilder.com/markdown/compiler/custom-code.md), [Binding](https://architecture.joomlacomponentbuilder.com/markdown/compiler/binding.md)

## A reusable contribution can target documentation

The component's README design uses the custom-code alias `readMEcontributors`. Its payload lives at `src/custom_code/readMEcontributors/item.json`, and the generated README contains the expanded contribution.

This example crosses a useful boundary. The managed code mechanism does not require every contribution to become a PHP method. It can supply reusable material to another generated artifact, including documentation. The output may carry an insertion marker with a local record number; that number is a recovery address, not the portable alias itself.

## Regeneration and recovery use additional identities

When GUI markers are enabled, they connect eligible generated regions to their local table, property, and record. Fingerprint-based custom-code placement additionally records surrounding location context. Those recovery identities connect selected edits to a later build.

The demonstration's inserted comments and JCB's actual recovery markers have different roles. The former make the example readable. The latter supply the machine-recognized addresses used by extraction and reconciliation.

The result is a traceable route for authored decisions through generation. It is neither an arbitrary final text append nor a general promise to infer every modification made anywhere in an output tree.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/examples/extension-trace.md

# The module and plugin contexts

Hello World's component blueprint links a Site Redirect module and a Privacy plugin. Both are represented as their own definitions. They share the acquisition and compilation infrastructure while receiving extension-specific names, namespaces, language contexts, manifests, and generated files.

The example demonstrates that context is not limited to switching between two forms inside one component. It also selects how a definition becomes a different kind of deployable product. [Extension generation](https://architecture.joomlacomponentbuilder.com/markdown/generation/extensions.md)

## The module supplies intent and authored behaviour

The module identity is `21c9f6f5-3193-485d-94e7-f9c789a9fa2e`, with name `SiteRedirect`. Its configuration references the Redirect field `12035b51-753b-4e3f-9f41-cde3a6046286`. That field in turn connects to the represented groups and URL controls used by the configuration structure.

The module's authored code reads the configured redirect entries, obtains user groups, compares them with the selected groups, and performs the corresponding redirect. It also invokes the selected module layout through a Joomla Power reference and a module-name placeholder. [Module payload](https://github.com/vast-development-method/hello-world-blueprint/blob/5802e7c1d9bfaac005c765ccda830a7d07cd7e12/src/joomla_module/21c9f6f5-3193-485d-94e7-f9c789a9fa2e/item.json)

These are two kinds of input: a structured field/configuration graph and an explicitly authored operation. The compiler does not invent the redirect business rule. It provides the target's extension structure, resolves the selected references, constructs field configuration, and places the authored rule in that structure.

## Its output is a native module tree

The pinned [module product](https://github.com/vast-development-method/hello-world-joomla-module/tree/20be318a6163e253c2a9803434622467d6006709) contains `src/Dispatcher/Dispatcher.php`, `services/provider.php`, `tmpl/default.php`, `mod_siteredirect.xml`, language files, installer code, and supporting directories.

The target-specific module infuser supplies the provider and dispatcher arrangements. Fieldset generation supplies the configuration representation. Language handling provides the selected module labels and messages. Placeholder and Joomla Power processing resolve the template's and authored code's platform references.

The module version stored in its definition is its own extension version; it is not the Joomla generation target. Those two values must not be conflated when examining the payload.

## The plugin's name is completed by its use

The plugin identity is `8aa96d76-94e3-47d1-8dd8-f430b72ed0f7`. Its name property is `[[[Component]]]`, not a permanently fixed Hello World name. The component context supplies that placeholder when the plugin is generated.

The plugin references its group, base-class information, three methods, and three properties through typed dependency descriptors. Its portable definition therefore includes both reusable class structure and a context-sensitive naming decision. [Plugin payload](https://github.com/vast-development-method/hello-world-blueprint/blob/5802e7c1d9bfaac005c765ccda830a7d07cd7e12/src/joomla_plugin/8aa96d76-94e3-47d1-8dd8-f430b72ed0f7/item.json)

In the [generated plugin](https://github.com/vast-development-method/hello-world-joomla-plugin/tree/6a785145ee84212fec65a53b7c6c362ab0f8b408), the corresponding files include `src/Extension/Helloworld.php`, `services/provider.php`, `helloworld.xml`, language material, and installer code.

This is a direct instance of

$$
\operatorname{name}(d,\Gamma_{\mathrm{HelloWorld}})
=\mathrm{Helloworld}.
$$

The exact case follows the naming rule of the selected output role. The portable identity does not change merely because a name is specialized for this occurrence.

## Context is established before content is assembled

Module and plugin infusers set their own build area, language target, and prefix before generating their content. They prepare their corresponding shared/contextual placeholder maps and select target-specific architecture services.

The same generic string can therefore be inappropriate in two contexts even where both outputs belong to one overall build. A module label must not accidentally inherit the component's prefix. A plugin class must use its plugin namespace and group conventions. A file-local Power alias is resolved within the imports of that particular file.

These relationships explain why reusable intermediate stores require explicit scope and a defined lifecycle. They are not incidental bookkeeping around an otherwise context-free template.

## Product identity and blueprint identity stay separate

The component's module and plugin association records describe which definitions participate in the product family. Each resulting extension tree has its own installation identity and archive path. A changed association, target rule, field definition, or reusable method can consequently affect different parts of that family.

The compiler maintains the connection between the model and those outputs. The generated application code does not require JCB to be installed alongside every deployed product, except for dependencies explicitly selected by the design.

The [accounting chapter](https://architecture.joomlacomponentbuilder.com/markdown/examples/accounting.md) counts these products separately, and the [formal model](https://architecture.joomlacomponentbuilder.com/markdown/formal/classification.md) represents their shared definitions and distinct occurrences without assigning a one-definition-to-one-file rule.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/examples/accounting.md

# Blueprint and product accounting

A useful size comparison identifies exactly what is counted. A blueprint repository contains authoritative entity payloads as well as indexes, generated explanations, assets, and license material. An output repository contains synthesized application code, supplied reusable classes, assets, and descriptive files. Combining all of those into one unexplained input number would obscure the architecture.

The figures below count the [pinned Hello World snapshots](https://architecture.joomlacomponentbuilder.com/markdown/examples/hello-world.md). They are static repository inventories, separate from the maintainer's timed JCB self-build measurements.

## Portable design and supporting repository material

| Category | Files | Physical text lines | Bytes |
| --- | ---: | ---: | ---: |
| Entity and relationship payload JSON under `src/` | 33 | 1,298 | 65,600 |
| Index JSON under `index/` | 22 | 269 | 11,885 |
| Markdown descriptions | 22 | 1,198 | 100,268 |
| Transported assets | 4 | 18 in the text asset | 68,416 |

The 33 payloads comprise 24 root `item.json` records and nine child relationship/configuration documents. The four assets comprise three images and one text file. The repository also carries its license. Index and Markdown categories describe or locate the model; they are not added to the payload count as if they were independent application decisions.

The payload files contain 65,600 serialized bytes. Embedded code can be represented with escaped newlines inside JSON strings. Consequently, 1,298 physical JSON lines is a property of this serialization, not a count of logical statements, distinct decisions, or authored code lines after decoding.

## Generated product repositories

| Product | All files | UTF-8 text files | Physical text lines |
| --- | ---: | ---: | ---: |
| Component | 259 | 255 | 31,981 |
| Module | 19 | 19 | 540 |
| Plugin | 12 | 12 | 467 |
| **Combined** | **290** | **286** | **32,988** |

The combined physical-text expansion relative to the serialized payload's physical lines is approximately **25.4 times**. This is a descriptive ratio between two specified representations. It is not a compression bound, a measure of manual labor, or an attribution of every output byte solely to the project payload.

The compiler's rules, target templates, reusable Powers, libraries, assets, and environmental values are additional build inputs. The output includes their selected generation and assembly results.

## Counting rule

The inventory visits regular files recursively, outside Git's own metadata. For a text-line count, it accepts files that decode as UTF-8 and contain no NUL character, then counts physical lines using the decoded text's line boundaries. Binary files remain in the total file count and byte inventory but not the text-line count.

Payload selection is structural: JSON below `src/`, with root item records and child documents counted separately. Index selection is JSON below `index/`. Markdown descriptions are selected by their `.md` extension. The asset category follows `src/file_folder/`.

This rule deliberately avoids guessing which generated file was “important enough” to count. A narrower runtime-only, executable-only, or dependency-excluding analysis would be a different metric and should publish its own selection rule.

## Internal build counters are a different observation

The generated component README includes compiler-produced line, file, and folder counts and illustrative time-saving calculations. They need not equal this later repository inventory. Counter update points, added repository descriptions, copied dependencies, and later repository changes can alter the counting boundary.

The README's estimates based on seconds per line or file are formulas, not measured developer hours or measured compiler elapsed time. They are not used here as productivity evidence. The [performance chapter](https://architecture.joomlacomponentbuilder.com/markdown/engineering/performance.md) instead separates actual compilation timing from output volume and hypothetical labor estimates.

## Why the distinction strengthens the example

The blueprint is compact because repeated implementation knowledge resides in reusable generation rules and supplied definitions. The output is large because those inputs are specialized and distributed across a complete application's concerns. There is no need to pretend the compiler invents reusable class bodies during each run for this to be a meaningful capability.

The more informative observation combines quantity with traceability. The Greeting field's SQL, form, language, list, and metadata outputs can be connected to its properties and occurrence roles. The module and plugin outputs can be connected to their definitions and component context. The count describes their scale; the trace explains their origin.

## Repeating the inventory

The repository provides `scripts/research_inventory.py` to inventory local checkouts of the four example repositories without running their code. Its output records revision identifiers, categories, file hashes, and marker correspondences. Running the inventory is not a fresh Joomla compilation; repeating the full build additionally requires the selected JCB environment and dependencies. [Verification](https://architecture.joomlacomponentbuilder.com/markdown/engineering/verification.md)

Fixing those two boundaries allows both operations to be useful: an artifact inventory can be reproduced quickly, and a runtime build can be compared under its declared configuration without confusing the two experiments.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/examples/service-directory.md

# 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](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#e05)

## Two versioned component identities in the blueprint repository

The pinned [Joomla packages repository](https://github.com/joomengine/joomla-packages/tree/5e8733cb82c4467cf5e0a39c05a0133b457fec80) 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](https://github.com/joomengine/Joomla-Service-Directory/tree/0ac9788cb9239ed2801ba19c7e2393c70e03f9c4) 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](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#e06) 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](https://architecture.joomlacomponentbuilder.com/markdown/engineering/verification.md) 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.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/formal/notation.md

# Mathematical vocabulary and domains

The formal model describes the operations developed in the preceding chapters. It removes dependence on PHP syntax while retaining the distinctions that affect behaviour: typed identity, occurrence context, ordered mutation, deferred work, external observations, and staged artifacts.

A symbol denotes a role in the computation. It need not correspond to one allocated class or database table. For example, the context of a JCB operation can be distributed across arguments, association records, configuration, and store keys.

## Basic domains

| Symbol | Meaning |
| --- | --- |
| $\mathcal{T}$ | Supported entity types |
| $\mathcal{U}$ | Normalized portable requests $u=(t,k,v)$ |
| $D$ | Local definitions and relationships |
| $G=(V,E)$ | Resolved typed definition graph |
| $\mathcal{O}$ | Contextual occurrences of definitions |
| $\Gamma$ | Interpretation context |
| $J$ | A selected interpretation operation |
| $\mathcal{C}$ | Typed contributions to intermediate state |
| $M$ | Family of intermediate stores |
| $W$ | Retained deferred operations |
| $P$ | An ordered binding environment |
| $A$ | Staged or completed artifact collection |
| $\Delta$ | Diagnostics and operation results |
| $\Sigma$ | Complete abstract machine state |
| $\tau$ | An ordered execution trace |

$T$ denotes a generation target, such as an output platform version. It is distinct from $\mathcal{T}$, the set of entity types. $C$ denotes build configuration; calligraphic $\mathcal{C}$ denotes contributions.

## Identity and occurrence

A portable request is $u=(t,k,v)$: entity type, identifying field, and normalized value. A GUID-addressed field and a function-name-addressed custom-code item are both valid instances. A local realization $\lambda_i(u)$ assigns an installation-specific record identity.

An occurrence is

$$
o=(u,p,a),
$$

where $p$ identifies its position in an association/expansion and $a$ contains use-specific settings. Its context can be represented as

$$
\Gamma(o)=(T,e,v,r,\ell,P,a).
$$

The components identify target, extension, view or use-site, generation role, language destination, binding environment, and additional settings. Only the dimensions actually read by an operation determine that operation's reuse boundary. [Context](https://architecture.joomlacomponentbuilder.com/markdown/foundations/context.md)

## Partial maps, sequences, and sets

$X\rightharpoonup Y$ denotes a partial function: some inputs have no result. A store is usually a partial map from keys to typed values. The symbol $\bot$ denotes absence or an undefined result where the surrounding definition specifies that meaning.

$\langle x_1,\ldots,x_n\rangle$ denotes an ordered sequence. $S\cup R$ denotes set union. $s\mathbin{\|}t$ denotes sequence or string concatenation, as declared by the value type. These operations are not interchangeable. Appending two identical fragments retains both; set union does not.

A replacement map is an ordered sequence of key/value pairs because JCB's replacement semantics can consume tokens introduced by an earlier pair. [Staging](https://architecture.joomlacomponentbuilder.com/markdown/formal/staging.md)

## Contributions and effects

An interpretation returns an ordered sequence

$$
J(d,\Gamma)=\langle c_1,\ldots,c_m\rangle,
\qquad c_i=(s_i,k_i,\omega_i,v_i).
$$

A contribution selects a store, key, update operation, and value. An operation can overwrite, fill an absent value, append, concatenate, remove, or enqueue work. The contribution vocabulary explains effects; it does not force every result into a set of immutable facts.

For an operation $f$, $\operatorname{read}(f)$ and $\operatorname{write}(f)$ name its relevant state locations. External reads are included through the observed input stream. The [state model](https://architecture.joomlacomponentbuilder.com/markdown/formal/state.md) makes their order explicit.

## Artifacts and observation

An artifact has a logical role, destination, context, content, and remaining stages. The collection can include skeletons, prepared files, supporting assets, metadata, and archives. The predicate $\operatorname{complete}(a)$ is relative to the stages required for that artifact.

An observation function $\operatorname{obs}$ selects what a comparison measures: blueprint-relevant design, generated runtime structure, normalized text, raw bytes, or diagnostics. Equality of one observation does not imply equality of every other observation.

We use $\equiv_B$ for normalized blueprint-design equivalence and $\equiv_A$ for an explicitly chosen artifact equivalence. Raw byte equality remains ordinary equality over bytes. [Transport](https://architecture.joomlacomponentbuilder.com/markdown/formal/transport.md)

## Finite builds and unrestricted application families

Each completed build has finite inputs and outputs. The architecture can admit an unbounded family of finite application descriptions without one build containing infinitely many entities or producing infinitely many bytes.

Termination arguments therefore concern the requests reachable in a particular operation and the completion of its handlers. Expressive breadth concerns the family of descriptions and authored extensions admitted by the model. Neither is established merely by counting output lines.

## How to read the propositions

Each proposition states assumptions, a conclusion, and the argument connecting them. They explain a bounded mechanism: traversal, reuse, sequencing, or transport. Their mathematical tools have established precedents in compiler construction, program semantics, and model transformation. [Bibliography](https://architecture.joomlacomponentbuilder.com/markdown/reference/bibliography.md)

The implementation correspondence identifies where JCB realizes the relevant responsibilities. A proof about the explicit model applies to an implementation path only where its assumptions hold. Keeping those assumptions local makes the account useful for both source review and an independent implementation.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/formal/state.md

# Operational state and execution traces

The complete compiler is an effectful process. It reads definitions, can acquire remote material, updates shared stores, creates and rewrites files, recovers designated code, and records messages. Its mathematical representation must include those operations rather than treating compilation as one pure substitution over an already complete dictionary.

## State components

For one invocation, define

$$
\Sigma=(q,D,K,O,M,W,P,A,X,\Delta).
$$

$q$ is control state, including the current phase and call/continuation position. $D$ is local design state. $K$ records acquisition attempts and outcomes. $O$ contains established occurrences and contextual selections. $M$ is the intermediate-store family. $W$ contains deferred operations. $P$ contains active binding environments. $A$ contains staged artifacts. $X$ records relevant external observations. $\Delta$ contains diagnostics and operation results.

The representation does not require all these values to be stored in one production object. It identifies the information necessary to explain observable execution.

An operation labelled $o$ produces a transition

$$
\Sigma\xrightarrow{o/x}\Sigma',
$$

where $x$ supplies an external observation when the operation reads one. A complete trace is a finite sequence of such transitions beginning with a build request and ending at the selected completion or failure state.

## Representative transition rules

A local acquisition reads a definition under its typed request and records a local result. A remote acquisition additionally chooses a configured source, reads its payload, maps it to local data, and records dependencies. The attempt guard is established at its prescribed point; the persistence result is a separate event.

Interpretation of an occurrence applies its contribution sequence:

$$
M'=\operatorname{foldApply}(J(d,\Gamma),M).
$$

A deferred-work transition appends an operation and its arguments to $W$. A replay transition removes or consumes work in the specified phase and applies its contributions. A binding transition transforms an artifact using the selected ordered environment. A write transition changes the physical-artifact observation and can update counters or diagnostics.

These rules retain replacement and removal. An output filename binding can change from one artifact to the next without violating the state model.

## Control state carries the actual order

JCB's constructor performs initialization and content preparation before the final orchestration method. Within preparation, admin interpretations and aggregates precede selected deferred work. File processing has its own shared-binding, contextual-binding, custom-code, event, and injection sequence.

The control component $q$ represents those ordering choices. It is not an invented opportunistic scheduler. A language-neutral implementation can encode the sequence using functions and phases, a state machine, or explicit tasks with equivalent prerequisites. [Execution](https://architecture.joomlacomponentbuilder.com/markdown/compiler/execution.md)

An artifact may exist while some of its stages remain. Let $S(a)$ be its outstanding stage sequence. A write to a skeleton does not imply $S(a)=\langle\rangle$. Completion is determined by the required operations, not by filesystem existence alone.

## External observations are part of effective input

Repository payloads, installed source files, configuration, event-handler behaviour, dates, locale, and filesystem results can affect output. For a comparison, their relevant observations are fixed or explicitly normalized.

Represent the effective invocation by

$$
I=(D_0,\Theta,T,C,H,\xi),
$$

where $\xi$ is the stream of external observations supplied at the corresponding reads. This is an analysis boundary. JCB need not prefetch the entire stream before beginning compilation.

## Proposition: repeatability of a prescribed trace

Assume the initial state is fixed, every operation is deterministic for its state and supplied observation, and the control policy chooses the same next operation from the same state. Then two executions with the same effective input have the same state at every corresponding step and therefore the same selected final observation.

**Argument.** Initial states are equal. If the states at step $i$ are equal, the control policy selects the same operation and the input stream supplies the same observation. Deterministic transition semantics then gives equal states at step $i+1$. Induction establishes equality through the common completion point.

This proposition allows ordered mutation. It does not require operations to commute. A different schedule can produce a different result while each prescribed schedule remains repeatable. [Staging](https://architecture.joomlacomponentbuilder.com/markdown/formal/staging.md)

## Observation and representation independence

Let $S$ be concrete implementation state and $\alpha(S)$ its abstract representation. A correspondence establishes that a concrete operation or finite sequence has the same relevant effect as an abstract transition:

$$
\alpha(S)\xrightarrow{*}\alpha(S').
$$

The star permits concrete housekeeping steps that do not change the selected abstract observation. For example, a database result can be decoded and indexed through several method calls before it is available as one modeled definition.

The source map supplies responsibility-level correspondences for this edition. It is not a machine-checked simulation proof of every method. Another implementation can use different physical representations while testing the same observations at the named boundaries.

## Failure and recovery remain visible

A transition can record a warning, reject a candidate, retain a commented code block, or stop a required operation. The final result is

$$
\operatorname{result}(\tau)=(A,\Delta,\operatorname{status}(q)).
$$

A success flag does not discard diagnostics. An unresolved optional translation and a failed required file write remain distinguishable. This gives the model enough information to describe both JCB's normal generation and its explicit recovery paths.

The following articles specialize this state model for [resolution](https://architecture.joomlacomponentbuilder.com/markdown/formal/resolution.md), [classification](https://architecture.joomlacomponentbuilder.com/markdown/formal/classification.md), [staging](https://architecture.joomlacomponentbuilder.com/markdown/formal/staging.md), and [transport](https://architecture.joomlacomponentbuilder.com/markdown/formal/transport.md).


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/formal/resolution.md

# Resolution, reachability, and termination

Resolution connects a portable request to an available local definition. Dependency traversal repeats that operation for requests exposed by the acquired material. The model separates selection, retrieval, persistence, and completion so that an attempt guard is not mistaken for proof of success.

## Local-first lookup

Let $u=(t,k,v)$ be a normalized request, $L(u)$ a local lookup, and $\mathcal{R}=\langle r_1,\ldots,r_n\rangle$ the configured repository order. For ordinary initialization,

$$
\operatorname{resolve}(u)=
\begin{cases}
L(u), & \text{an acceptable local definition exists},\\
\operatorname{persist}(\operatorname{map}(\operatorname{fetch}(r_j,u))), & \text{a repository is selected},\\
\operatorname{failure}(u), & \text{otherwise}.
\end{cases}
$$

The selected $j$ is the first applicable index match under the configured search contract. Payload retrieval and mapping can fail after selection. The model does not silently replace that contract with “try every later payload until one succeeds.” [Discovery](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/discovery.md)

Explicit reset changes the local-preservation decision. Recursive reset policy also depends on the edge role: owned incoming children can be refreshed while referenced reusable definitions continue through ordinary initialization. [Import](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/import.md)

## Request state and definition state

Use an attempted set $V$, a pending queue $Q$, a successful-resolution map $S$, and a failure map $F$. These are logical roles; the production implementation distributes its guards and result buckets across services.

```text
Q := normalized roots
V := empty
S := empty
F := empty
while Q is not empty:
    u := remove the next request
    if u is in V:
        continue
    add u to V before recursively exposed work can re-enter it
    result := resolve(u)
    if result supplies an accepted local definition:
        S[u] := result.definition
        append its supported discovered requests to Q
    else:
        F[u] := result.diagnostic
```

A request in $V$ has been attempted. A request in the domain of $S$ has an accepted definition. Those predicates have different meanings. A failure can leave the traversal finite but the requested graph incomplete.

## Proposition: termination of guarded traversal

Assume the reachable normalized request universe $U$ is finite, each handler completes, each first attempt enqueues only finitely many requests from $U$, and already-attempted requests do not enqueue new work on their duplicate visit. Then the loop terminates.

**Argument.** Consider the lexicographic measure

$$
\mu=(|U\setminus V|,|Q|)\in\mathbb{N}\times\mathbb{N}.
$$

A first attempt decreases the first component even if it increases the queue length. A duplicate visit leaves the first component unchanged and decreases the second by removing the queued request. Handler completion makes each transition finite. Lexicographic order on these natural-number pairs is well-founded, so there cannot be an infinite sequence of visits.

A cycle such as $u\to v\to u$ is therefore compatible with termination. The guard controls repeated processing; it does not require the dependency graph to be acyclic.

## Reachability describes the intended acquired graph

For a fixed dependency relation $\operatorname{deps}$ and roots $R_0$, define

$$
R_{i+1}=R_i\cup\bigcup_{u\in R_i}\operatorname{deps}(u).
$$

For finite $U$, the sequence stabilizes at the least dependency-closed set $R^*$ containing the roots. Each strict growth step adds a member of $U$; every closed superset containing the roots contains each $R_i$ by induction.

This is ordinary finite reachability/closure reasoning. It describes the requested dependency set, not every mutation and generation operation in the compiler. The source can realize the traversal through nested calls and queue drains rather than these mathematical rounds.

## Conditions for completeness are stronger than termination

Successful graph completion requires that every required request be resolved and that the supported dependencies of accepted records be accounted for. If a local-first path skips dependency examination on a local hit, completeness additionally relies on those local records already having the required local dependencies, or on another stage discovering them.

Formally, a successful result for the selected roots requires

$$
R^*\subseteq\operatorname{dom}(S)
$$

under the applicable validity policy. An empty pending queue alone does not establish that inclusion.

Likewise, a resolver can only close the relation it knows how to extract. Schema-described references and recognized literal code keys belong to that relation. Arbitrary runtime-computed references require a separate contract or runtime mechanism.

## Snapshot stability and schedule independence

When local data, repository selection, payloads, and dependency extraction are stable, different fair traversal orders can reach the same dependency set. Equality of that set does not establish equality of every intermediate side effect, database update sequence, or diagnostic order.

Where the selected payload depends on changing remote state or earlier mutations, resolution includes those observations. A permanent visited marker is insufficient for an algorithm whose earlier answers must be revised after new information appears. JCB's documented acquisition guards should be interpreted within their actual operation lifetime, not generalized into a universal knowledge-completion engine.

## Cost boundaries

With indexed guards and a represented finite graph, traversal bookkeeping can be proportional to visited requests plus discovered edges. Database operations, repository index fetches, payload transfers, parsing, and persistence add their own costs.

Caching a repository index amortizes repeated catalogue access. Retaining a resolved local definition avoids repeated network acquisition. Neither removes the cost of writing the required output or processing distinct contextual occurrences later. [Performance](https://architecture.joomlacomponentbuilder.com/markdown/engineering/performance.md)

The model isolates these responsibilities so that an implementer can change the transport or queue representation without changing typed identity, local-preservation policy, or the meaning of completion.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/formal/classification.md

# Context-qualified contributions and consistency

Classification maps one contextual use of a definition into the consequences needed by several generators. Its formal object is an ordered contribution sequence, not a single final string and not necessarily a monotone set of facts.

## A typed contribution algebra

Let $M_s:K_s\rightharpoonup V_s$ be store $s$. A contribution $c=(s,k,\omega,v)$ applies a declared update at address $(s,k)$. Typical operations include

$$
\operatorname{set}(M,k,v)=M[k\mapsto v],
$$

$$
\operatorname{append}(M,k,v)=M[k\mapsto M(k)\mathbin{\|}\langle v\rangle],
$$

with a declared empty sequence for an absent append value. `Fill` writes only when its chosen absence predicate holds; `remove` deletes the binding; concatenation joins text. A set-union operation is used only for values whose semantics are sets.

For $J(d,\Gamma)=\langle c_1,\ldots,c_m\rangle$,

$$
M_0=M,\qquad M_i=\operatorname{apply}(c_i,M_{i-1}).
$$

The final $M_m$ is the interpretation's store effect. A field can set a title binding, append a searchable member, add schema data, and concatenate code in one interpretation. Their different operations remain explicit.

## Occurrence expansion precedes projection counting

A definition graph can reuse one field in several views. Let $\operatorname{uses}(d)$ be its finite occurrence set. Total interpretation is over occurrences:

$$
\mathcal{C}_{\mathrm{build}}
=\mathop{\operatorname{concat}}_{o\in\mathcal{O}\text{ in prescribed order}}
J(\operatorname{definition}(o),\Gamma(o)).
$$

The count of definitions, occurrences, contributions, and files can therefore differ substantially. Neither a one-to-one mapping nor a fixed expansion factor is assumed.

This distinction also explains why a definition-level acquisition cache can coexist with view-level script guards and per-file import maps. They operate over different domains.

## Proposition: a sufficient reuse condition

Assume $J$ is deterministic and its result depends only on the definition version $d$, a context projection $\pi_J(\Gamma)$, and a dependency observation $z$. Define a cache key

$$
\kappa_J=(\operatorname{id}(d),\operatorname{version}(d),\pi_J(\Gamma),z).
$$

Equal keys imply equal interpretation results, provided key equality faithfully represents equality of those dependencies.

**Argument.** Every argument read by $J$ has the same value in the two uses. Determinism therefore gives the same contribution sequence. No statement is made about dimensions that the key omits unless their irrelevance has been established.

A smaller key is valid when an equivalent dependency projection is justified. A key based only on a GUID is insufficient for a result whose language prefix, target namespace, or view-specific name can differ.

## Equal values do not make repeated effects harmless

Memoizing a prepared fragment and applying that fragment twice are separate operations. If its update is concatenation, repeating the same fragment duplicates content. A per-scope contribution guard can be required even when retrieval returns the same value.

For an effect $f$, safe repeated application needs idempotence,

$$
f(f(M))=f(M),
$$

or a guard ensuring that the effect is applied only once in the intended occurrence/role scope. JCB's field/view script tracking is a concrete example of the second approach. [Acquisition](https://architecture.joomlacomponentbuilder.com/markdown/compiler/acquisition.md)

## A sufficient independence condition

Two deterministic operations $f$ and $g$ can be freely exchanged when their writes are disjoint and neither reads what the other writes, with no unmodeled external effects:

$$
W_f\cap W_g=\varnothing,\quad
W_f\cap R_g=\varnothing,\quad
W_g\cap R_f=\varnothing.
$$

Under these assumptions, applying either operation leaves the other's observed inputs unchanged, and their updates affect separate locations. Thus $f(g(M))=g(f(M))$.

Many compiler operations do not satisfy these conditions. Appending to the same ordered fragment or changing a language prefix before a consumer is intentionally order-sensitive. The prescribed execution order remains part of the architecture.

## Cross-artifact consistency is a relation

Let $a_1,\ldots,a_n$ be artifacts influenced by one occurrence. A consistency relation $\mathcal{I}$ can require their interpreted names, types, or policy references to agree:

$$
\mathcal{I}(d,o,a_1,\ldots,a_n).
$$

For Greeting, the form and metadata agree on logical name and field GUID where emitted; the SQL and metadata agree on `VARCHAR(255)` and ordinary-key status; the form and list refer to the intended language label; the association supplies title and sorting roles.

The form maximum of 50 and database width of 255 are not a violation because they are different properties. A correct invariant compares corresponding meanings, not every superficially similar number.

## Traceability connects the abstraction to output

A provenance relation records which occurrence produced a contribution and which consumer used it:

$$
\mathcal{P}\subseteq\mathcal{O}\times\mathcal{C}\times\mathcal{A}.
$$

The publication reconstructs selected paths through source references and marker traces. It does not assume that production JCB stores a complete provenance graph at runtime. The relation is useful for tests and explanations even when inferred from the orchestration.

The compiler's maintenance advantage follows from this coordination: shared interpretation and target rules update the artifacts related by $\mathcal{P}$ when the model is regenerated. The [implementation guide](https://architecture.joomlacomponentbuilder.com/markdown/engineering/implementation.md) shows how another language can preserve these boundaries using typed records and explicit operations.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/formal/staging.md

# Deferred execution and substitution semantics

Staging determines when information is consumed. It appears in deferred operations, contextual code retrieval, file binding, and late dependency injection. The common concern is readiness; the individual operations retain different semantics.

## Deferred operations retain their arguments

Represent deferred work by

$$
w=(f,a,r,p),
$$

where $f$ is the operation, $a$ its arguments, $r$ its required information, and $p$ its designated phase. The condition for execution is that the phase has been reached and the required observations have been established for that operation.

JCB's `secondRunAdmin` retains operations and argument arrays and replays them after the earlier admin/component work. Its control sequence supplies the prerequisite ordering. The mathematical $r$ makes that dependency explicit; it does not claim that production entries all contain machine-readable prerequisite sets.

## Phase ordering can establish readiness

Suppose every producer required by work $w$ completes in an earlier phase, its results are retained, and no intervening operation invalidates them. Then the designated replay phase can execute $w$ with those requirements available.

**Argument.** Every required producer precedes replay. Retention preserves its result through the intervening steps. The non-invalidation assumption ensures the result remains applicable. Their conjunction establishes the operation's readiness at replay.

This proposition explains the purpose of a phase boundary. It does not require a generic scheduler or a whole-program fixed-point loop. A second fieldset pass and a linked-view replay are selected operations at known completion points. [Deferred work](https://architecture.joomlacomponentbuilder.com/markdown/compiler/deferred-work.md)

## Ordered replacement within one pass

For an ordered map $P=\langle(k_1,v_1),\ldots,(k_n,v_n)\rangle$, define

$$
\sigma_1(s,P)=s_n,\qquad
s_0=s,\quad s_i=\operatorname{replaceAll}(s_{i-1},k_i,v_i).
$$

Each `replaceAll` replaces the occurrences in its input for that operation; it does not repeatedly process the newly inserted value against the same key until no match remains. Keys are nonempty in the model.

For the filtered action, first select entries using the original input:

$$
P_s=\langle(k_i,v_i)\in P\mid k_i\text{ occurs in }s\rangle,
\qquad \sigma_3(s,P)=\sigma_1(s,P_s).
$$

The selection happens once, before the ordered replacements. The presence-check action returns $s$ when no key occurs and otherwise applies the ordinary ordered map. [Binding](https://architecture.joomlacomponentbuilder.com/markdown/compiler/binding.md)

## An introduced token distinguishes the algorithms

Let $P=\langle(A,B),(B,x)\rangle$. Then

$$
\sigma_1(A,P)=x,\qquad \sigma_3(A,P)=B,
$$

because the filtered action removes the `B → x` entry when `B` is absent from the original input. For input `A B`, both entries survive filtering and the result is `x x`.

Reversing the entry order changes the ordinary result for input `A` to `B`. These examples establish that ordered replacement, original-input filtering, and simultaneous substitution are different semantics.

They also show why determinism does not require commutativity. Fix the map order and input, and the result is well-defined. Change the order, and a different result can be correct for that different input program.

## A finite pass does not imply small output

A pass with finitely many finite key/value pairs terminates on finite input under finite string-replacement operations. It can still expand its input substantially. Several stages can compound that expansion.

If $b_i$ is the byte length before replacement $i$ and $m_i$ the number of selected occurrences, then

$$
b_{i+1}=b_i+m_i(|v_i|-|k_i|).
$$

The occurrence count is evaluated on that replacement's actual input, which can include text introduced earlier in the pass. Costs therefore depend on intermediate as well as final sizes.

## Multiple passes have an explicit composition

For staged environments $P_0,\ldots,P_{n-1}$ and selected actions $a_i$,

$$
s_{i+1}=\sigma_{a_i}(s_i,P_i).
$$

Custom-code expansion, events, and Power injection can occur between passes and can expose new work. The operation that introduces a token must precede a suitable consumer if that token is intended to be resolved in the build.

A token introduced after its applicable consumer has already run will remain unless another designated operation handles it. The formal model identifies that ordering issue; it does not attribute a universal unresolved-token validator to the production placeholder service.

## Context has a lifetime

A prepared fragment can be retained before its destination is known. Retrieval applies the context at the later consumption point. A filename binding, module prefix, or view-specific method body has a scope and lifetime different from a globally reusable definition.

A phase-local environment can therefore be overwritten legitimately as the compiler moves to another artifact. Correctness depends on establishing it before use and avoiding unintended leakage into another context. An implementation using explicit context arguments can make the same boundary structural rather than relying on shared mutable configuration.

The [reference mechanisms](https://architecture.joomlacomponentbuilder.com/markdown/engineering/reference-model.md) test the exact replacement cases, deferred prerequisite handling, and ordered contribution behaviour. These small tests make the semantic distinctions executable without pretending to recreate the complete Joomla compiler.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/formal/transport.md

# Transport equivalence and bounded reconstruction

Export/import, regeneration, marked-code recovery, and extrusion cross different representation boundaries. Their useful laws must identify which information each transformation preserves. Raw database equality, equivalent application structure, and identical output bytes are different relations.

## The normalized portable design

Let $\beta(D)$ extract the blueprint-relevant design from local data: typed identities, selected properties, supported relationships, and asset identities/content under the export contract. Installation-local primary keys, unrelated records, and intentionally omitted configuration are outside that projection.

Define

$$
D_1\equiv_B D_2\quad\Longleftrightarrow\quad\beta(D_1)=\beta(D_2).
$$

Equality includes relationship roles and relevant ordering. An ordered field association cannot be replaced by an unordered set merely because it contains the same field GUIDs.

For local identity maps $\lambda_1$ and $\lambda_2$, a transported relationship commutes with realization when both endpoints resolve to the same portable entities:

$$
\operatorname{portable}(\lambda_i(u))=u.
$$

Local row numbers can differ while this relation is preserved.

## Proposition: design preservation through transport

Assume export serializes every selected property and required relationship in $\beta(D)$ without loss; required assets are retained; import uses the corresponding decoding and identity rules; and the selected existing-item policy accepts the transported state. Then the imported design $D'$ satisfies $D'\equiv_B D$.

**Argument.** Each selected entity property is recovered by the corresponding decode operation. Typed identities recover the same vertices. Relationship keys recover the same endpoints, roles, and ordered association values. The asset condition preserves the selected resource observations. Thus every component of $\beta(D')$ equals the corresponding component of $\beta(D)$.

Ordinary local-first initialization does not meet the acceptance premise when an intentionally retained local definition differs from the remote one. Explicit reset is one way to choose another policy. The law describes a correctly scoped transport, not an instruction to overwrite local work indiscriminately.

## Regeneration equivalence needs the generation environment

Suppose compilation's selected artifact observation depends only on $\beta(D)$ and an environment $E$ containing target rules, supplied libraries, templates, hooks, and other output-affecting observations. Then

$$
D_1\equiv_B D_2\land E_1=E_2
\quad\Longrightarrow\quad
\operatorname{obs}_A(\operatorname{compile}(D_1,E_1))
=\operatorname{obs}_A(\operatorname{compile}(D_2,E_2)).
$$

The argument is substitution of equal effective inputs into the deterministic operation sequence. If a hook reads an omitted local property, the premise that compilation depends only on $\beta(D)$ no longer holds for that observation.

Editor-region markers can include local IDs; output can include dates or archive metadata. Comparing runtime structure may normalize selected metadata, while a byte-equality comparison must fix or identically normalize every such value. The comparison must publish its normalization, not delete inconvenient differences after seeing the result.

## Marker-bounded recovery

Let $S$ be a finite set of region identities and $M:S\to\mathcal{B}$ a map of admitted bodies. An emitter places each body in a uniquely identified region; an extractor recovers those regions.

If identities occur exactly once, delimiters are unambiguous, admitted bodies cannot forge structural delimiters, and no intervening operation changes a body, then

$$
\operatorname{extract}(\operatorname{emit}(M))=M.
$$

**Argument.** Each identity determines one non-overlapping interval. Emission places the corresponding body in that interval, and extraction returns precisely that interval under the same identity. Equality follows pointwise over $S$.

Where generation applies a specialization $s$ and recovery applies a canonicalization $r$, the needed condition becomes $r(s(m))=m$ on the admitted body domain. That condition must be checked for the actual transformations. A string-replacement reversal is not automatically an inverse on arbitrary text with ambiguous names.

JCB's GUI and fingerprint mechanisms have their own identity and placement domains. The existing-file commented fallback preserves recoverable code when automatic executable placement cannot be established. It is a different observation from successful placement at the original semantic location. [Custom code](https://architecture.joomlacomponentbuilder.com/markdown/compiler/custom-code.md)

## Extrusion is evidence-based reconstruction

For artifact collection $A$, extrusion reads facts $H(A)$, resolves candidate model $Q$, and applies review decisions before writing. The result is a supported reconstruction, not necessarily the unique original model that produced the artifacts.

Non-uniqueness is concrete. The same ordinary database index can follow from an explicit index selection or from a title role. A SQL file alone cannot distinguish those origins. Table metadata, forms, associations retained elsewhere, and review decisions can supply additional information.

The reverse map is therefore naturally partial or set-valued before selection:

$$
\operatorname{candidates}(A)\subseteq\mathcal{D},
\qquad
\operatorname{extrude}(A,V)=\operatorname{select}(\operatorname{candidates}(A),V).
$$

The implemented resolver makes that selection through property precedence, identity/sharing rules, and pairing decisions. The chosen model can then enter normal compilation and become an explicit blueprint for future work.

## The common architectural result

These laws expose the useful invariants without collapsing distinct operations. Blueprint transport preserves a selected design representation. Compilation realizes it under target knowledge. Marked recovery preserves designated authored content under recognized transformations. Extrusion reconstructs represented structure from existing products.

Together they allow development intent to move between authoring, distribution, local editing, and deployable artifacts while retaining explicit identities and transformation rules. The [implementation guide](https://architecture.joomlacomponentbuilder.com/markdown/engineering/implementation.md) translates those boundaries into a portable engineering design.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/engineering/implementation.md

# Implementing the architecture in another technology

The architecture can be implemented without reproducing JCB's PHP classes or Joomla-specific emitters. Its reusable structure is the separation of design identity, contextual use, retained contributions, deferred operations, target knowledge, and materialized products.

A practical implementation begins with a small complete vertical slice. Define one entity and its associations, acquire it by stable identity, derive several coordinated outputs, export and import it, and demonstrate that the same represented intent reaches each output correctly. The Greeting example supplies a concrete template for that exercise. [Field trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/field-trace.md)

## Define the authoring model before the interface

Specify typed entity schemas, portable identifying fields, ordered associations, supported embedded references, assets, and custom-code roles. Then let a GUI, API, command-line tool, or repository file produce the same normalized representation.

The interface should express design choices rather than expose an unexplained collection of output filenames. A searchable field, for example, is a model decision whose query and interface consequences belong to generation rules.

Keep reusable definitions separate from their occurrences. The occurrence supplies role, placement, and context; it should not require copying and modifying a globally shared definition merely to change one use.

## Give resolution an explicit contract

A resolver needs a typed request, a local lookup policy, ordered configured sources, a payload mapper, persistence, dependency extraction, and request-state tracking. Initialization and reset should be different operations where local authoring is supported.

```text
acquire(request, mode, context):
    normalize request identity
    consult operation attempt state
    apply local-preservation policy for mode
    select source through the configured index contract
    retrieve and validate the represented payload
    map it into local design data
    record persistence outcome and discovered dependencies
    dispatch dependencies according to their relationship roles
    report unresolved requests and asset outcomes
```

Do not let the queue's emptiness stand in for graph validity. Attempted, resolved, and failed requests have distinct meanings. [Resolution](https://architecture.joomlacomponentbuilder.com/markdown/formal/resolution.md)

## Make contribution types explicit

An interpreter receives a definition and occurrence context and returns contributions. Each contribution specifies its destination, address, update operation, and value. Schema records, query aliases, ordered layout members, code fragments, requirement flags, and deferred tasks should retain their different types.

A typed map, record collection, or graph store can replace a PHP registry. The important property is that producers and consumers agree on the value's meaning and scope. A generic key/value service alone does not define that contract.

Represent names once they have been resolved within their scope. Downstream emitters should consume that decision rather than independently choose suffixes or aliases. This keeps forms, data paths, imports, and metadata aligned.

## Separate reusable preparation from contextual completion

A code dispenser can retain prepared fragments indexed by role and occurrence. Retrieval supplies the current binding environment and optional surrounding syntax. A definition cache can retain acquired source data while a per-view guard controls an effect such as script inclusion.

Those mechanisms must not share a key merely because both retain text. Define the dependency projection for each reusable result and the application scope for each effect. [Contribution model](https://architecture.joomlacomponentbuilder.com/markdown/formal/classification.md)

Deferred work can be a stored operation and arguments with a designated later phase. A dependency-task representation is another option, provided it preserves the same prerequisites and ordering. Do not introduce an unspecified repeat-until-stable loop where a finite sequence of selected completion stages is sufficient.

## Keep target knowledge behind responsibilities

Define logical emitter responsibilities such as schema, item model, list model, form, controller, module entry, plugin entry, manifest, and installation update. Select their concrete implementation through an explicit target context.

A Python implementation might return structured syntax trees or text fragments; a JVM implementation might transform models; another system might use typed intermediate code. The representation can differ while the responsibilities remain comparable.

Separate the host executing the generator from the platform targeted by its output. Establish target selection before resolving cached target-specific services.

## Materialize through an explicit stage plan

An artifact needs a destination, role, context, and ordered transformations. Skeleton creation, shared binding, use-site binding, custom expansion, dependency injection, validation, and packaging are distinct operations.

The selected substitution semantics must be specified. Reproducing JCB's ordered replacement requires preserving map order and the original-input filtering rule where used. Replacing it with simultaneous substitution is a deliberate semantic change, not an implementation-neutral optimization. [Staging](https://architecture.joomlacomponentbuilder.com/markdown/formal/staging.md)

Track artifacts and diagnostics separately. A completed optional publication step, a generated source file, a recoverable code-placement warning, and a successfully created archive answer different questions.

## Add transport and reconstruction at their actual boundaries

Blueprint export projects portable design information and serializes its dependency graph. Import restores that graph under explicit existing-item policies. Installed-artifact extrusion uses readers, precedence, identity resolution, reviewable candidates, and ordered writers. Marked-code recovery uses designated region identities and placement context.

These operations can share identity services and representations without being called the same inverse transformation. Preserve the domain and equivalence appropriate to each. [Transport](https://architecture.joomlacomponentbuilder.com/markdown/formal/transport.md)

## Test a complete represented decision

For the first vertical slice, test that a field's resolved name appears consistently in schema, form, query, and metadata; that its context changes only the intended outputs; that export/import preserves its portable identity; and that a missing dependency produces a specific diagnostic.

Then add shared definitions, cyclic dependency references, deferred operations, custom-code binding, alternate targets, and explicit recovery cases. The [reference mechanisms](https://architecture.joomlacomponentbuilder.com/markdown/engineering/reference-model.md) demonstrate several of those contracts at small scale.

The purpose is to reproduce the architectural relationships, not to start by recreating JCB's complete feature catalogue. A small correct implementation of the full lifecycle gives subsequent emitters and entity types a stable foundation.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/engineering/reference-model.md

# Executable reference mechanisms

The publication includes a small executable companion to the mathematics. It isolates mechanisms that can be tested without installing Joomla: typed request identity, local-first dependency traversal, property precedence, contextual field contributions, deferred prerequisites, ordered placeholder replacement, and normalized transport observations.

The implementation lives in `reference/architecture.py`. The demonstration lives in `examples/demo.py`, and the tests live in `tests/test_architecture.py`. Python is used as an executable notation for the companion; the white paper's definitions do not depend on Python.

## Run the companion

From the repository root:

```bash
python -m unittest discover -s tests -v
python examples/demo.py
```

The demonstration prints structured results so that the selected identities, outputs, and stage decisions can be inspected. It performs no network access, executes no imported application code, and requires no credentials.

## Resolution examples

A request includes entity type, identifying field, and value. The example resolver preserves a local record under initialization, otherwise searches an ordered repository collection, records attempt and outcome state, and follows represented dependencies.

Tests cover a shared dependency, a cycle, a missing request, local-first behavior, and a selected repository entry whose payload is invalid. The last case verifies that index selection and payload fallback are separate policies.

The purpose is to make the [termination argument](https://architecture.joomlacomponentbuilder.com/markdown/formal/resolution.md) concrete. Visiting a request once bounds repeated acquisition; it does not convert a failed request into a resolved definition.

## Classification examples

A small field model distinguishes reusable database/form properties from occurrence roles such as title, search, and sorting. Its interpretation produces schema, form, language, and list-related observations.

The Greeting case retains database width 255 and form maximum 50 and derives an ordinary index from the title role despite an explicit-index value of zero. The executable result mirrors the branch explained in the [field trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/field-trace.md), not every possible JCB field type.

Additional tests change the occurrence context to check that context-qualified names and roles change at the intended boundary while the portable field identity remains stable.

## Ordered binding examples

The replacement function implements ordinary ordered replacement, the presence-check action, and original-input map filtering. Tests exercise introduced tokens, reversed map order, unknown tokens, and a replacement that contains its own key.

For the map `A → B`, `B → x`, ordinary replacement of `A` gives `x`, while original-input filtering gives `B`. This small distinction is important enough to test directly because a superficially similar substitution algorithm would produce different generated text. [Formal staging](https://architecture.joomlacomponentbuilder.com/markdown/formal/staging.md)

## Deferred work and property precedence

The companion represents deferred work with named prerequisites and a retained operation. It rejects execution before those prerequisites are available and records the result after they are supplied. This exposes the readiness relation that JCB's selected phase boundaries establish operationally.

The precedence helper selects usable property values by configured tier rank and a stable default tie-break. Zero and false are retained as meaningful values; only the declared missing-value cases are excluded. Tests distinguish configured rank from the order in which candidates happen to be iterated. [Extrusion analysis](https://architecture.joomlacomponentbuilder.com/markdown/extrusion/analysis.md)

## Representation observations

Transport tests compare a declared portable projection while allowing local record IDs to differ. They also ensure that ordered associations remain ordered and that differing represented design values are not discarded by normalization.

The companion's normalization is deliberately small and explicit. It must not be mistaken for a complete implementation of every JCB entity's export mapper. Its role is to test the mathematical distinction between design equivalence and raw record equality. [Formal transport](https://architecture.joomlacomponentbuilder.com/markdown/formal/transport.md)

## What these tests establish

The tests establish behavior of the companion code and the worked mechanisms it implements. Source references separately establish JCB's corresponding responsibilities. Repository inventories establish the observed public artifacts. A full Joomla build exercises another, larger boundary.

Keeping those boundaries distinct makes the companion useful rather than inflated: another engineer can run and modify a small model, inspect the actual compiler paths, and decide how to represent the same mechanism in a different technology.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/engineering/performance.md

# Build measurements and cost structure

In repeated JCB self-builds, an exported blueprint of approximately **30,000 lines** has produced an application of **more than one million lines** in approximately **60–64 seconds** on the demonstrated setup. These are measurements from the maintainer's repeated builds and demonstrations. The architecture uses compiler rules, templates, reusable Power classes, and other supplied material in addition to the project blueprint.

The measurement describes compilation and assembly of the application. It does not imply that every reusable class body is newly authored during that interval. Reuse and coordinated placement are part of the work being measured.

## The timing boundary includes preparation

The inspected compiler starts its timer before initialization and inherited content preparation. The successful path stops it after final file processing, language and metadata work, repository-output handling, archives, and completion notices. The timer therefore does not measure only the last placeholder pass. [C01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c01)

The exact environment, enabled options, dependency state, and output size determine an individual run. The maintained approximate measurement is not assigned retrospectively to every revision or every machine. A reproducible run record fixes those values alongside the input blueprint and output inventory.

The [edition record](https://architecture.joomlacomponentbuilder.com/markdown/reference/edition.md) identifies the maintainer's measurement as an engineering record and the source-derived timer boundary as a separate observation.

## Output size and blueprint size answer different questions

The pinned official source snapshot contains 1,014,391 physical UTF-8 text lines under the inventory rule used for this edition. Of those, 484,477 are outside its top-level `libraries` directory. This inventory describes the repository snapshot, not the exact timed build's counter or a claim about manually typed source.

The application layers outside the library collection are generated through JCB's blueprint-driven process. The library collection includes supplied reusable implementation, including much of the compiler's own service code. JCB's self-build coordinates those inputs into the delivered application. [Regeneration and self-build](https://architecture.joomlacomponentbuilder.com/markdown/engineering/regeneration.md)

Hello World's smaller example separately contains 1,298 physical payload JSON lines and 32,988 physical text lines across its three product repositories. Its indexes, descriptions, assets, and supplied libraries are counted explicitly. [Accounting](https://architecture.joomlacomponentbuilder.com/markdown/examples/accounting.md)

Neither ratio is a standalone measure of correctness or labor. The ratios describe how much implementation is materialized from compact represented intent and reusable generation knowledge.

## A useful cost decomposition

For an invocation, write

$$
T_{\mathrm{build}}=T_{\mathrm{acquire}}+T_{\mathrm{normalize}}
+T_{\mathrm{interpret}}+T_{\mathrm{defer}}+T_{\mathrm{bind}}
+T_{\mathrm{write}}+T_{\mathrm{package}}+T_{\mathrm{effects}}.
$$

Acquisition includes database and configured repository work. Interpretation processes contextual occurrences and their contributions. Deferred completion handles selected later operations. Binding depends on replacement-map order, content size, and introduced text. Writing and packaging depend on the artifact volume and filesystem/archive operations. Effects include the active hooks and selected integrations.

The terms can overlap in implementation timing; the decomposition names responsibilities for measurement rather than asserting that each has already been separately profiled.

## Reuse reduces particular repeated costs

A cached definition can avoid repeated database acquisition. A cached repository index can serve many identity requests. A per-view contribution guard can avoid duplicate scripts. Retained schema or alias information can feed several emitters without being rediscovered independently.

If $n$ uses share a base acquisition of cost $a$ and each requires contextual interpretation cost $j_i$, acquisition reuse changes the corresponding idealized cost from

$$
\sum_{i=1}^{n}(a+j_i)
\quad\text{to}\quad
 a+\sum_{i=1}^{n}j_i,
$$

apart from lookup and retention overhead. It does not remove the distinct contextual work represented by $j_i$.

The actual benefit depends on the workload. Retaining a value that is cheap to recompute but very large can cost more memory than it saves time. The architecture makes that tradeoff visible through distinct store lifetimes.

## Binding and output impose their own bounds

Ordered replacement can scan intermediate strings several times. A map with $m$ relevant entries over content of size $b$ can involve work proportional to repeated scans, with intermediate expansion affecting the actual cost. Original-input filtering changes which entries are processed but also has its own presence-check cost.

Materializing $B$ output bytes requires at least $\Omega(B)$ byte-transfer work in a model that charges for written bytes. No cache removes the cost of actually producing the requested artifact set. Archive compression, copied assets, and filesystem behavior can dominate particular builds.

Peak memory includes acquired definitions, contextual contributions, pending work, active content, and temporary copies. Measuring it requires the host process and actual build options, not only the blueprint size.

## A reproducible measurement record

A concrete record should identify the blueprint revision, compiler revision, target, templates and reusable dependencies, host versions and resource limits, enabled hooks/integrations, local-versus-remote acquisition state, elapsed-time boundary, peak memory, and output selection rule. Repeated runs should retain their individual observations rather than only the fastest one.

Cold and warm dependency conditions are different workloads. A build that imports missing definitions from repositories should not be compared silently with one whose complete graph is already local. Correctness-equivalent output is required when comparing alternative implementations.

This procedure extends the maintained build record; it does not recast those existing measurements as a hypothetical future capability.

## The architectural performance result

JCB's approach spends work on interpreting structured intent and reusing established implementation knowledge, then writes the complete native products. Its resource requirements follow those conventional acquisition, transformation, and output operations. The useful engineering question is which repeated work is eliminated, which contextual work remains necessary, and how the retained state affects time and memory.

That account is more actionable than an unqualified “fast generator” label. It tells an implementer where to measure, what can be reused safely, and which costs follow from the requested output itself.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/engineering/regeneration.md

# Self-generation and maintenance propagation

JCB builds its own application through the same blueprint-driven development approach it supplies to other projects. The generated application layers outside the library collection include the authoring interface and the Joomla integration needed to manage definitions and invoke the compiler. Reusable library and Power inputs supply substantial implementation, including the compiler's own specialized services.

This is a concrete use of the architecture on its own development tool. Its model describes the application that manages models; its generated interface supports further work on those definitions. [C01](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#c01), [E07](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#e07)

## Separate the generator's application from its supplied libraries

Let $B_J$ be JCB's application blueprint, $L_J$ its supplied libraries/Powers, and $\Theta_T$ its target generation rules. The self-build can be represented as

$$
A_J=\operatorname{compile}(B_J,L_J,\Theta_T,C,H).
$$

The output $A_J$ is the delivered JCB application with its generated layers and included dependencies. The equation does not say that $L_J$ is invented during compilation. Its manually developed and reviewed implementation is an input whose inclusion and placement the build coordinates.

The distinction also explains the repository structure. Generated application code and reusable library source are both present in the delivered project, but their immediate origins differ. A repository line count alone cannot assign authorship effort to either category.

## Self-generation exercises the architecture's actual workload

JCB's own model contains the relationships, editors, fields, permissions, custom code, and integrations required by a development platform. Regenerating that application exercises a broader model than a minimal example while keeping the same underlying acquisition, classification, binding, and packaging responsibilities.

The significance is operational: the architecture is used to maintain the application that exposes it. Its recurring self-build connects changes in stored design and reusable implementation to a concrete runnable product.

The maintained performance record describes repeated self-builds of this kind. [Build measurements](https://architecture.joomlacomponentbuilder.com/markdown/engineering/performance.md)

## Shared rules carry maintenance knowledge

A generated application's blueprint expresses choices such as a field's storage, a view's model, a permission option, or a target-platform reference. The compiler supplies recurring implementation around those choices.

When a shared generation rule is corrected, each model that uses that rule can receive the correction through regeneration. The work is performed at the generation-knowledge boundary rather than manually repeated in every affected application file.

Let $\Theta$ and $\Theta'$ differ in one rule family. For application models $B_1,\ldots,B_n$, the propagated products are

$$
A_i'=\operatorname{compile}(B_i,L_i,\Theta',T_i,C_i,H_i).
$$

Only applications whose selected paths consume the changed rule need exhibit a corresponding output change. The relation is determined by their definitions and occurrence choices, not by a claim that every update changes every file.

## Target adaptation preserves represented intent

JCB's target-specific emitters and Joomla Power mappings separate application intent from selected platform conventions. A platform change can be incorporated into those shared rules while the application retains its field and view definitions.

The compiler then emits the updated controller/model/view, service-provider, import, routing, or installation conventions under the chosen target. [Target selection](https://architecture.joomlacomponentbuilder.com/markdown/compiler/targets.md)

This maintenance path is strongest where the design uses represented compiler abstractions. Arbitrary embedded target-specific code and deliberate whole-class replacements retain their own authorship and maintenance boundaries. Regeneration does not infer an unstated business-rule migration from unrelated source code.

## Editable regions and overrides have different ownership

A designated code region can be recovered and placed into the next generated structure. A full source-class override supplies a complete class and intentionally replaces the default emitter's ownership of that class. A reusable Power supplies a managed definition that can be updated independently.

Those choices allow different balances of automation and control. The paper describes them separately because their maintenance consequences differ: a recovered method fragment receives a regenerated surrounding class; a complete override retains the author's surrounding implementation as well.

## Distribution multiplies reuse across projects

Blueprint repositories distribute application design. Power and field-type repositories distribute reusable definitions. Repository-target definitions make those sources discoverable. Local-first acquisition preserves editable working copies while explicit reset/publication operations control updates.

The compiler combines those layers when generating an application. A reusable definition can therefore influence several projects through their declared dependencies, and a compiler rule can influence several output artifacts within each project.

The multiplier is the repeated application of shared knowledge under explicit context. It can be described without hypothetical saved-hour formulas: identify the changed input, identify its consumers, regenerate, and inspect the resulting products.

## A basis for studying the next implementation

The architectural account makes those relationships visible enough to evaluate. It identifies what must retain identity, what can be reused, which work must wait, and which outputs share a decision. That understanding can guide later improvements to JCB or another implementation.

This edition first documents the current mechanism. Future changes can then be compared against a clear behavioral model rather than against an impression formed from the size of the original classes or the number of generated files.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/engineering/verification.md

# Verification and traceability

A useful architectural publication lets a reader move from a claim to the evidence appropriate to it. This edition combines implementation paths, public blueprint/product traces, mathematical arguments, executable reference mechanisms, and maintained build measurements.

These forms of evidence reinforce each other while answering different questions. A repository trace shows a generated artifact. A source path explains the operation that can produce it. A mechanism test checks a defined behavior. A runtime build exercises the full environment. A proof derives a conclusion under explicit assumptions.

## Source correspondence

The [source map](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md) groups paths by responsibility and identifies the pinned core revision. The integrated extrusion scope is recorded separately so that a source link is never asked to support code absent from its revision.

A review follows the actual entry and calls through their collaborators, including constructor work, mutable state, events, deferred processing, and later file updates. Class names alone are not proof of ordering or guarantees. The prose uses inspected operations and distinguishes structural correspondence from a complete formal verification of every path.

## Public artifact traces

The Hello World trace connects typed source identities and code-property roles to generated artifacts. It checks the field GUID, database/form properties, derived index, language key, list behavior, marker destinations, module context, and plugin naming.

The inventory script operates on local pinned checkouts and records file counts, line counts, bytes, hashes, and selected marker matches. It does not execute imported code. The resulting manifest can be compared across source snapshots under the same selection rule.

Identical marker text in multiple properties is retained as a many-origin case rather than falsely assigned a unique provenance. Field identity and role provide stronger evidence than an unqualified substring match. [Custom-code trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/custom-code-trace.md)

## Executable mathematical mechanisms

The reference tests check typed requests, local-first policy, cyclic traversal, failed selection, property precedence, contextual contributions, deferred prerequisites, exact ordered substitution, and normalized design observations.

Those tests provide executable examples of the formal definitions. They do not replace Joomla integration tests. Keeping the model small permits exhaustive checks over selected small cases and makes a semantic change visible when an alternative implementation is tried.

The [formal chapters](https://architecture.joomlacomponentbuilder.com/markdown/formal/notation.md) state assumptions explicitly. A termination argument requires a finite reachable request universe and terminating handlers. A reuse argument requires a key covering the relevant inputs. A transport law requires the selected design to be retained and accepted by the import policy.

## Full build reproduction

A complete reproduction records the compiler and blueprint revisions, local initialization/reset policy, repository and dependency versions, target, environment, hooks, and assets. It then imports or restores the selected model, runs compilation, retains diagnostics and timing, and compares the generated products under a declared observation.

For a fresh-instance transport test, local database primary keys can differ. The portable graph should be compared independently of those IDs. For byte comparison, local GUI markers, dates, archives, and other output-affecting values must be controlled or normalized by a rule stated before comparison. [Transport](https://architecture.joomlacomponentbuilder.com/markdown/formal/transport.md)

The measured self-build record is an engineering observation from repeated use. A new reproduction adds a precisely packaged instance of that observation; it does not determine whether prior builds occurred.

## Review the interactions, not only isolated functions

Important checks cross concern boundaries: form and schema names, save/read storage transformations, permission-driven omission and persistence, query aliases and templates, language keys and catalogue entries, Power symbols and imports, deferred prerequisites and consuming phases.

A successful string replacement does not by itself establish those relationships. Tests should inspect the interpreted result or generated artifact relation that the operation is supposed to preserve.

Similarly, a completed extrusion can include skipped candidates and unresolved details. The report and selected writes must be reviewed together. The source's explicit recovery behavior should be tested as behavior rather than treated as an unspecified error.

## Publication validation

The website build checks article metadata, one primary heading per page, internal paths and anchors, canonical addresses, exact Markdown alternates, article hashes, complete downloads, and machine-readable indexes. Browser checks cover navigation, search, system-following/manual themes, mathematical rendering, diagrams, and narrow-screen layout.

These checks establish the integrity of the publication, not the runtime correctness of all JCB extensions. Their purpose is to ensure that the explanation, mathematics, and supporting evidence are actually accessible to readers.

## A stable basis for further work

The publication provides an explicit account against which future changes can be examined. A proposed optimization can identify the observation it preserves. A new entity type can state its identity and dependency contract. A new backend can demonstrate the same contextual contributions in another syntax.

That is the practical value of verification here: it turns architectural understanding into concrete questions and repeatable checks, while leaving each conclusion attached to the evidence that supports it.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md

# Implementation and evidence source map

The core implementation references use the official **Joomla Component Builder** repository at commit **`bca4a1520484f3e2c2fbd12964a5995b0d058de1`**. Paths below beginning `Compiler/`, `Package/`, or `Remote/` are relative to `libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/`, unless stated otherwise. Each entry identifies the responsibility examined, not an assertion that every method in that directory implements the same guarantee.

The integrated extrusion capture is recorded separately under X01–X04. It contains implemented operations included in this architectural edition but is not attributed to the older core pin. The [edition record](https://architecture.joomlacomponentbuilder.com/markdown/reference/edition.md) explains this boundary. All public compiler links use the official project.

## C01

**Entry, timing, initialization, and final orchestration.** [Compiler.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler.php) contains the constructor, `run()`, final custom-code placement, repository output, and archive sequence. [Initializer.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Initializer.php) establishes the once-only initialization sequence, code recovery before reset, component loading, version handling, and structures. Include inherited Infusion work when tracing the constructor.

## C02

**Shared services, configuration, and extension boundaries.** [Compiler/Factory.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Factory.php), `Compiler/Config.php`, and the [compiler service providers](https://github.com/joomengine/Joomla-Component-Builder/tree/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Service) connect shared stores and selected collaborators. Event interfaces and calls in the consuming paths establish where handlers can affect state. Service lifetime and construction are part of execution.

## C03

**Component acquisition and nested enrichment.** [Component/Data.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Component/Data.php), `Compiler/Component.php`, and `Compiler/Model/Adminviews.php` load the root, establish its registry, enrich configuration and code, and follow view occurrences into their referenced data. Examine the query and `energize()` sequence, not only the final returned object.

## C04

**Field definitions, names, and contextual code.** [Field/Data.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Field/Data.php) implements ID/GUID indexing, local acquisition, guarded remote retry, field-type enrichment, and use-site custom-code processing. The [Field services](https://github.com/joomengine/Joomla-Component-Builder/tree/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Field), including `Name`, `UniqueName`, `TypeName`, and `Customcode`, supply naming scope and per-view contribution guards. Cached data can be processed and mutated; it is not represented as a universally pure GUID lookup.

## C05

**Semantic classification.** [Creator/Builders.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Creator/Builders.php) is the central field-contribution trace: schema and keys, list membership, relations, titles and aliases, storage treatment, search, sorting, filters, layouts, languages, and component-field metadata. Inspect the branch conditions and update operations of each contribution. The Greeting title-to-index rule is in the schema-building branch.

## C06

**Store operations and output environments.** [Abstraction/Registry.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Abstraction/Registry.php) supplies shared registry operations. [ContentOne.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Builder/ContentOne.php) models shared placeholder keys; [ContentMulti.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Builder/ContentMulti.php) partitions bindings by context. Specialised builders retain their own value and update meanings.

## C07

**Content preparation and deferred completion.** [Helper/Infusion.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Helper/Infusion.php) prepares content, interprets views, replays `secondRunAdmin` operations and argument arrays, and invokes the second configuration-fieldset pass. `Compiler/Creator/ConfigFieldsets.php` implements the selected fieldset work. The source has a prescribed replay point, not a generic least-fixed-point scheduler.

## C08

**Exact binding semantics.** [Placeholder.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Placeholder.php) defines ordinary ordered replacement, presence checking, original-input map filtering, active-placeholder updating, and marker construction. Action 3 filters map entries; it does not remove every unknown output token. The host replacement primitive is documented in [R12](https://architecture.joomlacomponentbuilder.com/markdown/reference/bibliography.md#r12).

## C09

**Custom, GUI, external, and recovered code.** [Customcode.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Customcode.php) coordinates expansion and discovery. The [Customcode services](https://github.com/joomengine/Joomla-Component-Builder/tree/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Customcode) include `Dispenser`, `Gui`, `Extractor`, `External`, and `Reverse`. They establish preparation/retrieval, local editing addresses, static extraction, content-history acceptance, and supported reversal. Final fingerprint placement and `loadEscapedCode()` are in C01's compiler. A missing file and an unresolved location in an existing file have different diagnostic paths.

## C10

**Power acquisition, dependency processing, and injection.** [Power.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Power.php) and the [Power collaborators](https://github.com/joomengine/Joomla-Component-Builder/tree/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Power) handle GUID acquisition, recursive preparation, source placement, import aliases, and per-file injection. [JoomlaPower.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/JoomlaPower.php) selects target-sensitive platform mappings. Distinguish a processing guard from completed preparation and a definition's qualified name from a file-local alias.

## C11

**Nested template and layout acquisition.** [Templatelayout/Data.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Templatelayout/Data.php) recognizes supported literal load/render forms, resolves aliases, stores templates/layouts under their respective scopes, and follows nested content. Its recognized syntax defines the discovered dependency relation.

## C12

**Dynamic Get and alias/result structure.** [Dynamicget/Selection.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Dynamicget/Selection.php), `Compiler/Dynamicget/Data.php`, and `Compiler/Model/Dynamicget.php` prepare sources, selections, aliases, joins, filters, and method-specific mappings. Query execution remains a runtime operation in the generated application.

## C13

**History and update contributions.** [Model/Updatesql.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Model/Updatesql.php), `Historycomponent.php`, `Historyadminview.php`, and `Sql.php` in the same model directory process supported old/new relationships and properties. They contribute migration information; compiling that information is not the later execution of an installation migration.

## C14

**Permission declarations and consumers.** [Creator/Permission.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Creator/Permission.php) prepares action mappings. [Helper/Interpretation.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Helper/Interpretation.php) contains the generated form treatment, field options, strict result processing, and permission-sensitive JSON save path. Inspect the respective branches around lines 4,030, 15,436–15,700, and 16,808 onward. Their conditions differ; a hidden input is not equivalent to removing data from every runtime result.

## C15

**Language collection and output.** [Language.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Language.php) and [Language services](https://github.com/joomengine/Joomla-Component-Builder/tree/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Language) implement keyed collection, extraction, source/translation maintenance, association updates, inclusion thresholds, and messages. `Set`, `Update`, `Translation`, `Insert`, `Purge`, and `Multilingual` have separate responsibilities.

## C16

**Router modeling and emission.** [Model/Router.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Model/Router.php) prepares view/key/alias data. [Creator/Router.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Creator/Router.php) selects default, configured, or authored work; `RouterConstructorDefault`, `RouterMethodsDefault`, and their manual counterparts implement those selected paths.

## C17

**Module content.** [Joomlamodule/JoomlaSix/Infusion.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Joomlamodule/JoomlaSix/Infusion.php) establishes module context and prepares provider, dispatcher, Dynamic Get, helper, default template, installer, fieldset, and manifest content. Data and structure services and the architecture provider supply the corresponding acquisition and target responsibilities.

## C18

**Plugin content.** [Joomlaplugin/JoomlaSix/Infusion.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Joomlaplugin/JoomlaSix/Infusion.php) establishes plugin naming and language context and prepares extension, provider, installer, fieldset, and manifest material. Plugin group, base-class, method, and property definitions participate through their data paths.

## C19

**File inventory and ordered updating.** [Extension/Files/Updater.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Extension/Files/Updater.php), `Extension/Files/Dynamic.php`, and [Extension/FileContent.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Extension/FileContent.php) establish file-family order, context selection, shared-before-context binding, later code processing, injection, writing, and autoloader completion.

## C20

**Packaging and configured publication.** C01's `Compiler.php` contains the final language/update/README/repository operations and component, module, and plugin archive paths. Structure and utility collaborators manage the associated file trees. These are operation-specific outcomes, not an asserted distributed transaction.

## C21

**Target dispatch.** [Service/ArchitectureModule.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Service/ArchitectureModule.php) provides a concrete target-selection example. The same directory contains `ArchitectureController`, `ArchitectureView`, `ArchitectureComponent`, `ArchitecturePlugin`, `ArchitectureDashboard`, and `ArchitectureModel`. Inspect target configuration before service resolution and the lifetime of cached selection.

## C22

**Generated design metadata.** C05's `Creator/Builders.php` assembles the component-field map. The [Hello World Table class](https://github.com/vast-development-method/hello-world-joomla-component/blob/a81c0dd8b8f41905671a86796a3e5995685fdaba/libraries/jcb_powers/JCB.Joomla/src/Helloworld/Table.php#L73-L96) shows the emitted Greeting GUID, type, roles, tab, and database properties.

## C23

**Historical implementation.** [Root commit](https://github.com/joomengine/Joomla-Component-Builder/commit/ecf47809f960bd057af8a414168fada6fe22c5f7), 30 January 2016 at 20:28:43 UTC, and its [admin/helpers/compiler.php](https://github.com/joomengine/Joomla-Component-Builder/blob/ecf47809f960bd057af8a414168fada6fe22c5f7/admin/helpers/compiler.php). The early source already contains specialised builders, static/dynamic content stores, acquisition, structure construction, and later file updates. Later features and this manuscript are not backdated to that commit.

## C24

**API and AJAX generation.** The [Joomla 4 compiler templates](https://github.com/joomengine/Joomla-Component-Builder/tree/bca4a1520484f3e2c2fbd12964a5995b0d058de1/admin/compiler/joomla_4) include API controller and JSON-view material. C07's Infusion establishes the API bindings; [Model/Ajaxadmin.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Compiler/Model/Ajaxadmin.php) prepares selected AJAX input and method contributions, flags, and tokens. Entry registration and runtime authorization must be read in their respective generated integration paths.

## B01

**Entity catalogue and transport schema.** [Componentbuilder/Factory.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Factory.php) records the canonical entity map. [Package entity configurations](https://github.com/joomengine/Joomla-Component-Builder/tree/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Package) declare identifying fields, child relationships, indexes, payload paths, projection/encoding, and ignored local properties. `Package/Field/Remote/Config.php` and `Package/AdminView/Remote/Config.php` are representative cases. Distribution-channel flags are not interchangeable with every handler's retrieval eligibility.

## B02

**Graph acquisition and publication dispatch.** [Package/Builder/Get.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Package/Builder/Get.php) and [Set.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Package/Builder/Set.php) select handlers, drain entity batches, distinguish reset policy, process files/folders, and aggregate results. Empty queues and successful persistence remain different observations.

## B03

**Dependency extraction and tracking.** [Package/Dependency/Resolver.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Package/Dependency/Resolver.php), `Package/Dependency/Tracker.php`, and `Remote/SetDependenciesTrait.php` handle outgoing references, incoming children, recognized dynamic content, nested fields/rules, and asset queues. Edge direction affects subsequent operation policy.

## B04

**Repository selection.** [Abstraction/Grep.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Abstraction/Grep.php), `Componentbuilder/Remote/Grep.php`, and `Componentbuilder/Package/Grep.php` establish configured-source traversal, index caching, item matching, and payload location. Trace selection and fetching separately when determining fallback behavior.

## B05

**Portable export and remote updates.** [Abstraction/Remote/Set.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Abstraction/Remote/Set.php) and [Componentbuilder/Remote/Set.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Remote/Set.php) prepare payloads, dependencies, item descriptions, index updates, and eligible per-repository writes. Their normalization and unchanged-content checks differ from raw database-row comparison.

## B06

**Remote initialization and local persistence.** [Componentbuilder/Remote/Get.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Remote/Get.php) coordinates local-preservation and retrieval behavior. [Data/Item.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Data/Item.php) supplies table-aware item persistence. Examine the return values of individual operations before assigning a stronger meaning to aggregate result buckets.

## B07

**File and folder transport.** [Package/Remote services](https://github.com/joomengine/Joomla-Component-Builder/tree/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Package/Remote) include `GetContent`, `GetFile`, `GetFolder`, `SetContent`, `SetFile`, and `SetFolder`. They normalize resource identities, locate repository content, interpret target destinations, and retain the distinction between ordinary and forced acquisition.

## B08

**Repository definitions.** [Repository/Remote/Config.php](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/libraries/vendor_jcb/VDM.Joomla/src/Componentbuilder/Repository/Remote/Config.php), the repository services, and E06's repository-index snapshot describe managed source configuration. Read/write branches and channels are inputs to discovery and publication, not properties inferred from an entity's short name.

## X01

**Integrated component extrusion.** The captured implementation under `Componentbuilder/Extrusion/` includes `Extruder.php`, `Config.php`, discovery/layout adapters, typed registries, resolvers, and writers. `harvest`, `candidates`, and the writing operation separate observation, pairing, and persistence. The capture is identified by file SHA-256, independently of any moving branch:

| File | SHA-256 |
| --- | --- |
| `Extruder.php` | `9f7bc95ba0d3912b40cbb0f14a689371523c46c26dc1c14e5a8513277521e1c6` |
| `Config.php` | `7aef639bbb031d7f8e487b0b78acbfa59169c806472462657c6c7bba38246476` |

These are implemented edition-scoped operations, not paths asserted to exist at the older core compiler pin. Release availability is determined by the [official project](https://github.com/joomengine/Joomla-Component-Builder).

## X02

**Static readers and property precedence.** Under the same capture, reader services examine schema, form, language, manifest, table metadata, and view artifacts. `Resolver/Precedence.php` selects each usable property's value and origin by configured rank and stable default tier order. Its SHA-256 is `81665ea7c80df6506ad5fe1699c9e1348bdb4c35f293c748455326d2d752ac6b`. Zero and false are admitted values; null and empty string are omitted. The reader grammars define recovery coverage.

## X03

**Class recovery and reusable Power assembly.** Capture paths and SHA-256 values:

| File | SHA-256 |
| --- | --- |
| `Powers/Extruder.php` | `3d572f1ffb82b1ed7badab938ef5cffa1a2333ab7d855c2ad1ce030f3aa3c44c` |
| `Powers/Reader/ClassFile.php` | `4a59011afdbae2d29b95341e10716170f65099cc360b9d7c7c9eee73552e2635` |
| `Powers/Resolver/Namespacer.php` | `4e78fe939ebdeb66fd4a9e66b5d168446325275abf65d20b6682ce9238771e06` |
| `Powers/Assembler.php` | `bffa8682f55257f03b41e0caac15ad152c6a269350ad35ebcdf4acc2e64aa879` |

The trace covers declaration location, body extraction, namespace/path interpretation, supported placeholder/language reversal, relationship assembly, and selected writes. Lexical recognition is distinguished from the declaration forms fully represented by the destination model.

## X04

**Pairing and write order.** `Resolver/Pairing.php` (SHA-256 `0dc7f59d0c1d85b4840ec07e116498ad2a7ac528e0c30565e8049605e8610e3d`), `Resolver/Candidates.php`, `Resolver/Sharing.php`, `Resolver/Reuse.php`, and `Writer/Dispatcher.php` (SHA-256 `d0de812634c16ad2a14805f5148a43806cbb5fae339214cc50bba5b39258cd84`) retain explicit verdicts, identity selection, shared-field decisions, and the dependency-compatible writer sequence. Each write and diagnostic has its own outcome.

## E01

**Hello World blueprint.** [Snapshot](https://github.com/vast-development-method/hello-world-blueprint/tree/5802e7c1d9bfaac005c765ccda830a7d07cd7e12). Entity payloads under `src/`, child records, `@dependencies`, indexes, README descriptions, and assets support the [worked lifecycle](https://architecture.joomlacomponentbuilder.com/markdown/examples/hello-world.md). The accompanying [accounting](https://architecture.joomlacomponentbuilder.com/markdown/examples/accounting.md) publishes separate categories.

## E02

**Hello World component product.** [Snapshot](https://github.com/vast-development-method/hello-world-joomla-component/tree/a81c0dd8b8f41905671a86796a3e5995685fdaba). Forms, SQL, list/view/model code, language entries, Table metadata, installer, and GUI-code markers support the field and custom-code traces.

## E03

**Site Redirect module product.** [Snapshot](https://github.com/vast-development-method/hello-world-joomla-module/tree/20be318a6163e253c2a9803434622467d6006709). Dispatcher, provider, template, manifest, language, and installer material demonstrate a distinct extension context.

## E04

**Hello World Privacy plugin product.** [Snapshot](https://github.com/vast-development-method/hello-world-joomla-plugin/tree/6a785145ee84212fec65a53b7c6c362ab0f8b408). The plugin class and manifest show the component-sensitive name resolved from its reusable definition.

## E05

**Service Directory family.** [Blueprint collection](https://github.com/joomengine/joomla-packages/tree/5e8733cb82c4467cf5e0a39c05a0133b457fec80) and [generated application](https://github.com/joomengine/Joomla-Service-Directory/tree/0ac9788cb9239ed2801ba19c7e2393c70e03f9c4). The two root versions and the product snapshot are treated as related artifacts, not silently asserted to be a byte-matched build certificate. The application author is Lemuel van der Merwe. [Larger example](https://architecture.joomlacomponentbuilder.com/markdown/examples/service-directory.md)

## E06

**Reusable distribution channels.** The inspected snapshots are [packages](https://github.com/joomengine/packages/tree/7a26dac49093c4b9a79c793e65736efbd25f0005), [Super Powers](https://github.com/joomengine/super-powers/tree/adf335173201edeaf95f0ef6c3dc1bcabd23f3bc), [Joomla Powers](https://github.com/joomengine/joomla-powers/tree/e38ad0600bdd82513021ec7e5b2b9eecfe7f2f0b), [field types](https://github.com/joomengine/joomla-fieldtypes/tree/3be64d59378b5650825b97b44dbd58f2cdb82fcb), [snippets](https://github.com/joomengine/snippets/tree/a7f536be6ea7a8af5bdf86d81c9f7f547b862365), and [repository definitions](https://github.com/joomengine/repoindex/tree/9634461fd06cdb8235bac841e557410aac18817f). Their schemas and handlers have different responsibilities; their item counts are not interchangeable product counts.

## E07

**JCB's generated application and maintained build record.** The [official README](https://github.com/joomengine/Joomla-Component-Builder/blob/bca4a1520484f3e2c2fbd12964a5995b0d058de1/README.md) identifies the application as created with JCB. The author's development record describes its generated application layers, supplied reusable library inputs, and repeated self-build timing. C01 establishes the inspected timer boundary; the repository inventory establishes the separately counted source snapshot. [Performance](https://architecture.joomlacomponentbuilder.com/markdown/engineering/performance.md), [self-generation](https://architecture.joomlacomponentbuilder.com/markdown/engineering/regeneration.md).

## D01

**Operational documentation.** [JCB documentation snapshot](https://github.com/joomengine/jcb-documentation/tree/ecd3670232d344295fc4f673b2d3dc40a64b3bf6). The English documentation covers authoring, fields and relationships, custom code, Dynamic Gets, Powers, compilation, and maintenance. Its operational explanations informed the source investigation; implementation claims are connected to the corresponding compiler paths above.

## Using the ledger

A stronger claim should follow a listed operation into its collaborators, record the relevant branch conditions, and compare its actual consumer and output. A shared service name alone does not prove scope correctness. A generated comment alone does not prove a unique origin. A source fingerprint fixes a capture but is not a substitute for a fresh runtime build.

The [verification guide](https://architecture.joomlacomponentbuilder.com/markdown/engineering/verification.md) explains how the source, artifact, executable, mathematical, and runtime checks fit together.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/reference/bibliography.md

# Related mechanisms and bibliography

The architecture was developed independently in the course of building JCB. The references below provide established terminology and mathematical context for mechanisms that can be recognized retrospectively. A correspondence identifies what two approaches have in common; it does not invent an influence on the original development or claim that their complete implementations are equivalent.

Implementation evidence is catalogued separately in the [source map](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md). The principal correspondences concern structured intent, contextual interpretation, retained intermediate information, dependency ordering, and controlled regeneration.

## R01

**Object Management Group. Model Driven Architecture.** [Official overview](https://www.omg.org/mda/).

The separation between application intent and target-platform implementation supplies a useful context for GUI-authored JCB models and target-specific generation. JCB's database-backed entity schema and custom-code roles are its concrete representation choices; use of model-driven terminology does not imply conformance to every OMG modeling or transformation specification. See [structured intent](https://architecture.joomlacomponentbuilder.com/markdown/foundations/structured-intent.md) and [targets](https://architecture.joomlacomponentbuilder.com/markdown/compiler/targets.md).

## R02

**Donald E. Knuth. “Semantics of context-free languages.”** *Mathematical Systems Theory* 2, 127–145, 1968. DOI: `10.1007/BF01692511`. [Publisher](https://link.springer.com/article/10.1007/BF01692511).

Inherited and synthesized attributes provide a precise precedent for information flowing into a structured occurrence and results flowing out of it. JCB's field/view/component interpretation has a corresponding direction of information flow, while its implementation uses database entities, services, shared builders, and ordered calls rather than an attribute-grammar evaluator. See [context](https://architecture.joomlacomponentbuilder.com/markdown/foundations/context.md) and [classification](https://architecture.joomlacomponentbuilder.com/markdown/compiler/classification.md).

## R03

**Torbjörn Ekman and Görel Hedin. “The JastAdd system—modular extensible compiler construction.”** *Science of Computer Programming* 69(1–3), 14–26, 2007. DOI: `10.1016/j.scico.2007.02.003`. [Publisher](https://doi.org/10.1016/j.scico.2007.02.003) · [JastAdd concept overview](https://jastadd.cs.lth.se/web/documentation/concept-overview.php).

JastAdd combines modular compiler construction with reference attributes, contextual information, and demand-driven evaluation. It is a close comparison for obtaining an interpretation when required and retaining relationships between uses and definitions. JCB's manually orchestrated phases, mutable builders, repository acquisition, and textual emitters remain distinct. The comparison helps identify the actual dependencies of reuse rather than treating every retained result as a context-free cache.

## R04

**JetBrains. MPS generator documentation.** [Generator](https://www.jetbrains.com/help/mps/mps-generator.html) · [Generator cookbook](https://www.jetbrains.com/help/mps/generator-cookbook.html) · [Mapping labels](https://www.jetbrains.com/help/mps/generator-language.html) · [Generation plans](https://www.jetbrains.com/help/mps/generation-plan.html).

MPS mapping labels retain a relationship from input nodes to generated nodes so later reference generation can retrieve the correct counterpart. Generation plans and priorities make transformation ordering explicit. This is a particularly relevant comparison for JCB's retained identities, deferred consumers, and staged generation. MPS's model-to-model transformations and typed node representation differ from JCB's mixture of structured stores and prepared text. The shared architectural question is how a later consumer finds the interpretation established by an earlier producer.

## R05

**Andrey Mokhov, Neil Mitchell, and Simon Peyton Jones. “Build systems à la carte.”** *Proceedings of the ACM on Programming Languages* 2, ICFP, article 79, 2018. DOI: `10.1145/3236774`. [Author/institutional publication](https://www.microsoft.com/en-us/research/publication/build-systems-la-carte/).

The expanded **“Build systems à la carte: theory and practice”**, *Journal of Functional Programming* 30, 2020, has DOI `10.1017/S0956796820000088`. [Journal-version record](https://www.microsoft.com/en-us/research/publication/build-systems-a-la-carte/).

Separating dependency structure, execution order, and rebuilding decisions is useful when analyzing JCB's acquisition queues and deferred work. A within-build cache or fixed replay phase is not automatically a complete cross-build incremental invalidation system. This publication keeps those responsibilities distinct. See [resolution](https://architecture.joomlacomponentbuilder.com/markdown/formal/resolution.md) and [deferred work](https://architecture.joomlacomponentbuilder.com/markdown/compiler/deferred-work.md).

## R06

**Donald Michie. “‘Memo’ Functions and Machine Learning.”** *Nature* 218, 19–22, 1968. DOI: `10.1038/218019a0`. [Publisher](https://www.nature.com/articles/218019a0).

Memoization supplies the basic precedent for retaining a computed result to avoid repeating work. JCB's retained state is broader: some entries are acquired definitions, others contextual contributions or operations awaiting later prerequisites. Retrieval can have effects. The paper therefore distinguishes memoized values, contribution guards, dispensers, and deferred work rather than using *cache* for all four.

## R07

**J. Nathan Foster, Michael B. Greenwald, Jonathan T. Moore, Benjamin C. Pierce, and Alan Schmitt. “Combinators for bidirectional tree transformations: A linguistic approach to the view-update problem.”** *ACM Transactions on Programming Languages and Systems* 29(3), article 17, 2007. DOI: `10.1145/1232420.1232424`. [Publisher](https://doi.org/10.1145/1232420.1232424). The earlier conference presentation appeared at POPL 2005.

Bidirectional transformation research supplies the vocabulary for relating a source representation, a derived view, and updates returned from that view. JCB's marked-code recovery is bounded by recognized regions and supported reverse transformations; extrusion reconstructs candidates from represented artifacts. Their domains and preservation relations must be stated separately. See [transport and reconstruction](https://architecture.joomlacomponentbuilder.com/markdown/formal/transport.md).

## R08

**Eclipse Acceleo. User Guide.** [Official archived guide](https://wiki.eclipse.org/Acceleo/User_Guide).

Protected areas and JMerge integration are established approaches to retaining authored material across generation. They provide relevant context for JCB's designated code regions, GUI addresses, and placement recovery. The comparison concerns regeneration ownership and preservation, not an assertion that every marker scheme has identical identity, merge, or fallback semantics. JCB's commented recovery path is described by its own source in [custom code](https://architecture.joomlacomponentbuilder.com/markdown/compiler/custom-code.md).

## R09

**Alfred Tarski. “A lattice-theoretical fixpoint theorem and its applications.”** *Pacific Journal of Mathematics* 5(2), 285–309, 1955. DOI: `10.2140/pjm.1955.5.285`. [Publisher](https://msp.org/pjm/1955/5-2/p05.xhtml).

Order-theoretic fixed-point reasoning is an established foundation. The paper's finite dependency-closure argument uses an elementary finite instance: adding reachable requests stabilizes when no new request is added. It does not identify the entire effectful compiler with a monotone fixed-point evaluator, and it does not present the closure argument as new mathematics.

## R10

**David L. Parnas. “On the criteria to be used in decomposing systems into modules.”** *Communications of the ACM* 15(12), 1053–1058, 1972. DOI: `10.1145/361598.361623`. [Publisher](https://doi.org/10.1145/361598.361623).

Information hiding and responsibility-based decomposition supply a useful context for the compiler's separation into acquisition, naming, classification, language, target architecture, binding, and filesystem services. The history of refactoring a large compiler into specialized collaborators is described in [provenance](https://architecture.joomlacomponentbuilder.com/markdown/foundations/provenance.md). The correspondence concerns boundaries and change ownership, not compliance inferred merely from having many classes.

## R11

**LLVM Project. LLVM Language Reference Manual.** [Official reference](https://llvm.org/docs/LangRef.html).

Intermediate representations separate source from target and give transformations a defined object to manipulate. JCB's concern-specific records and prepared fragments perform intermediate roles. A registry of text does not acquire the type, control-flow, or SSA properties of LLVM IR simply because both are intermediate. The paper uses the role-level comparison while retaining the concrete structure of JCB's stores.

## R12

**PHP Documentation Group. `str_replace`.** [Official manual](https://www.php.net/manual/en/function.str-replace.php).

Array-based string replacement processes entries in order, which can affect subsequently introduced text. JCB's placeholder action modes add their own map-selection rules. The exact composition is defined in [binding](https://architecture.joomlacomponentbuilder.com/markdown/compiler/binding.md) and [staging](https://architecture.joomlacomponentbuilder.com/markdown/formal/staging.md), and tested in the executable companion. This technical reference is included because substituting a superficially similar algorithm would alter behavior.

## R13

**PHP Framework Interop Group. PSR-4: Autoloader.** [Official specification](https://www.php-fig.org/psr/psr-4/).

Namespace-to-path mapping supplies a relevant target-platform convention for reusable code placement and autoloading. JCB adds stable Power identity, local acquisition, contextual namespace processing, per-file import aliases, and selected source placement around those conventions. PSR-4 is a naming/loading contract, not a complete description of that compiler workflow.

## R14

**H. Penny Nii. “Blackboard Systems: Part One—The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures.”** *AI Magazine* 7(2), 38–53, 1986. DOI: `10.1609/aimag.v7i2.537`. [Publisher](https://onlinelibrary.wiley.com/doi/abs/10.1609/aimag.v7i2.537).

Specialized producers and consumers cooperating through shared state have a family resemblance to blackboard organization. JCB's observed execution is explicitly orchestrated, however; the presence of shared stores does not establish opportunistic blackboard scheduling. The useful connection is coordination through retained information with defined responsibilities.

## R15

**Todd J. Green, Grigoris Karvounarakis, and Val Tannen. “Provenance semirings.”** *Proceedings of PODS*, 31–40, 2007. DOI: `10.1145/1265530.1265535`. [Publisher](https://doi.org/10.1145/1265530.1265535).

Provenance research studies how contributing inputs relate to a result. The paper's occurrence–contribution–artifact relation uses that general question to organize source traces. It does not assert that JCB implements a provenance semiring or records a complete provenance graph during every build. The trace relation is a tool for explanation and verification.

## R16

**Walid Taha and Tim Sheard. “Multi-stage programming with explicit annotations.”** *Proceedings of PEPM*, 203–217, 1997. DOI: `10.1145/258993.259019`. [Publisher](https://doi.org/10.1145/258993.259019).

Explicit staging provides a vocabulary for separating preparation from later computation. JCB's deferred work, retrieval-time contextualization, and ordered file binding exhibit different staging responsibilities. String substitution does not inherit the scope and type guarantees of a staged programming calculus; the account states its actual replacement semantics instead.

## Correspondence without flattening the architecture

These references identify several established tools for understanding the implementation. No single comparison replaces the complete account. Attribute computation does not alone specify blueprint transport; mapping labels do not alone specify local persistence; memoization does not specify deferred effectful work; protected regions do not specify field permissions or target-aware class placement.

The architectural object studied here is their implemented coordination around reusable definitions and complete generated applications. Its originality is presented through the attributable implementation and the particular organization described, while established principles receive their own credit. A reader can use the references to deepen any part of the account and the [source map](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md) to inspect how JCB realizes it.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/reference/edition.md

# Edition scope and engineering record

**Title:** Joomla Component Builder: Contextual Compilation Architecture  
**Author:** Llewellyn van der Merwe  
**Publisher:** Vast Development Method  
**Architectural edition:** 1.0.0 · 16 September 2026  
**Publication:** architecture.joomlacomponentbuilder.com

This is the author's technical white paper, prepared with research and editorial assistance. It explains the implemented architecture in language-neutral terms and connects the explanation to source responsibilities, public blueprints, generated products, and executable mathematical examples.

The edition number identifies the publication. It is not a Joomla or JCB software release number.

## Compiler and integrated capability scope

The core compiler source study is pinned to official revision `bca4a1520484f3e2c2fbd12964a5995b0d058de1`. It covers acquisition, semantic classification, intermediate stores, deferred execution, target selection, ordered binding, code injection, generated application concerns, recovery, and packaging.

The edition additionally documents the implemented component and class extrusion machinery prepared for the integrated release: bounded artifact discovery, typed readers, property precedence, candidate pairing, shared-field resolution, class/namespace reconstruction, and ordered model writers. This capture extends beyond the older core pin. Its paths and SHA-256 fingerprints are recorded under [X01–X04](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md#x01), rather than linked to files that are absent from that pinned revision.

The architectural description includes those implemented operations. Availability in a particular installed release is determined by the [official JCB repository and release](https://github.com/joomengine/Joomla-Component-Builder), not by the white paper's edition number. This separates capability description from release packaging without requiring the architecture to be rewritten when the integration is published.

## Source and documentation captures

The [source map](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md) fixes the core compiler, operational documentation, Hello World blueprint and products, Service Directory family, and reusable distribution repositories. The inspection follows the principal operation paths and their collaborators. A repository snapshot being collected is not represented as a claim that every line in it was independently audited.

The documentation repository supplies the authoring and operational context for mechanisms visible in source. Public examples make selected input/output correspondences inspectable. The supplemental source capture fixes the integrated extrusion behavior without introducing another public compiler repository into the publication.

Historical implementation is separately pinned to root commit `ecf47809f960bd057af8a414168fada6fe22c5f7`, recorded on 30 January 2016 at 20:28:43 UTC. The current paper and every later feature are not retroactively assigned that date.

## The maintained measurement record

The author records repeated self-builds in which an approximately 30,000-line exported JCB blueprint produces an application exceeding one million lines in approximately 60–64 seconds on the demonstrated setup. Compiler rules, templates, reusable Powers, libraries, and assets participate as additional inputs.

The paper preserves this as an engineering measurement record. It does not assign a hardware configuration or per-run data that was not supplied. The inspected timer boundary and the separately counted pinned repository snapshots are identified in [performance](https://architecture.joomlacomponentbuilder.com/markdown/engineering/performance.md). A new reproducible run package can add its environment, blueprint, output inventory, and individual timings to that record.

Output volume, compilation elapsed time, and hypothetical manual development effort are different measurements. Compiler-produced estimates based on seconds per line or file are not relabeled as measured hours saved.

## Mathematical scope

The formal account introduces explicit identities, contexts, contributions, state transitions, request graphs, binding sequences, and representation equivalences. Its propositions state assumptions for the mechanism being described. Finite request traversal, safe contextual reuse, prescribed-sequence repeatability, and transport preservation are separate results.

A source path corresponds to a proposition where the path meets its assumptions. The model does not replace ordered mutation with a fictional immutable state, infer global transactions from ordered writes, or turn every generated region into a universally invertible transformation.

The mathematical contribution of the publication is the explicit account of this architecture's relationships and operations. Established proof techniques and related systems are credited in the [bibliography](https://architecture.joomlacomponentbuilder.com/markdown/reference/bibliography.md).

## Authorship and originality

The development account records the author's independent construction of JCB and its subsequent refactoring and maintenance. Retrospective correspondences to earlier research are acknowledged as correspondences, not invented influences. Independent development and first historical invention are different claims.

Application authors retain their attribution. In particular, the Service Directory example names Lemuel van der Merwe as its application author. Joomla and reusable third-party works retain their own authorship and licenses. The paper's account of JCB does not claim ownership of those works.

## Using this edition

The main reading path describes what the system does and how its operations fit together. The [source map](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md), [verification guide](https://architecture.joomlacomponentbuilder.com/markdown/engineering/verification.md), [citation information](https://architecture.joomlacomponentbuilder.com/markdown/reference/citation.md), and [publication details](https://architecture.joomlacomponentbuilder.com/markdown/reference/publication.md) support reproducible examination. Each article has an exact Markdown alternate, and complete downloadable editions are generated from the same source.

The intended use is understanding and reuse: another engineer should be able to identify a represented decision, follow its transformation, examine the mathematical relation, and implement the same architectural choice in a different technology.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/reference/glossary.md

# Architectural glossary

The terms below identify roles in the architecture. Where JCB uses a product-specific name, its general engineering meaning is given alongside it. The [notation](https://architecture.joomlacomponentbuilder.com/markdown/formal/notation.md) supplies the mathematical symbols.

## Artifact

A generated or assembled product with a role, destination, context, content, and remaining processing stages. Files, language catalogues, supporting assets, manifests, and archives are artifacts. A file can exist before its final binding and injection stages are complete. [Materialization](https://architecture.joomlacomponentbuilder.com/markdown/generation/materialization.md)

## Blueprint

The portable design representation: selected entity properties, typed identities, relationships, dependencies, authored code, and assets. Repository indexes and README descriptions locate or explain that design; they are counted separately from its payloads. [Representation](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/representation.md)

## Build context

The values that qualify an operation, including target, extension, view, generation role, language destination, active bindings, and occurrence settings. Runtime users and application data are a different context supplied when the generated application runs. [Context](https://architecture.joomlacomponentbuilder.com/markdown/foundations/context.md)

## Compilation

The coordinated acquisition, interpretation, contribution, staged binding, code placement, and materialization of a represented application. The complete execution includes constructor preparation, later file updating, diagnostics, and packaging. [Execution](https://architecture.joomlacomponentbuilder.com/markdown/compiler/execution.md)

## Contribution

A result of interpreting a definition's use: a store, key, update operation, and value. It may be schema data, a language entry, a query alias, a fragment, a requirement flag, or deferred work. Contributions are not all strings or immutable facts. [Classification](https://architecture.joomlacomponentbuilder.com/markdown/compiler/classification.md)

## Definition

Reusable design knowledge with typed identity. A field, view, Power, template, or query definition can participate in several uses. Its identity differs from a local database row number and from a final output path. [Identity](https://architecture.joomlacomponentbuilder.com/markdown/foundations/identity.md)

## Deferred work

An operation retained with its arguments because its required information will be ready later. JCB's selected admin replay and configuration-fieldset passes are examples. It differs from acquiring a definition lazily or binding a placeholder late. [Deferred work](https://architecture.joomlacomponentbuilder.com/markdown/compiler/deferred-work.md)

## Dependency

A typed relationship or resource requirement exposed by an entity's schema, association, recognized embedded reference, or asset configuration. Incoming owned children and outgoing shared references can have different reset policies. [Dependency traversal](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/dependencies.md)

## Dispenser

JCB's role- and context-indexed store for prepared code. Retrieval can apply the active placeholder environment, add surrounding material, and remove consumed content. It is not merely a cache of final output strings. [Custom code](https://architecture.joomlacomponentbuilder.com/markdown/compiler/custom-code.md)

## Dynamic Get

JCB's structured query/retrieval definition. It describes sources, selections, aliases, joins, filters, ordering, and result roles that are compiled into model code. Runtime query values remain inputs to the generated application. [Queries](https://architecture.joomlacomponentbuilder.com/markdown/generation/queries.md)

## Extrusion

Recovery of represented model information from an existing component or class library. Discovery, static readers, precedence, identity resolution, reviewable candidates, and writers return supported structure to JCB's editable definitions. It differs from importing an explicit blueprint. [Extrusion](https://architecture.joomlacomponentbuilder.com/markdown/extrusion/overview.md)

## GUI-linked region

A generated code region associated with a local table, property, and record address so eligible edits can be recovered. Its local numeric address is not the portable identity of the application model. [Custom-code trace](https://architecture.joomlacomponentbuilder.com/markdown/examples/custom-code-trace.md)

## Infusion

The implementation's name for preparing and coordinating generated content. It invokes interpretation and creators, establishes shared and contextual bindings, and completes selected deferred work. The term is retained when naming the source service, not required of a reimplementation. [Execution](https://architecture.joomlacomponentbuilder.com/markdown/compiler/execution.md)

## Initialization and reset

Initialization ordinarily preserves an acceptable local definition and acquires one where missing. Reset explicitly requests refresh; owned incoming children and referenced reusable definitions follow their respective recursive policies. These operations are not interchangeable overwrite modes. [Import](https://architecture.joomlacomponentbuilder.com/markdown/blueprints/import.md)

## Intermediate representation

Information retained between input acquisition and final output. JCB uses structured records, specialized builders, flags, code fragments, and binding maps. Calling these intermediate representations identifies their role without attributing the structural guarantees of a typed AST or SSA system. [Stores](https://architecture.joomlacomponentbuilder.com/markdown/compiler/stores.md)

## Occurrence

A definition's particular use under an association, placement, and context. Two views can reuse one field while assigning different roles or layout positions. The occurrence is not necessarily a separately allocated object in the implementation. [Identity](https://architecture.joomlacomponentbuilder.com/markdown/foundations/identity.md)

## Placeholder and binding environment

A placeholder identifies text to be replaced using an applicable environment. JCB's environments and action modes have ordered replacement semantics, including original-input filtering in action 3. A binding stage is the point at which a selected environment is applied. [Binding](https://architecture.joomlacomponentbuilder.com/markdown/compiler/binding.md)

## Power and Joomla Power

A Power is a managed reusable code definition with stable identity, dependencies, namespace, and placement behavior. A Joomla Power represents a version-sensitive platform class mapping. Both connect stable references to context-appropriate symbols, but their payloads and generation roles differ. [Powers](https://architecture.joomlacomponentbuilder.com/markdown/compiler/powers.md)

## Recollection

An explanatory term for retrieving identified retained information when a consumer needs it, sometimes with further acquisition or contextual processing. It denotes a software operation here, not a claim about biological memory. The precise store and retrieval contract should be named whenever ambiguity matters.

## Reconciliation and recovery

Returning designated authored changes to managed design state under the implementation's identity and transformation rules. Fingerprint placement and commented fallback distinguish executable placement from recoverability. This is not a general automatic three-way merge or an inverse for arbitrary source edits. [Transport](https://architecture.joomlacomponentbuilder.com/markdown/formal/transport.md)

## Semantic classification

Interpreting a definition in context and routing its different consequences to concern-specific consumers. It is not an ordinary sorting algorithm over comparable values. Schema, query, form, policy, language, and code-placement consequences can arise from the same occurrence. [Classification](https://architecture.joomlacomponentbuilder.com/markdown/compiler/classification.md)

## Target

The platform and generation conventions selected for output. It differs from the host running the compiler and from the application's own version number. Target-specific emitters and Joomla Power mappings carry shared adaptation knowledge. [Targets](https://architecture.joomlacomponentbuilder.com/markdown/compiler/targets.md)

## Trace and equivalence

A trace records an ordered sequence of operations or source-to-output correspondences. An equivalence states which observations a comparison preserves: portable design, normalized artifacts, or raw bytes. A local identity or date difference can matter to one comparison and not another, but the rule must be declared. [State](https://architecture.joomlacomponentbuilder.com/markdown/formal/state.md), [transport](https://architecture.joomlacomponentbuilder.com/markdown/formal/transport.md)


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/reference/citation.md

# Citation and authorship

**Llewellyn van der Merwe. _Joomla Component Builder: Contextual Compilation Architecture_. Edition 1.0.0. Vast Development Method, 16 September 2026.**

Publication: [architecture.joomlacomponentbuilder.com](https://architecture.joomlacomponentbuilder.com). Source: [joomengine/architecture](https://github.com/joomengine/architecture).

The author is the originator and principal implementer of the JCB architecture described. Research, editorial, and tooling assistance support the author's account. The publication does not present itself as an external certification of the project.

## Machine-readable citation

The repository provides [CITATION.cff](https://github.com/joomengine/architecture/blob/main/CITATION.cff). A BibTeX form is:

```bibtex
@techreport{vandermerwe2026jcbarchitecture,
  author      = {van der Merwe, Llewellyn},
  title       = {Joomla Component Builder: Contextual Compilation Architecture},
  institution = {Vast Development Method},
  year        = {2026},
  month       = sep,
  version     = {1.0.0},
  url         = {https://architecture.joomlacomponentbuilder.com},
  note        = {Technical white paper, edition of 16 September 2026}
}
```

## Citing an individual mechanism

For a specific result, name the article and section in addition to the edition. For example, a citation of ordered placeholder replacement should identify *Deferred execution and substitution semantics* and its action definitions. A citation of the Greeting trace should identify the field article and the pinned blueprint/product commits.

The [article manifest](https://architecture.joomlacomponentbuilder.com/articles.json) records article metadata, canonical and Markdown addresses, and source hashes. The exact Markdown alternate provides the article's source text. The complete edition archive preserves the corpus together for offline examination.

A moving publication URL and an immutable repository revision answer different needs. The former locates the current reading interface; the latter fixes the text used in a particular analysis. Record a commit or source hash when exact reproducibility matters.

## Citing implementation behavior

Use the official implementation paths and revisions in the [source map](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md). The publication's explanatory wording and the compiler source are separate works. Citing the paper for an architectural interpretation does not replace citing a particular implementation when discussing its exact branch behavior.

The integrated extrusion capture has its own edition scope and file fingerprints. Do not attach its behavior to an earlier core revision that lacks those files. [Edition scope](https://architecture.joomlacomponentbuilder.com/markdown/reference/edition.md)

## Citing engineering measurements

The repeated JCB self-build figure is an engineering record from the author. Its approximate blueprint size, output size, and elapsed time should be kept together with their scope and additional reusable inputs. The separate Hello World inventory has exact pins and an explicit counting rule.

A source-file inventory is not a newly executed compiler benchmark. A hypothetical seconds-per-line labor estimate is not measured development time. [Performance](https://architecture.joomlacomponentbuilder.com/markdown/engineering/performance.md), [accounting](https://architecture.joomlacomponentbuilder.com/markdown/examples/accounting.md)

## Attribution of related work

The [bibliography](https://architecture.joomlacomponentbuilder.com/markdown/reference/bibliography.md) credits the prior research and official documentation used to explain related mechanisms. The author's independent development history is retained in [provenance](https://architecture.joomlacomponentbuilder.com/markdown/foundations/provenance.md). Neither independent rediscovery nor retrospective similarity should be converted into an unsupported claim of first invention or direct influence.

Applications generated by JCB retain their own authorship. The Service Directory's application attribution, third-party library notices, and Joomla's attribution remain distinct from the authorship of this architectural white paper.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/reference/publication.md

# Publication, downloads, and maintenance

The publication is authored in Markdown under `DOCS/`. HTML pages, navigation, search, downloadable editions, and machine-readable indexes are generated from that source. A second independently maintained prose version is not required.

`site.json` supplies the title, author, publisher, edition, canonical domain, repository, and reading sections. The template uses text-based JCB architecture headings and retains the small VDM mark. System-following light/dark mode and an explicit user override are part of the reading interface.

## Every article has an exact Markdown equivalent

An article at `DOCS/compiler/binding.md` is published as an HTML page at `/compiler/binding/` and an exact source alternate at `/markdown/compiler/binding.md`. The page's Markdown action and alternate metadata point to that source. The build preserves the Markdown bytes, including front matter, rather than reconstructing prose from HTML.

Article-to-article links in source use relative `.md` paths. The renderer resolves them to the correct HTML destinations while the source remains usable as a connected Markdown corpus. Heading anchors, descriptions, and reading order are checked during publication.

## Complete editions and indexes

The build produces:

| Artifact | Purpose |
| --- | --- |
| `/downloads/jcb-architecture-complete.md` | A combined reading edition |
| `/downloads/jcb-architecture-markdown.zip` | All article sources in their directory structure |
| `/articles.json` | Article metadata, canonical/Markdown addresses, and SHA-256 hashes |
| `/search.json` | Searchable titles, descriptions, and article text |
| `/llms.txt` | Machine-readable publication entry points |
| `/llms-full.txt` | Full-text corpus for tools and offline analysis |
| `/sitemap.xml` | Canonical public page locations |

The article-level Markdown alternate remains the exact source. The combined reading edition can add separators and rewritten cross-article addresses for usability; it is not substituted for the source hash of an individual article.

## Build and inspect locally

From a checkout of the publication repository:

```bash
python3 -m venv .venv
. .venv/bin/activate
python -m pip install -r requirements.txt -r requirements-dev.txt
python -m unittest discover -s tests -v
python examples/demo.py
python scripts/vendor.py
python scripts/prepare_evidence.py
python scripts/build.py
python scripts/check_site.py
python -m playwright install chromium
python scripts/browser_check.py
python scripts/archive.py
python -m http.server 8000 --directory site
```

The vendor step acquires the pinned browser dependencies and records their hashes. Mathematical rendering uses the selected MathJax SVG output; diagrams use the pinned Mermaid bundle. The publication does not require a hosted third-party rendering service for each reader's equation or diagram.

## Pull-request validation and production deployment

The workflow archives the reviewed source before running the checks. It then tests the executable mechanisms and publication tooling, runs the demonstration, builds the site, checks article/Markdown consistency, and tests browser behavior. Review artifacts include the built site archive and validation evidence.

Pull requests do not deploy. Only a successful build of `main` reaches the GitHub Pages deployment job. The maintainer reviews and merges the branch; editorial work does not independently change the production domain or release the compiler.

## Domain configuration

The intended address is **`architecture.joomlacomponentbuilder.com`**. The repository generates its canonical addresses and a descriptive `CNAME` artifact from `site.json`. With a custom GitHub Actions Pages deployment, GitHub's repository Pages setting—not that generated file—controls the custom-domain association.

The maintainer should configure/verify the custom domain in GitHub Pages and create the subdomain's DNS CNAME pointing to **`joomengine.github.io`**, without a repository suffix. HTTPS activation and DNS validation are hosting operations separate from the source rewrite. Follow the [official GitHub custom-domain instructions](https://docs.github.com/en/pages/configuring-a-custom-domain-for-your-github-pages-site/managing-a-custom-domain-for-your-github-pages-site).

Do not leave an unclaimed DNS alias pointing at a disabled Pages site. Retaining an old address as a redirect requires control of that old host; the new publication cannot create an HTTP redirect on another domain merely by changing its canonical URL.

## Edition history and maintenance

The earlier manuscript remains in repository history at `c833d39f606d2b237eeaecbd5c41a350dde823cb`. This edition replaces its framing and article structure while retaining useful publishing infrastructure, attribution, and research references.

When implementation changes, update the affected source correspondence, worked trace, and mathematical assumptions together. When only a publication URL changes, update the canonical configuration, citation metadata, downloads, and generated indexes consistently. Stable article paths and explicit edition records make those changes inspectable.

The [verification guide](https://architecture.joomlacomponentbuilder.com/markdown/engineering/verification.md) distinguishes publication integrity from source, artifact, and runtime verification. A successful site build establishes that the explanation is published correctly; it is not a substitute for testing the compiler's generated applications.


---

Source article: https://architecture.joomlacomponentbuilder.com/markdown/reference/licensing.md

# Rights and reuse

The original prose, mathematical exposition, and authored diagrams in this publication are licensed under **Creative Commons Attribution 4.0 International (CC BY 4.0)**. The original publication tooling and executable reference examples are licensed under **MIT**. The repository's license and notice files identify the applicable material.

Author: **Llewellyn van der Merwe**. Publisher: **Vast Development Method**.

## Reusing the explanatory work

CC BY 4.0 permits sharing and adaptation, including commercial use, subject to its terms. Give appropriate credit, link the license, and indicate changes. Attribution must not suggest endorsement of an adaptation by the author or publisher. The [license deed](https://creativecommons.org/licenses/by/4.0/) summarizes the terms; the [legal code](https://creativecommons.org/licenses/by/4.0/legalcode) is authoritative.

A useful attribution names the paper, author, edition, publication address, and license. [Citation examples](https://architecture.joomlacomponentbuilder.com/markdown/reference/citation.md)

## Reusing the executable companion

The original reference mechanisms and website tooling are covered by the repository's MIT license notice. Retain the required copyright and permission notice when redistributing covered software. The executable companion is a small explanatory implementation; its license does not relicense the Joomla Component Builder source referenced by the paper.

## Cited code and third-party material

JCB, Joomla, Powers, libraries, application examples, and browser dependencies retain their respective licenses and notices. A source link or discussion in this white paper does not transfer those rights or imply that all cited software is under the paper's license.

VDM branding is retained as publisher identity. The explanatory-text license does not grant permission to represent an unrelated project as VDM or as an endorsed JCB implementation. Third-party trademarks and marks remain with their owners.

## Implementing the architectural ideas

The publication is intended to help engineers understand and reuse the described approach. Its license governs the covered expression and software. It is not presented as exclusive ownership of every mathematical principle, design pattern, or independently implemented algorithm discussed in the account.

An implementation that copies covered code or prose should follow the applicable license for that material. An implementation that uses a cited third-party library must follow that library's terms separately. The [bibliography](https://architecture.joomlacomponentbuilder.com/markdown/reference/bibliography.md) and [source map](https://architecture.joomlacomponentbuilder.com/markdown/reference/source-map.md) keep those origins visible.

## Preserving attribution accurately

The white paper's author, the compiler's originator, and the authors of generated applications are not automatically the same person. The Service Directory example retains its own application attribution. Research references identify earlier work without implying that it was part of the original developer's influences.

The repository's `LICENSE`, `LICENSES/MIT.txt`, and `NOTICE.md` remain the primary local notices. This page explains the publication's intended boundaries and does not replace those texts.