feat: Add README files for various modules and routes
This commit is contained in:
28
src/lib/ae_archives/README.md
Normal file
28
src/lib/ae_archives/README.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# Aether (AE) Archives Module
|
||||
|
||||
The Archives module is a system for storing and retrieving archived data. It is composed of two main data structures: `Archive` and `Archive_Content`.
|
||||
|
||||
## Data Structures
|
||||
|
||||
### Archive
|
||||
|
||||
An `Archive` is a container for a collection of `Archive_Content` items. It has a name, description, and other metadata.
|
||||
|
||||
### Archive Content
|
||||
|
||||
An `Archive_Content` item represents a single piece of content within an `Archive`. This can be text, a file, a URL, or other data.
|
||||
|
||||
## Functionality
|
||||
|
||||
This module provides the following functionality:
|
||||
|
||||
- **CRUD Operations:** Create, Read, Update, and Delete operations for both `Archive` and `Archive_Content` objects.
|
||||
- **Local Caching:** Uses Dexie.js to cache data in the browser's IndexedDB for offline access and faster load times.
|
||||
- **API Interaction:** All data operations are synced with the backend API.
|
||||
|
||||
## Files
|
||||
|
||||
- `ae_archives__archive.ts`: Contains functions for managing `Archive` objects.
|
||||
- `ae_archives__archive_content.ts`: Contains functions for managing `Archive_Content` objects.
|
||||
- `ae_archives_functions.ts`: Exports all the functions from the module for easy use in other parts of the application.
|
||||
- `db_archives.ts`: Defines the IndexedDB schema for the archives module using Dexie.js.
|
||||
28
src/lib/ae_posts/README.md
Normal file
28
src/lib/ae_posts/README.md
Normal file
@@ -0,0 +1,28 @@
|
||||
# Aether (AE) Posts Module
|
||||
|
||||
The Posts module provides functionality for creating and managing posts and their associated comments. This is suitable for features like a blog, forum, or bulletin board.
|
||||
|
||||
## Data Structures
|
||||
|
||||
### Post
|
||||
|
||||
A `Post` object represents a single entry, such as a blog post or a forum thread. It contains a title, content, and metadata about the author and topic.
|
||||
|
||||
### Post Comment
|
||||
|
||||
A `Post_Comment` object represents a comment made on a `Post`.
|
||||
|
||||
## Functionality
|
||||
|
||||
This module provides the following functionality:
|
||||
|
||||
- **CRUD Operations:** Create, Read, Update, and Delete operations for both `Post` and `Post_Comment` objects.
|
||||
- **Local Caching:** Uses Dexie.js to cache data in the browser's IndexedDB for offline access and faster load times.
|
||||
- **API Interaction:** All data operations are synced with the backend API.
|
||||
|
||||
## Files
|
||||
|
||||
- `ae_posts__post.ts`: Contains functions for managing `Post` objects.
|
||||
- `ae_posts__post_comment.ts`: Contains functions for managing `Post_Comment` objects.
|
||||
- `ae_posts_functions.ts`: Exports all the functions from the module for easy use in other parts of the application.
|
||||
- `db_posts.ts`: Defines the IndexedDB schema for the posts module using Dexie.js.
|
||||
27
src/lib/ae_sponsorships/README.md
Normal file
27
src/lib/ae_sponsorships/README.md
Normal file
@@ -0,0 +1,27 @@
|
||||
# Aether (AE) Sponsorships Module
|
||||
|
||||
The Sponsorships module is designed to manage event or project sponsorships. It includes data structures and functions for handling sponsorship configurations and individual sponsorship records.
|
||||
|
||||
## Data Structures
|
||||
|
||||
### Sponsorship Configuration (`Sponsorship_Cfg`)
|
||||
|
||||
This data structure defines the available sponsorship levels, options, and schedules for a particular event or account. It acts as a template for creating individual sponsorships.
|
||||
|
||||
### Sponsorship
|
||||
|
||||
This represents an actual sponsorship agreement with an organization or individual. It includes details about the sponsor, the selected level, payment amount, and other relevant information.
|
||||
|
||||
## Functionality
|
||||
|
||||
This module provides the following functionality:
|
||||
|
||||
- **Data Loading:** Functions to load sponsorship configurations and sponsorship records from the backend API.
|
||||
- **Data Export:** A function to download an export of sponsorship data in CSV or Excel format.
|
||||
- **Local Caching:** Uses Dexie.js to cache data in the browser's IndexedDB for offline access and faster load times.
|
||||
- **API Interaction:** All data operations are synced with the backend API.
|
||||
|
||||
## Files
|
||||
|
||||
- `ae_sponsorships_functions.ts`: Contains functions for loading and processing sponsorship data.
|
||||
- `db_sponsorships.ts`: Defines the IndexedDB schema for the sponsorships module using Dexie.js.
|
||||
48
src/lib/electron/README.md
Normal file
48
src/lib/electron/README.md
Normal file
@@ -0,0 +1,48 @@
|
||||
# Electron Integration (Events - Launcher)
|
||||
|
||||
This document describes the Electron integration for the Aether Svelte application, which provides native capabilities for the Events module, specifically for the **Event Launcher** functionality.
|
||||
|
||||
## Overview
|
||||
|
||||
The Event Launcher is not a standalone module but rather a set of native functions and UI elements integrated into the Events module. It is designed to be used in a hybrid event scenario where a local application (the Electron app) is used to control presentations and other event-related content on a local machine.
|
||||
|
||||
## Architecture
|
||||
|
||||
The Electron integration is composed of three main parts:
|
||||
|
||||
1. **Electron Main Process (`electron.js`):** The main process of the Electron application. It is responsible for creating the browser window and handling communication with the renderer process.
|
||||
2. **Native Functions (`src/lib/electron/electron_native.js`):** A set of functions that are executed in the Electron main process and have access to the operating system's native APIs. These functions provide the core functionality for the Event Launcher, such as opening files, running commands, and managing processes.
|
||||
3. **Relay/Bridge (`src/lib/electron/electron_relay.js`):** A bridge that exposes the native functions to the Svelte application running in the renderer process. This allows the Svelte components to call the native functions.
|
||||
|
||||
## Key Functionality
|
||||
|
||||
The native functions in `electron_native.js` provide the following key functionalities for the Event Launcher:
|
||||
|
||||
- **File Caching:**
|
||||
- `check_hash_file_cache()`: Checks if a file with a specific hash exists in the local cache.
|
||||
- `download_hash_file_to_cache()`: Downloads a file from the API and stores it in the local cache.
|
||||
- **File Operations:**
|
||||
- `open_hash_file_to_temp()`: Copies a file from the cache to a temporary directory and opens it.
|
||||
- `open_local_file()`: Opens a local file.
|
||||
- **Process Management:**
|
||||
- `kill_processes()`: Kills processes by name or ID. This is used to close presentation applications after a presentation is finished.
|
||||
- **Command Execution:**
|
||||
- `run_osascript()`: Runs an AppleScript command (macOS only).
|
||||
- `run_cmd()`: Runs a shell command.
|
||||
- **Device Information:**
|
||||
- `get_device_info()`: Gets information about the device, which can be used for logging and debugging.
|
||||
|
||||
## UI Integration
|
||||
|
||||
The Event Launcher functionality is integrated into the Events module's UI as follows:
|
||||
|
||||
- **Launcher Links:** In the list of event sessions, there are "launcher" links that, when clicked, trigger the native launcher functionality.
|
||||
- **Configuration:** The visibility and behavior of the launcher links are controlled by the `mod_pres_mgmt_json` configuration in the `Event` object. This allows for fine-grained control over the launcher functionality on a per-event basis.
|
||||
|
||||
## How it Works
|
||||
|
||||
1. The Svelte application, running in the Electron renderer process, displays a list of event sessions.
|
||||
2. For each session, a "launcher" link is displayed if the configuration allows it.
|
||||
3. When the user clicks on a launcher link, a function in `electron_relay.js` is called.
|
||||
4. The relay function then calls the corresponding native function in `electron_native.js` via the Electron context bridge.
|
||||
5. The native function performs the requested action, such as downloading a file, opening a presentation, or running a command.
|
||||
Reference in New Issue
Block a user