diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..85e7c1d --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +/.idea/ diff --git a/LampacModuleDocumentation.md b/LampacModuleDocumentation.md new file mode 100644 index 0000000..8c9e04e --- /dev/null +++ b/LampacModuleDocumentation.md @@ -0,0 +1,120 @@ +# Lampac Online Module Architecture + +This document provides a generalized overview of the structure, initialization, and operation of an online module for the Lampac platform. It is based on the `Uaflix` module and is intended to serve as a template for creating new modules. + +## 1. File Structure + +A typical online module consists of the following key files: + +- **`manifest.json`**: The module's "passport". It tells the main application how to load and initialize the module. +- **`ModInit.cs`**: The module initializer. This code runs once when the module is loaded to set up initial configurations. +- **`OnlineApi.cs`**: The "bridge" to the main application. It allows the module to register itself as an available online source. +- **`Controller.cs`**: The "heart" of the module. It handles requests from the main application, fetches data from the external source, parses it, and returns the results. +- **`Models/`**: A directory containing data model classes used internally to structure information (e.g., `Movie`, `Result`). +- **`*.csproj`**: The C# project file that defines dependencies and build settings. + +## 2. Module Lifecycle + +The module's lifecycle can be broken down into three main stages: Initialization, Integration, and Operation. + +### 2.1. Initialization + +This is the first step where the module comes to life. + +```mermaid +sequenceDiagram + participant App as Main Application + participant Manifest as manifest.json + participant ModInit as ModInit.cs + + App->>Manifest: 1. Read manifest.json + Manifest-->>App: Return initspace: "ModuleName.ModInit" + App->>ModInit: 2. Invoke loaded() method + ModInit->>App: 3. Register module settings (name, display name, etc.) +``` + +1. **Read `manifest.json`**: On startup, the main application scans for modules and reads their `manifest.json` files. It looks for the `"initspace"` key to identify the initialization class. +2. **Invoke `loaded()`**: The application then calls the static `loaded()` method in the specified class (e.g., `ModInit.cs`). +3. **Register Module**: Inside `loaded()`, an `OnlinesSettings` object is created, defining the module's internal name, display name, and other parameters. This configuration is stored in a static variable, making it accessible to other parts of the module. + +### 2.2. Integration + +This stage makes the module visible to the user. + +```mermaid +sequenceDiagram + participant User + participant App as Main Application + participant Manifest as manifest.json + participant OnlineApi as OnlineApi.cs + participant ModInit as ModInit.cs + + User->>App: Clicks on a movie + App->>Manifest: 1. Read manifest.json for all modules + Manifest-->>App: Return online: "ModuleName.OnlineApi" + App->>OnlineApi: 2. Invoke Events() method with movie details + OnlineApi->>ModInit: 3. Check if module is enabled (init.enable) + ModInit-->>OnlineApi: Return 'true' + OnlineApi->>App: 4. Add module to list (displayname, url, plugin) + App->>User: Show module in the list of sources +``` + +1. **Read `manifest.json`**: When a user selects content, the application again reads `manifest.json`, this time looking for the `"online"` key to find the integration class (e.g., `OnlineApi.cs`). +2. **Invoke `Events()`**: The application calls the `Events()` method from the specified class, passing in details about the selected content. +3. **Check Status**: The `Events()` method checks if the module is enabled by accessing the settings object created during initialization (`ModInit.ModuleName.enable`). +4. **Add to List**: If enabled, the module adds its details (display name, request URL) to the list of available sources, which is then presented to the user. + +### 2.3. Operation (Controller Logic) + +This is the main workflow that executes when the user selects the module as a source. + +```mermaid +graph TD + A[Start: Request to /module-url] --> B{Is module enabled?}; + B -- No --> C[Forbid access]; + B -- Yes --> D{Search in cache}; + D -- Found --> E[Return cached result]; + D -- Not Found --> F[Search on external site]; + F --> G{Found movie on site?}; + G -- No --> H[Return empty result]; + G -- Yes --> I[Parse movie page]; + I --> J{Found iframe with player?}; + J -- No --> H; + J -- Yes --> K[Parse iframe content]; + K --> L["Extract stream links (.m3u8)"]; + L --> M[Extract subtitles]; + M --> N["Create response object (MovieTpl)"]; + N --> O[Save result to cache]; + O --> P[Return result as HTML/JSON]; +``` + +1. **Request & Validation**: The `Controller` receives an HTTP request at its designated URL (e.g., `/uaflix`). It first validates that the module is enabled. +2. **Caching**: It checks a local cache (`hybridCache`) for a previously saved result to avoid redundant work. +3. **External Search**: If no cached data exists, it performs a search on the external website. +4. **Parsing**: It parses the HTML of the search results and the movie page to find `