A modern website is not a folder of independent files.
A page depends on a layout. The layout loads styles and scripts. A view queries content. CSS refers to images and fonts. Links point to routes. Components contain other components. The same image may appear in a page, a product, a style rule, and an email.
Most development tools store these pieces, but they do not understand the complete website relationship. When something moves or disappears, developers discover the consequences later: a broken image, an old URL, a missing dependency, stale browser content, or a component that looked unused but was not.
Kooboo treats these connections as part of the website itself.
The website is not only its objects. It is also the relationships between those objects.
Demo one: find every place an image is used
Instead of searching through source files and hoping every reference has the same spelling, Kooboo can show the website objects that use it.
- Open Media Libary of the website.
- Show the pages, layouts, views, styles, or other objects that refer to it.
- Open one of those consumers directly.
- Replace or edit the image and verify the affected pages.
The same relationship model is useful for more than images. Kooboo records typed connections between many site objects, including pages, layouts, views, styles, scripts, resource groups, routes, labels, HTML blocks, forms, components, content, files, and external resources.
Demo two: change a local URL or localize external resource
URL changes are deceptively expensive. A route may be referenced by navigation, content, HTML attributes, layouts, views, styles, or other application objects.
In Kooboo, route relationships identify the objects that refer to a URL. When the route is updated through the supported URL-editing workflow, Kooboo can update those known consumers and rebuild the corresponding relationships.
When an external file like javascript or images, this creates data breach legal issue, Kooboo can one click to convert the external resource into object in local website and update all related references.
- Open the URL menu under development
- Show all the URL defined within the website and where it is used
- Navigate to External, shows all external links or resources being used
- Click to edit or localize external resource
Relation intelligence begins when the source is saved
Kooboo has its own HTML DOM engine. When a source-aware website object is added or changed, Kooboo can parse the real document structure and compute relationships from it.
The relation engine recognizes connections such as:
- Referenced stylesheets and scripts
- Images and website files
- Internal links and external URLs
- Layouts used by pages
- Components embedded in other objects
- Inline styles and CSS class use
- Labels, HTML blocks, forms, and configuration objects
- Embedded styles, scripts, forms, and KScript blocks
- Video and other routed resources
Each relationship retains the identity and type of both sides. Kooboo therefore knows more than “this text appears somewhere.” It knows that a Page refers to a Route whose destination is an Image, or that a View is used by a Page.
This is a practical object graph built into the site database.
Ask both questions: “What does this use?” and “What uses this?”
A relationship becomes useful only when it can be followed in both directions.
From a page, Kooboo can inspect the layouts, views, resources, components, and routes it uses. From an image, style, view, or route, Kooboo can inspect the objects that use it.
That changes common maintenance work:
- Before editing: understand the scope of the change.
- Before deleting: inspect the consumers that may be affected.
- After importing: identify missing or external resources.
- During debugging: move from a rendered problem to the responsible object.
- During optimization: find large images and the pages that use them.
- During packaging: understand which objects belong together.
Kooboo does not need to rediscover the entire application through text search every time a user asks one of these questions.
External resources become visible—and can become local
External resources are easy to add and easy to forget. A template may depend on a remote font, image, stylesheet, or script. That dependency can affect privacy, performance, reliability, security policy, and long-term ownership.
Kooboo records recognized external URLs as external-resource objects and connects them to the source objects that use them. Users and AI can list those URLs instead of treating them as invisible strings scattered through the website.
Kooboo can then internalize supported external images, scripts, and styles:
- Download the resource into the Kooboo website.
- Create the corresponding local object and route.
- For a stylesheet, inspect and download supported referenced resources recursively.
- Use the relation map to replace known consumers with the new local URL.
This is particularly valuable when making third-party assets—such as externally hosted fonts—part of the site that the owner controls. It can reduce runtime dependence on another host and can help with privacy and availability, although licensing terms must still permit local hosting.
If the website depends on it, Kooboo should be able to show it.
Diagnosis becomes specific instead of generic
A scan that reports “missing image” is useful. A scan that also reports where the missing image is used is actionable.
Kooboo’s diagnosis and automation code combines resource checks with relation data. It can identify conditions such as:
- Internal links whose destination is missing
- Missing images
- External links that should be validated
- Images above configured size expectations
- Malformed HTML and duplicate element IDs
For relationship-aware checks, the report can include the objects that use the problem resource. The developer can move from symptom to source without manually crawling the website.
Cache versioning follows the object version
Long browser caching improves performance, but it creates a familiar deployment problem: the browser may keep an old image, stylesheet, or script after the website changes.
Kooboo can append a version query parameter to eligible local asset URLs. The value comes from the current website object or route version. When a versioned image, style, script, resource group, or supported module resource changes, its rendered URL can change as well.
That creates a simple performance contract:
- An unchanged asset can remain cached.
- A changed asset receives a changed URL.
- The browser requests the new version instead of reusing stale content.
The developer does not need to rename every file manually or run a separate fingerprinting pipeline for ordinary Kooboo-managed resources.
The inline editor works because Kooboo understands the source
Relation intelligence and source-aware editing reinforce each other.
The inline editor can connect a rendered element back to the page, layout, view, content, style, or other source that produced it. The relation system adds another dimension: how that source participates in the rest of the website.
A user can begin with what is visible, trace it to the responsible source, and then inspect the objects connected to that source. This is much closer to editing a living application than editing a screenshot of one.
AI needs structure, not a larger text search
An AI that sees only files must infer the architecture from names and text. That works until names are ambiguous, content is generated dynamically, or a URL is referenced through several object types.
Kooboo can give AI structured operations for listing external URLs, internalizing selected resources, reading object context, inspecting rendered elements, and changing routes. The platform’s object and relation model provides safer context for those operations.
This does not make every generated reference automatically knowable. A URL assembled dynamically at runtime may not be visible to static relation analysis. Custom code and unusual source formats still require testing. The advantage is that ordinary website relationships are first-class platform data rather than undocumented developer knowledge.
Designed for runtime use, not a heavyweight graph service
Kooboo stores relation records in its own site database and represents object types with compact identifiers. Relationship lookup is part of the same local application model as pages, routes, content, and resources.
This matters for a high-density Web OS. Relation intelligence should not require a separate search cluster or graph server for every website. It should remain available to the editor, diagnosis engine, deployment tools, KScript, and AI without turning ordinary page rendering into a network of external services.
The relation model and its supporting objects use explicit serialization paths in the Kooboo codebase, fitting the platform’s NativeAOT direction without making runtime reflection the foundation of the feature.
What relation intelligence does—and does not—promise
Kooboo can understand relationships that its parsers, repositories, routes, and supported object formats recognize. It can use those relationships for navigation, diagnosis, reference updates, localization, and cache behavior.
It should not be described as infallible static analysis of arbitrary JavaScript. A URL constructed from several runtime values, fetched from an unknown external API, or hidden inside an unsupported custom format may not appear in the relation map.
The correct promise is more useful:
Kooboo turns the normal structure of a website into actionable platform knowledge.
That knowledge reduces accidental breakage, makes maintenance faster, gives AI better context, and helps the owner keep the application understandable as it grows.