IA-v2: Sidebar reshuffle + scenarios/ rename + Concepts + Embed topics

docs/web/concepts.md

@@ -0,0 +1,64 @@
+# Concepts
+
+A short mental model for how the Reveal SDK fits together. Read this once; the rest of the docs assume this vocabulary.
+
+## Two pieces: client and server
+
+The Reveal SDK is split between a **client SDK** that runs in the browser and a **server SDK** that runs in your backend.
+
+| Piece | Runs in | Job |
+|---|---|---|
+| Client SDK | The browser, inside your web app | Renders the `RevealView` component, handles user interactions, sends data and dashboard requests to the server |
+| Server SDK | Your backend (ASP.NET, Node.js, NestJS, Spring Boot) | Stores and serves dashboards, answers data queries, holds connection credentials |
+
+The client never talks to your data sources directly. It always goes through the server SDK, which is where credentials and connection strings live. This is what makes embedded analytics secure — sensitive details never reach the browser.
+
+## Dashboards as files
+
+A Reveal dashboard is a **`.rdash` file**. It's a binary container that holds the dashboard's layout, visualizations, filters, and references to data sources. Dashboards are typically saved on the server and loaded into the `RevealView` on demand.
+
+By convention, the server SDK looks for `.rdash` files in a folder named `Dashboards` in the working directory. You can override that convention by implementing a custom dashboard provider (see below).
+
+## The provider pattern
+
+The server SDK is configured by implementing a small set of **provider interfaces**. Each provider gives you a hook into one part of the SDK's behavior:
+
+| Provider | What it controls |
+|---|---|
+| **`IRVDashboardProvider`** | Where dashboards are loaded from and saved to (file system, database, blob storage, etc.) |
+| **`IRVDataSourceProvider`** | The connection details for each data source (host, database, table, schema) — mutated per request based on user context |
+| **`IRVAuthenticationProvider`** | The credentials used when connecting to a data source (username/password, token, key pair) |
+| **`IRVUserContextProvider`** | The current user's identity and metadata, available to the other providers |
+
+Most embedded scenarios involve customizing one or more of these. For example: serving different dashboards to different tenants combines a custom `IRVDashboardProvider` (to scope dashboards by tenant) with a custom `IRVUserContextProvider` (to identify the tenant from the request). End-to-end multi-provider patterns will live under the upcoming **Solutions & Advanced Guides** section.
+
+## How a request flows
+
+A typical request from the moment a user opens a dashboard:
+
+1. **Client** — your app instantiates a `RevealView`, calls `RVDashboard.loadDashboard("Sales")`.
+2. **Network** — the client sends an HTTP request to the server SDK.
+3. **Server** — `IRVUserContextProvider.GetUserContext` runs to identify the user.
+4. **Server** — `IRVDashboardProvider.GetDashboardAsync` runs to retrieve the `.rdash` file (from disk, database, wherever you've configured).
+5. **Server** — the dashboard is sent back to the client.
+6. **Client** — `RevealView` renders the dashboard.
+
+When a visualization needs data:
+
+7. **Client** — sends a query request to the server.
+8. **Server** — `IRVDataSourceProvider.ChangeDataSourceAsync` runs to mutate connection details (e.g., swap in the tenant-specific database).
+9. **Server** — `IRVAuthenticationProvider.ResolveCredentialsAsync` runs to attach credentials.
+10. **Server** — query executes against the data source; results return to the client.
+
+Most of the SDK's customization surface boils down to overriding behavior in one of these provider methods.
+
+## Dashboard editing
+
+Dashboards can be **viewed**, **edited**, and **created** by end-users — not just embedded as static reports. The `RevealView` includes a built-in editor that supports adding visualizations, configuring filters, and reorganizing layout. Whether your end-users see the editor (and what they can do in it) is controlled by properties on the `RevealView`. See [Common Patterns](scenarios/index.md) for typical configurations.
+
+## Where to go next
+
+- Install: [Installation](install-server-sdk.md)
+- See it work: [Embed a Dashboard](embedding/dashboard.md)
+- Show one chart inline: [Embed a Single Visualization](embedding/single-visualization.md)
+- Wire it to your data: [Connect Data](datasources.md)

docs/web/editor-events.md

@@ -2,7 +2,7 @@
 
 The Visualization Editor exposes four lifecycle events you can hook into to run code before or after the editor opens or closes. Each event is paired below with a realistic example beyond the basic signature.
 
-For property-level customization (`canX` / `showX` toggles for menu items and buttons), see [Common Patterns](customizing/index.md). For the full property surface, see the [`RevealView` API reference](https://help.revealbi.io/api/javascript/latest/classes/RevealView.html).
+For property-level customization (`canX` / `showX` toggles for menu items and buttons), see [Common Patterns](scenarios/index.md). For the full property surface, see the [`RevealView` API reference](https://help.revealbi.io/api/javascript/latest/classes/RevealView.html).
 
 ## onVisualizationEditorOpening
 

docs/web/embedding/dashboard.md

@@ -0,0 +1,77 @@
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+
+# Embed a Dashboard
+
+The most common Reveal embed: drop a full dashboard into your app, with all of its visualizations, filters, and interactions. Three lines of client-side code plus a `.rdash` file on your server.
+
+## Before you start
+
+- The Reveal **Server SDK** must be installed and running. See [Install Server SDK](../install-server-sdk.md).
+- The Reveal **Client SDK** must be installed in your web app. See [Install Client SDK](../install-client-sdk.md).
+- A `.rdash` file must be available to the server. By default, the server looks for it in a folder named `Dashboards` in the working directory.
+
+If any of those is unfamiliar, read [Concepts](../concepts.md) first — it explains the client/server split and where dashboards live.
+
+## Minimum code
+
+In your HTML, add a `<div>` to host the `RevealView`:
+
+```html
+<div id="revealView" style="height: 800px; width: 100%;"></div>
+```
+
+In JavaScript, point the SDK at your server, load the dashboard by name, and assign it to a new `RevealView`:
+
+```js
+RevealSdkSettings.setBaseUrl("https://localhost:5111/");
+
+RVDashboard.loadDashboard("Sales").then(dashboard => {
+    const revealView = new RevealView("#revealView");
+    revealView.dashboard = dashboard;
+});
+```
+
+That's the entire embed. The dashboard renders with full editing, filtering, and export enabled by default.
+
+`RevealSdkSettings.setBaseUrl` only needs to be called once per page. Skip it if your client and server are served from the same origin.
+
+## Variations
+
+### Start with a new, empty dashboard
+
+When you want users to author from scratch instead of opening an existing file, instantiate `RVDashboard` directly:
+
+```js
+const revealView = new RevealView("#revealView");
+revealView.dashboard = new RVDashboard();
+```
+
+The user gets an empty canvas with the **+ Visualization** button ready. For a kiosk-style flow that opens directly into the new-visualization picker, see [Editor on Load (Kiosk)](../scenarios/editor-on-load-kiosk.md).
+
+### Load from a JSON-serialized dashboard
+
+If your server stores dashboards as JSON (`.json`) instead of binary (`.rdash`), use `Dashboard.FromJsonString` (or the equivalent in your server stack) inside your `IRVDashboardProvider`. The client-side code is the same — `loadDashboard("Sales")` either way.
+
+:::caution
+
+Manipulating dashboard JSON directly can break the file's integrity. Treat the JSON as opaque unless you have a specific reason to inspect or modify it.
+
+:::
+
+### Load from an embedded resource
+
+Your server's `IRVDashboardProvider` can return a `.rdash` stream from anywhere — a file path, an embedded resource in your assembly, blob storage, a database. The client-side `loadDashboard` call doesn't change.
+
+For the full set of provider patterns (custom file paths, embedded resources, JSON, custom storage), see [Loading Dashboards](../loading-dashboards.md). *(Will move to a dedicated **Dashboard Provider** topic under Connect Data in an upcoming docs change.)*
+
+## What's next
+
+Most embeds need more than the default behavior. Pick the scenario closest to your goal:
+
+- [Read-only Embed](../scenarios/view-only-embed.md) — disable editing for view-only users.
+- [Custom Save Destination](../scenarios/custom-save-workflow.md) — route saves to your own REST endpoint instead of the server SDK's default.
+- [Locked-down Export Menu](../scenarios/locked-down-export.md) — hide specific export formats for compliance.
+- [Editor on Load (Kiosk)](../scenarios/editor-on-load-kiosk.md) — start in edit mode with the new-visualization picker open.
+
+Need to show just one chart instead of a full dashboard? See [Embed a Single Visualization](single-visualization.md).

docs/web/embedding/single-visualization.md

@@ -0,0 +1,104 @@
+# Embed a Single Visualization
+
+Show a single chart inline in your app — a KPI on a homepage, a sales chart in a product page, a metric in a sidebar. The Reveal SDK supports this directly: load a dashboard, pick the visualization you want, and the rest of the dashboard stays out of the way.
+
+## Before you start
+
+The setup is identical to embedding a full dashboard — server SDK installed, client SDK installed, a `.rdash` file on the server. See [Embed a Dashboard](dashboard.md) for the basics. The only difference is the two extra lines that pick a single visualization.
+
+## Two ways to do it
+
+| | Single Visualization Mode | Maximized Visualization |
+|---|---|---|
+| **What it does** | Locks the view to one chart. The dashboard menu and other visualizations are inaccessible. | Opens the dashboard zoomed in on one chart, but the user can navigate back to the full dashboard. |
+| **Use when** | You want a permanent single-chart embed (KPI tile, inline metric, kiosk). | You want a focused initial view but full dashboard navigation. |
+| **Property** | `revealView.singleVisualizationMode = true` | (no extra property — just set `maximizedVisualization`) |
+
+Both patterns use the same `maximizedVisualization` property to specify *which* visualization. Single Visualization Mode just adds the lock.
+
+## Single Visualization Mode (locked)
+
+Most common pattern for embedding a chart inline:
+
+```html
+<div id="revealView" style="height: 400px; width: 100%;"></div>
+```
+
+```js
+RVDashboard.loadDashboard("AllDivisions").then(dashboard => {
+    const revealView = new RevealView("#revealView");
+    revealView.singleVisualizationMode = true;
+    revealView.dashboard = dashboard;
+    revealView.maximizedVisualization = dashboard.visualizations.getByTitle("Sales");
+});
+```
+
+The user sees only the "Sales" visualization. Filters, the dashboard header, and other visualizations are hidden.
+
+![](../images/maximize-three_divisions_dashboard_maximized.png)
+
+## Maximized Visualization (with navigation)
+
+Same code, minus the `singleVisualizationMode` line:
+
+```js
+RVDashboard.loadDashboard("AllDivisions").then(dashboard => {
+    const revealView = new RevealView("#revealView");
+    revealView.dashboard = dashboard;
+    revealView.maximizedVisualization = dashboard.visualizations.getByTitle("Sales");
+});
+```
+
+The dashboard opens on the "Sales" visualization, but a back button lets the user expand to the full dashboard.
+
+## Variations
+
+### Switch which visualization is shown, dynamically
+
+In a single-page app where the user picks which chart to view (e.g., a button bar of departments), update `maximizedVisualization` on the existing `RevealView`:
+
+```html
+<section style="display:grid;grid-template-rows:30px auto;">
+    <section style="display:grid;grid-template-columns:auto auto auto;">
+        <button onclick="showVisualization('Sales')">Sales</button>
+        <button onclick="showVisualization('HR')">HR</button>
+        <button onclick="showVisualization('Marketing')">Marketing</button>
+    </section>
+    <div id="revealView" style="height:500px;"></div>
+</section>
+```
+
+```js
+let revealView;
+
+RVDashboard.loadDashboard("AllDivisions").then(dashboard => {
+    revealView = new RevealView("#revealView");
+    revealView.singleVisualizationMode = true;
+    revealView.dashboard = dashboard;
+    revealView.maximizedVisualization = dashboard.visualizations.getByTitle("Sales");
+});
+
+function showVisualization(title) {
+    revealView.maximizedVisualization = revealView.dashboard.visualizations.getByTitle(title);
+}
+```
+
+No reload, no flicker — the view swaps in place.
+
+### Pick the visualization by index instead of title
+
+If the visualization titles aren't stable, use the index:
+
+```js
+revealView.maximizedVisualization = dashboard.visualizations[0];
+```
+
+### Customize the chart's appearance
+
+The same property toggles that work on a full dashboard work here — for example, hiding the menu (`showMenu = false`) or specific export formats. See [Common Patterns](../scenarios/index.md).
+
+## What's next
+
+- [Embed a Dashboard](dashboard.md) — the full-dashboard alternative.
+- [Common Patterns](../scenarios/index.md) — customizations that apply to either embed mode (read-only, locked-down export, etc.).
+- [`RevealView` API reference](https://help.revealbi.io/api/javascript/latest/classes/RevealView.html) — full property and event surface.

docusaurus.config.ts

@@ -62,10 +62,10 @@ const config: Config = {
         { from: '/web/web-component-wrappers/reveal-view/loading-dashboards', to: '/web-components/reveal-view/loading-dashboards' },
         { from: '/web/web-component-wrappers/visualization-viewer', to: '/web-components/visualization-viewer' },
         { from: '/web/web-component-wrappers/visualization-viewer/options', to: '/web-components/visualization-viewer/options' },
-        // editing-dashboards.md replaced by scenario-driven Common Patterns under
-        // /web/customizing/* plus per-event examples in /web/editor-events. Old URL
-        // points at the Common Patterns overview as the most natural landing.
-        { from: '/web/editing-dashboards', to: '/web/customizing' },
+        // editing-dashboards.md replaced by scenario-driven Common Patterns
+        // plus per-event examples in /web/editor-events. Old URL points at the
+        // Common Patterns overview as the most natural landing.
+        { from: '/web/editing-dashboards', to: '/web/scenarios' },
       ],
     }],
   ],

i18n/ja/docusaurus-plugin-content-docs/current/web/concepts.md

@@ -0,0 +1,64 @@
+# Concepts
+
+A short mental model for how the Reveal SDK fits together. Read this once; the rest of the docs assume this vocabulary.
+
+## Two pieces: client and server
+
+The Reveal SDK is split between a **client SDK** that runs in the browser and a **server SDK** that runs in your backend.
+
+| Piece | Runs in | Job |
+|---|---|---|
+| Client SDK | The browser, inside your web app | Renders the `RevealView` component, handles user interactions, sends data and dashboard requests to the server |
+| Server SDK | Your backend (ASP.NET, Node.js, NestJS, Spring Boot) | Stores and serves dashboards, answers data queries, holds connection credentials |
+
+The client never talks to your data sources directly. It always goes through the server SDK, which is where credentials and connection strings live. This is what makes embedded analytics secure — sensitive details never reach the browser.
+
+## Dashboards as files
+
+A Reveal dashboard is a **`.rdash` file**. It's a binary container that holds the dashboard's layout, visualizations, filters, and references to data sources. Dashboards are typically saved on the server and loaded into the `RevealView` on demand.
+
+By convention, the server SDK looks for `.rdash` files in a folder named `Dashboards` in the working directory. You can override that convention by implementing a custom dashboard provider (see below).
+
+## The provider pattern
+
+The server SDK is configured by implementing a small set of **provider interfaces**. Each provider gives you a hook into one part of the SDK's behavior:
+
+| Provider | What it controls |
+|---|---|
+| **`IRVDashboardProvider`** | Where dashboards are loaded from and saved to (file system, database, blob storage, etc.) |
+| **`IRVDataSourceProvider`** | The connection details for each data source (host, database, table, schema) — mutated per request based on user context |
+| **`IRVAuthenticationProvider`** | The credentials used when connecting to a data source (username/password, token, key pair) |
+| **`IRVUserContextProvider`** | The current user's identity and metadata, available to the other providers |
+
+Most embedded scenarios involve customizing one or more of these. For example: serving different dashboards to different tenants combines a custom `IRVDashboardProvider` (to scope dashboards by tenant) with a custom `IRVUserContextProvider` (to identify the tenant from the request). End-to-end multi-provider patterns will live under the upcoming **Solutions & Advanced Guides** section.
+
+## How a request flows
+
+A typical request from the moment a user opens a dashboard:
+
+1. **Client** — your app instantiates a `RevealView`, calls `RVDashboard.loadDashboard("Sales")`.
+2. **Network** — the client sends an HTTP request to the server SDK.
+3. **Server** — `IRVUserContextProvider.GetUserContext` runs to identify the user.
+4. **Server** — `IRVDashboardProvider.GetDashboardAsync` runs to retrieve the `.rdash` file (from disk, database, wherever you've configured).
+5. **Server** — the dashboard is sent back to the client.
+6. **Client** — `RevealView` renders the dashboard.
+
+When a visualization needs data:
+
+7. **Client** — sends a query request to the server.
+8. **Server** — `IRVDataSourceProvider.ChangeDataSourceAsync` runs to mutate connection details (e.g., swap in the tenant-specific database).
+9. **Server** — `IRVAuthenticationProvider.ResolveCredentialsAsync` runs to attach credentials.
+10. **Server** — query executes against the data source; results return to the client.
+
+Most of the SDK's customization surface boils down to overriding behavior in one of these provider methods.
+
+## Dashboard editing
+
+Dashboards can be **viewed**, **edited**, and **created** by end-users — not just embedded as static reports. The `RevealView` includes a built-in editor that supports adding visualizations, configuring filters, and reorganizing layout. Whether your end-users see the editor (and what they can do in it) is controlled by properties on the `RevealView`. See [Common Patterns](scenarios/index.md) for typical configurations.
+
+## Where to go next
+
+- Install: [Installation](install-server-sdk.md)
+- See it work: [Embed a Dashboard](embedding/dashboard.md)
+- Show one chart inline: [Embed a Single Visualization](embedding/single-visualization.md)
+- Wire it to your data: [Connect Data](datasources.md)

i18n/ja/docusaurus-plugin-content-docs/current/web/editor-events.md

@@ -2,7 +2,7 @@
 
 The Visualization Editor exposes four lifecycle events you can hook into to run code before or after the editor opens or closes. Each event is paired below with a realistic example beyond the basic signature.
 
-For property-level customization (`canX` / `showX` toggles for menu items and buttons), see [Common Patterns](customizing/index.md). For the full property surface, see the [`RevealView` API reference](https://help.revealbi.io/api/javascript/latest/classes/RevealView.html).
+For property-level customization (`canX` / `showX` toggles for menu items and buttons), see [Common Patterns](scenarios/index.md). For the full property surface, see the [`RevealView` API reference](https://help.revealbi.io/api/javascript/latest/classes/RevealView.html).
 
 ## onVisualizationEditorOpening