Design Philosophy

DALT.PHP is built on four core educational principles that guide every design decision. Understanding these principles helps you get the most out of the platform.

The Four Principles

1. Learn by Debugging

Traditional approach: "Here's how routing works. Now build a blog."

DALT.PHP approach: "Here's how routing works. Now fix these broken routes."

Debugging forces you to:

• Understand what the code SHOULD do
• Identify what it ACTUALLY does
• Figure out WHY it's broken
• Apply the correct fix

This multi-layered understanding is deeper than just copying working code.

Why it works:

• Mirrors real-world development (you'll debug more than you'll write from scratch)
• Creates memorable learning experiences (you remember bugs you fixed)
• Builds problem-solving skills (not just syntax memorization)
• Develops debugging intuition (recognizing patterns)

Example:

Instead of:

// Tutorial: "Add this route"
$router->get('/posts/create', 'posts/create.php');

You get:

// Challenge: "Why does /posts/create show the wrong page?"
$router->get('/posts/{id}', 'posts/show.php');
$router->get('/posts/create', 'posts/create.php'); // Never matches!

You must understand route order to fix it, not just copy code.

2. Transparency Over Abstraction

Production frameworks hide complexity:

// Laravel - magic methods, facades, service providers
Route::get('/posts', [PostController::class, 'index']);
Post::where('published', true)->get();

DALT.PHP shows how it works:

// DALT.PHP - explicit, readable, educational
$router->get('/posts', 'posts/index.php');
$db->query('SELECT * FROM posts WHERE published = 1')->get();

Why transparency matters:

• You see exactly what's happening (no magic)
• Framework source code is readable (learn by reading)
• Error messages are clear (no abstraction layers)
• Debugging is straightforward (follow the code)

Design decisions for transparency:

1. Raw SQL instead of ORM

   -- You write actual SQL
   SELECT * FROM users WHERE email = ?
   
   -- Not ORM abstractions
   User::where('email', $email)->first()

2. Explicit routing

   // Clear file paths
   $router->get('/posts', 'posts/index.php');
   
   // Not class-based controllers
   Route::get('/posts', [PostController::class, 'index']);

3. Simple middleware

   // Readable middleware check
   if (!($_SESSION['user'] ?? false)) {
       header('location: /');
       exit();
   }
   
   // Not middleware stacks with pipelines

4. No facades or magic methods

   // Explicit dependency injection
   $db = App::resolve(Database::class);
   
   // Not facades
   DB::table('users')->get()

3. Progressive Complexity

Challenges are ordered by difficulty, building on previous knowledge:

Challenge 1: Broken Routing (Easy)

• Concepts: Route order, route registration
• Bugs: 2 simple bugs
• Prerequisites: None
• Teaches: How routers match URLs

Challenge 2: Broken Middleware (Medium)

• Concepts: Request filtering, session checks
• Bugs: 2 logic bugs
• Prerequisites: Understanding routing
• Teaches: How middleware intercepts requests

Challenge 3: Broken Authentication (Easy)

• Concepts: Password hashing, verification
• Bugs: 1 critical bug
• Prerequisites: Understanding middleware
• Teaches: Why password_verify() matters

Challenge 4: Broken Database (Medium)

• Concepts: SQL injection, prepared statements
• Bugs: 2 security bugs
• Prerequisites: Understanding SQL basics
• Teaches: Why prepared statements are essential

Challenge 5: Broken Session (Medium)

• Concepts: Flash data, session lifecycle
• Bugs: 2 subtle bugs
• Prerequisites: All previous concepts
• Teaches: How sessions persist data

Why this order:

• Each challenge builds on previous knowledge
• Difficulty increases gradually
• Concepts are introduced when needed
• Final challenge integrates everything

Lesson structure:

1. Concept explanation - What is routing/middleware/auth?
2. How it works - Code examples and diagrams
3. Common bugs - What goes wrong and why
4. Challenge - Fix real bugs using your knowledge

4. Real-World Relevance

Every bug in DALT.PHP is based on real bugs developers encounter:

Broken Routing:

• ❌ Route order issues (specific after generic)
• ❌ Commented-out routes
• ✅ Real problem: Routes not matching as expected

Broken Middleware:

• ❌ Wrong session key checks
• ❌ Inverted CSRF logic
• ✅ Real problem: Auth bypass, CSRF failures

Broken Authentication:

