What Are Blueprints?

A blueprint in JCB is a full internal representation of your component structure. It includes:

• Entities like Admin Views, Fields, Templates, Snippets, etc.
• Their relationships and metadata (version, UUID, parent ID)
• Component-level info (author, compile history, description)
• Language strings, field mappings, logic injections, and more

Rather than being just "a backup," blueprints are the canonical source of your component's definition — independent of compiled code output.

Versioning by Metadata

Each blueprint is version-aware and records key metadata:

• 🔖 Version: Current semantic version (e.g., 2.3.1)
• 🧬 UUID: Unique ID for the component or entity
• 📅 Timestamp: Last modified / compiled time
• 🧑 Author / Contributor: Attributed metadata
• 🧠 Hash: Entity hash for tracking diffs and compile safety

This metadata is used to detect changes, rebuild intelligently, and power auto-compile/tagging logic.

Storage Format

JCB stores blueprints in either:

• JSON format (for Git syncing, import/export)
• Database format (for active JCB usage)
• YAML or flat files (if output for CI/CD pipelines)

Each format retains all core metadata.

Benefits of Metadata Blueprinting

• 🔁 Reusability
  Export a blueprint from one project and import it into another — without losing structure, identity, or internal logic. Reuse layouts, views, field types, templates, etc.
• 🔍 Trackability
  Every change to a blueprint is traceable by hash or timestamp. You can compare versions of blueprints or entities (e.g., Admin View v1.3.0 vs v1.2.0) before compiling.
• 🌐 Git-Friendly
  Because blueprints are structured text (not just binary ZIPs), they integrate cleanly with Git. This makes them easy to:
  • Push to a central repository
  • Fork for customization
  • Reset from upstream
  • Compare via diffs
• 🛠️ Compile Safety
  JCB uses metadata to check that a blueprint is valid before compiling. If version mismatches or incompatible entities are detected, warnings or failsafes can be triggered.

Use Cases

• Exporting your JCB component for use in another project
• Maintaining centralized repositories of field definitions or layouts
• Version-controlling logic blocks, views, and full project state
• Enabling rollback or forward migration of entity changes
• Comparing blueprint evolution over time

Conclusion

Blueprint metadata turns your JCB project into a self-aware, version-controlled artifact. Whether you're managing one component or hundreds across a team, this architecture makes your work reproducible, shareable, and secure — forming the backbone of professional-grade component lifecycle management.

Summary

JCB automatically stores your component’s internal configuration as structured blueprints, complete with metadata like version numbers, entity hashes, authorship, and timestamps. These blueprints allow seamless tracking, versioning, and reuse of your component logic across projects and teams — enabling a truly modular and maintainable development workflow.