Why the CS50W Wiki Project Stores Articles in an entries Folder Instead of Inside the Django App

[Rajeev Bagra]

When beginners first explore the CS50W Wiki project, one question often comes up:

Why are the Markdown article files stored in a separate entries/ folder instead of inside the encyclopedia/ Django app?

At first glance, it may feel slightly confusing.

The project structure usually looks something like this:

wiki/
│
├── encyclopedia/
├── entries/
├── wiki/
└── manage.py

And inside entries/ you might see:

Python.md
HTML.md
CSS.md
Git.md

So why are these article files separated from the app itself?

---

The Core Idea: Separate Logic from Data

The main reason is a very important software engineering principle:

Programs manipulate data,
but programs themselves are not the data.

In this project:

Folder	Responsibility
encyclopedia/	Application logic
entries/	Content/data
wiki/	Project configuration

The encyclopedia app contains:

• Django views
• URL routing
• templates
• helper functions
• Markdown rendering logic

Meanwhile, the entries folder simply stores article content.

Think of it like this:

Real World	Django Project
Library system	encyclopedia/
Books inside library	entries/

The system manages the content, but the content itself lives separately.

---

What Are the .md Files?

The files ending in .md are Markdown files.

Example:

# Python

Python is a programming language.

## Features

- Easy
- Powerful
- Popular

Markdown is a lightweight formatting language that is easier to write than raw HTML.

The Django app reads these files and converts them into HTML webpages dynamically.

So when a user visits:

/wiki/Python

the application loads:

entries/Python.md

and displays it in the browser.

---

Why This Structure Works Well for Learning

The CS50W project intentionally keeps things simple.

Instead of introducing databases immediately, it teaches beginners:

• file handling
• dynamic webpage rendering
• URL routing
• template rendering
• separation of concerns

Using Markdown files makes these ideas easier to understand.

---

But Could This Structure Become Confusing?

Yes — and this is actually an important architectural observation.

Imagine the project later grows:

wiki/
│
├── encyclopedia/
├── one_month_app/
├── entries/

Now questions arise:

• Which app owns the entries folder?
• Can multiple apps modify it?
• Is the folder shared infrastructure?
• Should each app maintain its own content separately?

This is why larger production systems usually evolve toward:

• app-specific storage
• dedicated content apps
• or databases like PostgreSQL/MySQL

---

A More Modular Alternative

Some developers prefer:

encyclopedia/
│
├── entries/
├── views.py
├── urls.py

This makes the app more self-contained and modular.

Others eventually move all content into databases entirely.

---

The Bigger Lesson

This small CS50W project quietly introduces a massive industry concept:

Separation of Concerns

Meaning:

Different parts of a system should have clearly separated responsibilities.

For example:

Responsibility	Location
Business logic	Python files
Content/data	Markdown/database
Presentation	Templates
Styling	CSS

This separation makes software:

• easier to maintain
• easier to debug
• easier to scale
• easier for teams to work on

---

Final Thought

Many beginners focus only on:

“How do I make the app work?”

But an important shift happens when you begin asking:

“Will this structure remain clean and scalable as the project grows?”

That is the moment you start thinking like a software engineer rather than just someone writing code.

[Author]

Posts