• ❌ Plain text password comparison
• ❌ Using == instead of password_verify()
• ✅ Real problem: Login always fails

Broken Database:

• ❌ SQL injection vulnerabilities
• ❌ String concatenation in queries
• ✅ Real problem: Security holes, data corruption

Broken Session:

• ❌ Flash data not clearing
• ❌ Session not persisting
• ✅ Real problem: Messages showing multiple times

Why real bugs matter:

• You'll encounter these in actual projects
• Builds security awareness
• Teaches debugging patterns
• Prepares you for real work

Design Decisions Explained

Why PHP?

PHP is ideal for teaching backend fundamentals:

• Close to HTTP: $_GET, $_POST, $_SERVER are explicit
• Synchronous: No async/await complexity for beginners
• Ubiquitous: Powers 77% of websites
• Low barrier: No compilation, immediate feedback

See Why PHP? for detailed comparison.

Why SQLite?

SQLite is perfect for learning:

• Zero configuration: No server setup
• Single file: Easy to inspect and reset
• Real SQL: Same syntax as PostgreSQL
• Portable: Database travels with the code

Why Raw SQL?

No ORM abstractions because:

• Learn SQL: You need to know SQL for any backend work
• Understand queries: See exactly what's happening
• Debug easily: No ORM magic to decipher
• Security awareness: Learn prepared statements explicitly

// DALT.PHP - explicit and educational
$db->query('SELECT * FROM posts WHERE id = ?', [$id])->find();

// Laravel - convenient but hides SQL
Post::find($id);

Why No Models?

DALT.PHP doesn't have models because:

• Simplicity: One less concept to learn
• Transparency: Query directly, see results
• Focus: Learn backend concepts, not ORM patterns

You can add models later when building real apps.

Why Custom Framework?

Using a custom micro-framework instead of Laravel/Symfony because:

• Readable source: 200 lines vs 200,000 lines
• Understandable: No magic, no hidden behavior
• Educational: Designed for learning, not production
• Debuggable: Follow the code easily

Why Verification System?

Automated testing provides:

• Instant feedback: Know immediately if you're right
• Helpful hints: Guidance when stuck
• Progress tracking: See what you've completed
• Confidence: Verify your understanding

Without verification, you'd need to manually test every URL and guess if your fix is correct.

Why Hidden .dalt/ Directory?

The platform code is hidden because:

• Reduce cognitive load: Beginners don't need to see Vue/Vite
• Focus on backend: Learn PHP, not frontend tooling
• Clean workspace: Only see relevant files
• Progressive disclosure: Explore .dalt/ when curious

Educational Research Behind DALT.PHP

Active Learning

Research shows active learning (doing) beats passive learning (reading):

• 10% retention from reading
• 20% retention from watching videos
• 75% retention from practicing
• 90% retention from teaching/debugging

DALT.PHP uses active learning through debugging challenges.

Productive Struggle

Educational psychology shows that struggling (within reason) strengthens learning:

• Forces deep thinking
• Creates memorable experiences
• Builds problem-solving skills
• Develops persistence

DALT.PHP provides hints to keep struggle productive, not frustrating.

Spaced Practice

Challenges are spaced to improve retention:

• Challenge 1: Routing
• Challenge 2: Middleware (uses routing)
• Challenge 3: Auth (uses middleware)
• Challenge 4: Database (new concept)
• Challenge 5: Sessions (integrates everything)

This spacing helps move knowledge from short-term to long-term memory.

Immediate Feedback

Fast feedback loops accelerate learning:

• Run verification → Get results instantly
• See which tests pass/fail
• Read helpful hints
• Fix and try again

No waiting for instructor feedback or manual testing.

Comparison with Other Learning Approaches

Principles in Action

Example: Broken Routing Challenge

Principle 1 (Learn by Debugging):

• You don't just read about route order
• You fix actual broken routes
• You understand WHY order matters

Principle 2 (Transparency):

• Router source code is readable
• You can see how matchUri() works
• No magic route resolution

Principle 3 (Progressive Complexity):

• First challenge (easiest)
• Only 2 bugs to fix
• Builds foundation for middleware

Principle 4 (Real-World Relevance):

• Route order issues are common
• You'll encounter this in real projects
• Teaches debugging patterns

Next Steps

• Why PHP? - Detailed language choice rationale
• Architecture - How principles shape design
• Building a Blog - Start building with DALT.PHP