⚡ Client Variables

1️⃣ Storage & timing Stored in the browser’s Local Storage with a name like:

$OS_Users$$ClientVars$

Example:

$OS_Users$CVDemo$ClientVars$IsFullScreen

• CVDemo = Module name

• IsFullScreen = Client Variable name

2️⃣ Access with native JavaScript

localStorage.setItem("$OS_Users$CVDemo$ClientVars$IsFullScreen", true);localStorage.getItem("$OS_Users$CVDemo$ClientVars$IsFullScreen");

3️⃣ Access from other applications Any external application can also set and get the same key in Local Storage.

4️⃣ Maximum size for Text values Depends on the browser. If the quota is exceeded, you’ll get:

Uncaught QuotaExceededError: Failed to execute 'setItem' on 'Storage'

5️⃣ Why not Structure or Entity? Designed for simple values only (Local Storage supports strings). 👉 Workaround: use Serialization / Deserialization (e.g., JSON.stringify / JSON.parse). But remember: this is a workaround to use only when really needed.

6️⃣ Cross-module usage Yes, by creating Client Actions for set/get and reusing them in other modules.

🖥️ Site Properties (O11) or Settings (ODC)

1️⃣ Storage Persisted in the Database. On first get, it’s loaded from the database into Heap Memory and then read from there until updated.

2️⃣ With Load Balancer Each server follows the same logic: initial read from database → cached in memory.

3️⃣ Direct access vs Database

• Direct access = faster (uses Cache).

• Database access = bypasses cache and adds overhead.

4️⃣ Maximum size for Text values 2000 characters.

5️⃣ Why not Structure or Entity? Designed for simple system-wide settings. 👉 Workaround: use Serialization / Deserialization to store more complex data as text, but only when really necessary.

6️⃣ Cross-module usage Yes, by exposing Server Actions for set/get and consuming them in other modules.

✅ Takeaway: Both Client Variables and Site Properties are optimized for simple values. As a developer, you should know their limitations and the workarounds available, but always use them with their intended purpose in mind.