Static Page Management

Relevant source files

The following files were used as context for generating this wiki page:

• stackbit.config.ts
• server.js
• about.html
• contact.html
• properties.html
• 404.html
• css/custom.css

The static page management system for the Vandore Heritage website is built around a Git-based content source, structured content models defined via Stackbit, and a simple Node.js server for serving the static HTML files. This architecture allows for content to be managed in structured JSON files, which are then mapped to corresponding HTML templates.

This system decouples content from presentation, enabling content editors to modify page data through a CMS interface (like Stackbit) without directly editing HTML. The Node.js server acts as a lightweight web server, handling file requests, serving the correct MIME types, and managing basic error handling like 404 pages.

Architecture Overview

The system follows a straightforward static site generation pattern. Content is stored in JSON files, which are governed by models defined in the Stackbit configuration. This configuration also dictates how content files map to the final HTML pages. A Node.js server is responsible for serving these static assets to the end-user.

The following diagram illustrates the high-level architecture of the static page management system.

Content Modeling with Stackbit

Content structure is formally defined in stackbit.config.ts using Stackbit's modeling capabilities. The primary content source is a GitContentSource, which reads from the content directory in the repository. Two main models are defined: Page and Property.

Sources: stackbit.config.ts:5-12

The Page Model

The Page model is a generic type for standard website pages like "About Us" or "Contact". It defines the structure for pages that are stored as JSON files within content/pages/.

The diagram below shows the relationship between the Page model and its various field types.

The fields for the Page model are detailed in the table below.

Field	Type	Description	Required
title	string	The page title, used in the <title> tag.	Yes
heroHeading	string	The main heading in the hero section.	Yes
heroSubheading	text	The subheading text in the hero section.	Yes
sections	list	A list of generic content sections, each with a heading and text.	No
properties	list	A list of property cards for listing pages.	No
team	list	A list of team members for pages like "About Us".	No
faqs	list	A list of frequently asked questions and answers.	No
blogPosts	list	A list of blog post summaries for listing pages.	No

Sources: stackbit.config.ts:17-106

The Property Model

The Property model is a data type used for individual property listings. These are stored as JSON files in content/properties/.

Field	Type	Description	Required
title	string	The name or title of the property.	Yes
price	string	The listing price.	Yes
address	string	The property's address.	Yes
description	text	A detailed description of the property.	Yes
image	string	URL or path to the main property image.	Yes
url	string	The canonical URL for the property detail page.	Yes
bedrooms	number	Number of bedrooms.	No
bathrooms	number	Number of bathrooms.	No
area	number	The area of the property (e.g., in square meters).	No
floors	number	Number of floors.	No

Sources: stackbit.config.ts:109-125

Site Mapping

The siteMap function in stackbit.config.ts is responsible for mapping the content documents (JSON files) to the final static HTML URLs that the user will access. It processes documents based on their modelName.

The following flowchart shows the logic for mapping Page and Property documents to their respective URLs.

• Page Documents: Are mapped directly to an HTML file with the same name (e.g., content/pages/about.json maps to /about.html and uses about.html as its source).
• Property Documents: Are all mapped to a single template file, property-detail-template.html, but with unique URLs based on their slug (e.g., content/properties/my-villa.json maps to /properties/my-villa.html).

Sources: stackbit.config.ts:131-150

HTML Structure and Data Binding

The HTML files (about.html, contact.html, etc.) serve as templates. They are linked to their corresponding JSON content file via a data-sb-object-id attribute on the <html> tag. This allows a CMS like Stackbit to identify which content document is being displayed.

<!DOCTYPE html>
<html lang="lv" data-sb-object-id="content/pages/about.json">
...
</html>

Sources: about.html:1, contact.html:1, properties.html:1

Within the HTML, specific elements are bound to fields from the JSON data model using the data-sb-field-path attribute. This enables field-level highlighting and editing in a visual editor.

<!-- Example from about.html -->
<h1 data-sb-field-path="heroHeading">Par mums</h1>
<p data-sb-field-path="heroSubheading">Vandore Heritage sākās ar sarunu...</p>

<!-- Example from contact.html -->
<h1 data-sb-field-path="heroHeading">Sazinieties ar mums</h1>

Sources: about.html:178-181, contact.html:150-153

Static File Server

The website is served by a simple Node.js server defined in server.js. It uses the built-in http module to handle requests and fs to read files from the disk.

Sources: server.js

Request Handling Flow

The server's primary job is to receive a request, determine the correct local file path, identify the file's MIME type, and serve it. It includes special handling for the root path (/) and for files that are not found (404).

This sequence diagram illustrates a typical request for a CSS file and a request for a non-existent page.

MIME Type Configuration

The server maintains a map of file extensions to their corresponding MIME types to ensure the browser interprets the files correctly. If an extension is not found, it defaults to application/octet-stream.

Extension	MIME Type
.html	text/html
.css	text/css
.js	text/javascript
.json	application/json
.png	image/png
.jpg	image/jpeg
.svg	image/svg+xml
.woff	font/woff
.woff2	font/woff2

Sources: server.js:8-23

Client-Side Functionality

While the pages are served statically, they incorporate client-side JavaScript and CSS to provide dynamic features.

Property Filtering

The properties.html page includes a client-side filtering mechanism. The UI for this is defined in the HTML and styled by css/custom.css. The filtering logic itself is implemented in JavaScript, which manipulates the visibility of property cards based on user selections for location, price, and bedrooms. The property cards contain data-* attributes that the JavaScript uses for filtering.

<!-- Filter bar in properties.html -->
<div class="filter-bar d-none d-lg-block bg-white p-3 rounded-3">
    ...
</div>

<!-- Property card with data attributes for filtering -->
<div class="col mb-4" data-location="riga heritage lane" data-price="950000" data-bedrooms="4">
    ...
</div>

Sources: properties.html:247-285, 293, css/custom.css:3-16

General Scripts

The js/script.js file contains general-purpose scripts for UI enhancements, such as:

• Toggling navigation menus.
• Applying a "glass" effect to the header on scroll.
• Handling tabbed content interfaces.
• Animating numbers when they scroll into view.

These scripts operate on the static DOM after it has been loaded by the browser.

Sources: js/script.js