Nelze vybrat více než 25 témat Téma musí začínat písmenem nebo číslem, může obsahovat pomlčky („-“) a může být dlouhé až 35 znaků.

4.2KB

MVC Framework Skill

Purpose

Use this skill for MindVisionCode PHP framework architecture, routing, dispatching, controllers, actions, ViewModels, templates, and HTTP request/response flow.


Project Identity

This project is a small PHP MVC framework called MindVisionCode PHP.

It is intentionally inspired by a Classic ASP MVC framework style:

  • Central dispatcher
  • Controllers and actions
  • ViewModels
  • Repository classes
  • Simple validation
  • Database migrations
  • Small, readable files
  • Minimal dependencies

Do not turn this into Laravel, Symfony, Slim, CakePHP, or another large framework.


Request Flow

Browser
  → public/index.php
  → Request
  → Dispatcher
  → Router
  → Route
  → Controller
  → ViewModel/Repository/Service
  → View
  → Response

Project Structure

Preferred structure:

project-root/
  public/
    index.php
  src/
    Controller/
    Service/
    Repository/
    Entity/
    ValueObject/
    ViewModel/
    Http/
    Routing/
    Validation/
    Database/
    Migration/
  templates/
  config/
  tests/
  var/
    cache/
    logs/
  vendor/
  composer.json

Rules:

  • public/ is the web root.
  • Do not expose src/, config/, tests/, vendor/, .ai/, or .env files through the web server.
  • Put application code under src/.
  • Put generated cache/log files under var/ or another ignored runtime directory.
  • Keep secrets outside the web root.

Development Commands

Install dependencies:

composer install

Regenerate autoload files:

composer dump-autoload

Run local server:

php -S localhost:8000 -t public

Run basic tests:

php tests/run.php

Framework Coding Rules

  • Keep code simple and readable.
  • Prefer small classes.
  • Use typed properties and return types where practical.
  • Avoid hidden magic.
  • Do not add dependencies without a clear reason.
  • Preserve the framework style.
  • Explain any architectural changes.

Controller Rules

  • Keep controllers thin.
  • Validate request method and request shape at the boundary.
  • Do not put database query details directly in controllers when a repository or service is more appropriate.
  • Do not put template rendering logic inside business services.
  • Return or produce a response through the framework’s response mechanism.

ViewModel Rules

  • Use ViewModels to shape data for views.
  • Keep ViewModels simple and explicit.
  • Avoid passing raw database rows directly into complex templates when a ViewModel would make the template clearer.
  • Do not put database access inside ViewModels unless the existing project convention explicitly does that.

Templates and Views

Keep presentation separate from business logic.

Rules:

  • Do not query the database from templates.
  • Do not place business rules in templates.
  • Escape output by default.
  • Prefer simple view models or arrays passed into templates.
  • Use a template engine with automatic escaping only if it fits the project and does not make the framework unnecessarily large.

Plain PHP template example:

<h1><?= e($pageTitle) ?></h1>

<ul>
    <?php foreach ($users as $user): ?>
        <li><?= e($user->name()) ?></li>
    <?php endforeach; ?>
</ul>

HTTP and Web Application Rules

Rules:

  • Use the front controller pattern where appropriate.
  • Keep routing separate from business logic.
  • Validate request methods.
  • Use CSRF protection for state-changing forms.
  • Use proper HTTP status codes.
  • Redirect after successful POST to avoid duplicate form submission.
  • Do not trust headers such as X-Forwarded-For unless configured behind a trusted proxy.

Example POST guard:

if ($_SERVER['REQUEST_METHOD'] !== 'POST') {
    http_response_code(405);
    exit('Method Not Allowed');
}

Architecture Guardrail

When adding features, preserve the small-framework character:

  • Prefer explicit code over hidden convention.
  • Prefer simple routing over complex annotation systems.
  • Prefer plain PHP views unless a project decision says otherwise.
  • Prefer focused services and repositories over large framework abstractions.
  • Do not introduce a large package just to solve a small problem.

Powered by TurnKey Linux.