How arya-221/hindi-olab works
1. Repository shape
- This is a small Django project named olab with one main app, eng.
- The app implements a “Clause Simulator” for grammar exercises, backed by template-rendered pages and text-file vocabularies rather than a heavy database model.
2. Two feature slices
- The application is split into two exercise flows:
- Independent clause identification
- Dependent clause identification
- Each flow has its own backend logic and its own set of templates, but both follow the same pattern: present a sentence, evaluate the learner’s choice, then show explanation/theory pages.
3. Django request boundary
- The main routing boundary is the Django URL configuration:
- Project routes live in olab/urls.py
- App routes live in eng/urls.py
- Requests enter through Django’s standard WSGI/ASGI entry points in olab/wsgi.py and olab/asgi.py.
4. Backend logic layer
- The core rule-based processing is in eng/views.py and eng/views2.py.
- These files act as the application’s “engine”: they likely assemble sentences, classify clauses, and decide which feedback page to show.
- The README refers to views1.py for the dependent-clause exercise, but the tree shows the actual file as views2.py.
5. Lexicon/rule data layer
- The app relies heavily on many plain-text word lists under eng/.
- These files store categorized vocabulary such as names, verbs, places, food words, playing/watching/drinking/cooking words, days, groups, etc.
- This means the architecture is closer to a dictionary-driven parser/rule matcher than a database-backed content system.
6. Exercise-specific data sets
- For the independent-clause exercise, the backend uses files like:
- names.txt, verbs.txt, places.txt, days.txt, group.txt
- plus semantic sets like drinkable.txt, eatable.txt, playable.txt, watchable.txt, cookable.txt
- For the dependent-clause exercise, it uses files such as:
- names1.txt, names2.txt, verb1.txt, verb2.txt, verb3.txt
- food1.txt, hungry.txt, places1.txt, class.txt, books.txt
7. Template/presentation layer
- The UI is template-driven using Django HTML templates in templates/.
- Independent-clause screens: ex1.html, next.html, explanation.html, theory.html
- Dependent-clause screens: ex2.html, next2.html, explanation2.html, theory2.html
- This suggests a staged user journey: exercise input/result page → explanation page → theory/reference page.
8. Static assets
- Frontend styling is minimal and centralized in static/css/style.css.
- There is also an image asset under static/images/ for the tab icon, indicating a lightweight presentation layer with no complex frontend framework.
9. Data persistence
- The repository includes db.sqlite3, but the architecture does not appear to depend on rich relational persistence for the learning logic.
- The dominant “content store” is the collection of text files; SQLite is likely just the default Django database and may be used lightly or not at all for the core exercises.
10. Supporting Django app structure
- eng/models.py, admin.py, apps.py, and migrations/ are present, but the repo’s main behavior is driven by view logic and text resources rather than model-centric workflows.
- eng/tests.py exists for automated checks, though the repository appears oriented more toward instructional/demo behavior than a large test suite.
11. Core data flow
- A learner hits an exercise route.
- Django routes the request to the relevant view in eng.
- The view reads one or more word-list files, constructs or evaluates a clause/sentence, and renders a template.
- The user sees feedback and explanation pages, with the theory pages acting as static instructional content.
12. Architectural character
- Overall, this is a rule-based educational web application built with Django.
- The main architectural boundary is between:
- presentation: HTML templates + CSS
- logic: view functions
- content/rules: text-based lexical lists
- It is not a microservice system and not a data-heavy CRUD app; it is a compact, server-rendered teaching tool.
Main entry points: views2.py Clause engine 2 · views.py Clause engine · urls.py App URLs · ex1.html Exercise 1
Components 21
Django project
Framework entry points and root routing.
- ASGI entry · Async deployment entry for the Django project.
olab/asgi.py - WSGI entry · Sync deployment entry for the Django project.
olab/wsgi.py - Project URLs · Root URL configuration for the site.
olab/urls.py
eng app
Exercise routing, view logic, and optional model/admin scaffolding.
- App URLs · Routes exercise requests into the eng app.
eng/urls.py - Clause engine · Rule-based logic for independent clause identification.
eng/views.py - Clause engine 2 · Rule-based logic for dependent clause identification.
eng/views2.py - Dependent helpers · Additional dependent-clause support logic.
eng/dependent.py - Models · Present but not central to the exercise logic.
eng/models.py - Admin · Admin registration layer for the app.
eng/admin.py
Templates
Server-rendered pages for the two clause flows.
- Exercise 1 · Independent-clause exercise page.
templates/ex1.html - Feedback 1 · Independent-clause result/next page.
templates/next.html - Explain 1 · Independent-clause explanation page.
templates/explanation.html - Theory 1 · Independent-clause theory/reference page.
templates/theory.html - Exercise 2 · Dependent-clause exercise page.
templates/ex2.html - Feedback 2 · Dependent-clause result/next page.
templates/next2.html - Explain 2 · Dependent-clause explanation page.
templates/explanation2.html - Theory 2 · Dependent-clause theory/reference page.
templates/theory2.html
Static assets
Minimal CSS and image assets.
- Stylesheet · Central styling for the server-rendered UI.
static/css/style.css - Tab icon · Small image asset used by the site.
static/images/tab_icon_image
Text vocab
Dictionary-like word lists and rule inputs used by the exercises.
- Independent lexicon · Word lists used to generate and evaluate independent clauses.
- Dependent lexicon · Word lists used to generate and evaluate dependent clauses.
Connections 21
- ASGI entry → Project URLs: serve app · ASGI requests reach the Django URL layer.
- WSGI entry → Project URLs: serve app · WSGI requests reach the Django URL layer.
- Project URLs → App URLs: include · Project routes delegate exercise paths to the app.
- App URLs → Clause engine: route · Independent-clause endpoints resolve to the main view module.
- App URLs → Clause engine 2: route · Dependent-clause endpoints resolve to the second view module.
- Clause engine → Independent lexicon: read · Independent exercise logic consumes text-based vocabularies.
- Clause engine 2 → Dependent lexicon: read · Dependent exercise logic consumes text-based vocabularies.
- Clause engine 2 → Dependent helpers: use · Dependent flow shares helper logic with the support module.
- Clause engine → Exercise 1: render · Independent exercise page is rendered by the view layer.
- Clause engine → Feedback 1: render · Independent feedback/next page is rendered by the view layer.
- Clause engine → Explain 1: render · Independent explanation page is rendered after evaluation.
- Clause engine → Theory 1: render · Independent theory page is part of the learning flow.
- Clause engine 2 → Exercise 2: render · Dependent exercise page is rendered by the view layer.
- Clause engine 2 → Feedback 2: render · Dependent feedback/next page is rendered by the view layer.
- Clause engine 2 → Explain 2: render · Dependent explanation page is rendered after evaluation.
- Clause engine 2 → Theory 2: render · Dependent theory page is part of the learning flow.
- Exercise 1 → Stylesheet: style · Templates use the shared stylesheet.
- Exercise 2 → Stylesheet: style · Templates use the shared stylesheet.
- Exercise 1 → Tab icon: asset · The UI references the tab icon image.
- Exercise 2 → Tab icon: asset · The UI references the tab icon image.
- Admin → Models: register · Admin scaffolding is attached to the model layer.