What happens when a marks entry interface stops being fixed and becomes entirely data-driven?

The latest phase of the Teacher Assistant application explores building a scalable grades and report generation system using Rust, egui, and PostgreSQL.

Instead of treating marks entry as another CRUD screen, the implementation evolved into a fully data-driven interface capable of adapting dynamically based on the selected exam and subject configuration.

Key parts of the system include:

• Dynamic exam and subject management
• Runtime-generated marks grids
• Real-time total and percentage calculation
• State-driven UI synchronization
• Adaptive layouts for varying subject counts
• Bulk marks persistence using UPSERT-style workflows

One of the key implementation challenges was designing a marks interface capable of handling completely different subject structures without modifying the underlying UI layout.

The UI was no longer fixed — selecting a different exam could regenerate the entire marks grid at runtime.

The article explores:

• Relational database design for exams, subjects, and grades
• Trigger-based state synchronization inside egui
• Dynamic subject loading
• Scrollable adaptive marks grids
• Runtime-generated calculations and validations
• Preparing the foundation for future HTML/PDF report generation

The post also includes screenshots and a visual walkthrough of the adaptive marks interface.

👇Read the full implementation breakdown:
Designing Grades Panel

Feedback and suggestions are always welcome.🙂

— Manjusha (Techn0tz)