Poppy Framework

website·Indexed 31 days ago

https://weiran.tech/

A modular development framework based on Laravel. It provides tools for module-based architecture, including built-in support for permissions, menus, API documentation generation, and extensions for Aliyun OSS, Alipay, and webhooks. The framework includes versions 1.x and 4.x, with recent updates migrating from Laravel 6 to Laravel 10.

Tokens
68.9K
Snippets
406
Records
500
Agent score
52%

What's inside Poppy

  1. Project directory structure overview

    The project follows a modular directory structure. Key directories include:

    • config: Configuration files
    • modules: Business modules (e.g., finance, order, system)
    • public: Publicly accessible assets, including docs (documentation), modules (module resources), and resources (CSS, JS, SCSS)
    • resources: Source assets, including assets, docs, and lang (localization for en, zh)
    • storage: Application storage, including app, bootstrap, clockwork (debug files), framework (cache, sessions, views), and logs
    • tests: Test suites for MerchantApi and WebApi
    • vendor: Third-party dependencies
  2. Understand Poppy Framework module naming conventions

    The Poppy Framework divides projects into two types of modules. To distinguish between them, specific slug naming conventions are used: module.{module} for general modules and poppy.{poppy} for Poppy-specific core modules.
  3. Understand the Poppy Service and Hook system

    Services and Hooks in Poppy act as a 'slot and plug' mechanism for extensibility between modules. A service defines a slot, and hooks act as plugs that can be inserted into those slots. Multiple hooks can be attached to a single service.

    • Service Definition Location: modules/{module}/configurations/services.yaml
    • Hook Definition Location: modules/{module}/configurations/hooks.yaml
  4. Poppy project directory structure overview

    The project follows a modular structure. Key directories include:

    • config: Configuration files.
    • modules: Business modules (e.g., finance, order, system).
    • public: Publicly accessible assets, including docs and module resources.
    • resources: Source files for assets, documentation, and translations (en/zh).
    • storage: Application storage, including framework cache, sessions, views, and logs.
    • tests: Test suites for MerchantApi and WebApi.
    • vendor: Third-party dependencies.
  5. Understand the Weiran Service and Hook architecture

    Services and Hooks in Weiran act as a 'slot and plug' system, enabling extensibility across multiple modules. A single service slot can be populated by multiple hook implementations. Each module defines its available service slots in a services.yaml file.
  6. Understand Weiran 1.x module types

    Weiran 1.x organizes functionality into three distinct module types to support modular development:

    1. Plugin Modules (插件模块): Official toolkits providing solutions for common data and system needs. These include:
      • core: Redis, permission management, and documentation generation.
      • system: RBAC permission system, API signature extensions, system configuration extensions, user management, and rapid list/form generation.
      • mgr-page: A backend management framework based on Layui supporting backend authentication and RBAC.
    2. Extension Modules (扩展模块): Service modules that provide functionality to plugins. They do not contain database services and are designed to be reusable across multiple different projects.
    3. Project Modules (项目模块): Modules developed specifically to support the unique business logic of a particular project.
  7. Understand the modular architecture of the 4.x framework

    The framework is designed for modular development and categorizes modules into three types:

    1. Plugin Modules (插件模块): Official toolkits providing solutions for common data needs. Examples include:
      • core: Redis, permission management, and document generation.
      • system: RBAC permission system, interface signature extensions, system configuration, user management, and rapid list/form generation.
      • mgr-page: A Layui-based backend management framework supporting backend authentication and RBAC.
      • aliyun-push: A plugin for Aliyun app push notifications.
    2. Extension Modules (扩展模块): Service modules that provide functionality to plugins without including database services; these are designed to be reusable across multiple projects.
    3. Project Modules (项目模块): Modules developed specifically to support the business logic of a particular project.
  8. Understand Weiran module naming conventions

    Modules in the Weiran framework are categorized into custom modules and official modules. They are distinguished by their slug prefixes: custom modules use module.{module} and official modules use weiran.{weiran}.
  9. Architecture and modules of the 3.x framework

    The project is organized into four modular groups to facilitate management and is installed via Composer. The modules include:

    • Framework: Supports modular development and provides common pre-built functions.
    • Core: Includes Redis encapsulation and standardized documentation tools/norms.
    • System: Provides RBAC user management, permission systems, interface signature extensions, password encryption extensions, and system configuration extensions.
    • Management (layui-base): A backend management framework based on jQuery/Layui and an interface request platform based on apidoc.
  10. Poppy Framework directory structure overview

    The Poppy Framework follows a structured directory layout to organize its core logic, console commands, and support files. Key directories include:

    • src/Application: Base controllers, events, jobs, and requests.
    • src/Classes: Core loaders, utility classes (Number, Resp), and common Traits.
    • src/Console: CLI command definitions and generators (stubs for controllers, models, migrations, etc.).
    • src/Database: Database integration and migrator logic.
    • src/Foundation: Application kernel and exception handling.
    • src/Helper: Utility helpers for arrays, cookies, environment, files, HTML, images, routing, and strings.
    • src/Http: Middleware and pagination logic.
    • src/Poppy: Logic for managing and loading Poppy modules.
    • src/Support: General support files and service providers.
    • resources: Language packs, stubs for code generation, and default Blade views.
    ├── config/poppy.php          # Configuration
    ├── src/Application            # Base controllers
    ├── src/Console/Commands       # CLI Commands
    ├── src/Console/Generators    # Code generators
    ├── src/Foundation            # Kernel & Exception handling
    ├── src/Helper                 # Utility helpers
    ├── src/Poppy                 # Module management
    └── resources/stubs           # Generation templates
  11. Understand the RBAC conceptual model

    Role-Based Access Control (RBAC) manages authorization by defining the relationship between three elements: Who, What, and How. Instead of assigning permissions directly to users, permissions are assigned to Roles, and Roles are then assigned to Users. This provides flexibility as role permissions can be updated independently of the users assigned to them.

    • Who: The subject or owner of the permission (e.g., User, Group, Role, Actor).
    • What: The target object or resource (e.g., Resource, Class).
    • How: The specific privilege or action (Positive or Negative authorization).
  12. Implement form validation in Poppy Framework

    Poppy supports validation via Request classes and fluent form rules. Validation rules can be defined in resource/lang/zh/validator.php or via the Rule class.
    // Using a Request class for validation
    $reqPwd = app(PamConfirmedPasswordRequest::class, [$request]);
    if ($Pam->setPassword($this->pam, $reqPwd['password'])) {
        return Resp::success('Success');
    }
    
    // Using fluent form rules
    $this->text('note', 'Name')->rules([
        Rule::string(),
        Rule::max(30),
    ]);
    $this->text('expired_hour', 'Login Validity')->rules([
        Rule::numeric(),
        Rule::between(3, 24),
    ])->help('Validity between 3-24 hours');