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)
Top comments (0)