Here is an updated set of instructions for producing and revising code for your project. The specific references to the three models are removed, but all the general strict requirements are retained to ensure consistency, modularity, and accuracy across the project.
General Instructions for Producing and Revising Code in This Modularized Django Project
1. Carefully Analyze Existing Models and Project Structure
Before producing or revising any code, analyze the project's modular structure:
teaching/models.py
assessment/models.py
learning/models.py
common/models.py
school/models.py
Fully understand the patterns and conventions used within each models.py file:
Naming conventions for models, fields, and relationships.
Inheritance patterns (e.g., use of TimeStampedModel or other base models).
Soft deletion patterns (is_active field and soft_delete() method).
Change tracking with HistoricalRecords().
Meta options like verbose_name, verbose_name_plural, indexes, and permissions.
2. Ensure Modular Placement of Code
Place models in the correct models.py file based on their role:
Teaching-related models should go in teaching/models.py.
Assessment-related models should go in assessment/models.py.
Learning objectives and related models should go in learning/models.py.
Common models that may be shared across different apps should go in common/models.py.
School-related models should go in school/models.py.
Cross-reference models between apps: Ensure relationships (e.g., ForeignKey, ManyToManyField) reference models accurately across the different apps.
3. Update admin.py for Each App
For every new model or model revision, ensure the corresponding admin.py file is updated for that app:
Example: If a model is added to teaching/models.py, update teaching/admin.py to register the model with Django Admin.
Follow the same registration patterns used in the existing admin.py files, ensuring proper admin management of models.
Example:
from django.contrib import admin
from .models import YourModelName
admin.site.register(YourModelName)
4. Follow Programming Patterns and Precedents from Existing Models
All new models and revisions must follow the exact naming conventions, relationships, and field types already used in the corresponding app.
Maintain consistent style and structure for fields (e.g., blank=True, null=True, default values).
Ensure that ForeignKey and ManyToManyField relationships use appropriate related_name and on_delete behavior based on existing models.
5. Soft Deletion and Historical Records
Soft deletion:
If a model requires soft deletion, include is_active = models.BooleanField(default=True) to indicate whether the record is active.
Add a soft_delete() method to set is_active to False without actually deleting the record.
Historical Records:
If change tracking is used in the app, ensure that new or revised models include HistoricalRecords() for auditing purposes.
Use the existing setup for change history as seen in other models.
6. Meta Class: Internationalization, Auto-Documentation, and Optimization
Internationalization (i18n):
Wrap all translatable text (e.g., verbose_name, help_text) in gettext_lazy to provide future translation capabilities.
Example:
from django.utils.translation import gettext_lazy as _
name = models.CharField(max_length=255, verbose_name=_('Model Name'), help_text=_('Description of the model.'))
Auto-Documentation:
Add docstrings to models, fields, and methods to provide clarity for auto-generated documentation (e.g., using Django Rest Framework or Sphinx).
Ensure fields have meaningful help_text for documentation and admin clarity.
Indexes and Permissions:
Add indexes for fields that will be frequently queried (e.g., is_active, course, department):
models.Index(fields=['field_name'])
Include appropriate permissions for role-based access control, ensuring that permissions match existing patterns across the project:
permissions = [
("manage_model_name", "Can manage model name"),
]
7. Inheritance and Abstract Models
When multiple models share the same fields or methods, consider creating an abstract base class to reduce redundancy.
Use abstract = True in the Meta class to ensure the base model itself does not create a database table:
class AbstractModel(TimeStampedModel):
class Meta:
abstract = True
8. Field Defaults for Migrations
Always provide default values for new fields to ensure migration safety:
For text fields, use the verbose name as a reasonable default to prevent migration errors:
default='Field Verbose Name'
9. Handle Hierarchies with Parent-Child Relationships
For models requiring hierarchical relationships, use self-referencing foreign keys with optional relationships:
Ensure the hierarchical structure is flexible and optional, unless explicitly required.
10. Avoid Redundancy and Unnecessary Fields
Do not introduce redundant models or fields unless absolutely necessary:
For example, if Department already handles subject domains, avoid creating a new Subject model unless explicitly required.
Avoid unnecessary complexity: If the user has a simpler method of managing data, do not introduce over-engineered solutions.
11. Cross-Check and Update All Related Files
Cross-check and update all files that reference the models, including:
models.py in other apps, to ensure correct relationships.
admin.py, to ensure models are registered properly for Django Admin.
forms.py, serializers.py, and views.py, if models are referenced in forms or APIs.
Ensure that all files are accurately updated to reflect changes made in the models, ensuring no references are left out.
12. Clarify with the User When in Doubt
Seek clarification from the user if there is any ambiguity regarding the model structure, placement, or any other aspect of the project.
Be explicit in asking about:
Expected inheritance patterns.
Field behavior, especially defaults or constraints.
Which app models belong to and any future plans for migration between apps.
13. Test Migrations and Model Behavior
Run migrations locally after creating or modifying models to ensure that they proceed without errors.
Check the model’s behavior in Django Admin or the application to validate that all relationships, fields, and methods behave as expected.
This comprehensive set of instructions ensures that all code created or revised for this project follows the established modular structure, adheres to existing conventions, and provides clarity for future development. Let me know if there are any further refinements needed!
Here is an updated set of instructions for producing and revising code for your project. The specific references to the three models are removed, but all the general strict requirements are retained to ensure consistency, modularity, and accuracy across the project.
General Instructions for Producing and Revising Code in This Modularized Django Project
1. Carefully Analyze Existing Models and Project Structure
Before producing or revising any code, analyze the project's modular structure:
teaching/models.py
assessment/models.py
learning/models.py
common/models.py
school/models.py
Fully understand the patterns and conventions used within each
models.py
file:TimeStampedModel
or other base models).is_active
field andsoft_delete()
method).HistoricalRecords()
.verbose_name
,verbose_name_plural
,indexes
, andpermissions
.2. Ensure Modular Placement of Code
Place models in the correct
models.py
file based on their role:teaching/models.py
.assessment/models.py
.learning/models.py
.common/models.py
.school/models.py
.Cross-reference models between apps: Ensure relationships (e.g.,
ForeignKey
,ManyToManyField
) reference models accurately across the different apps.3. Update
admin.py
for Each AppFor every new model or model revision, ensure the corresponding
admin.py
file is updated for that app:teaching/models.py
, updateteaching/admin.py
to register the model with Django Admin.admin.py
files, ensuring proper admin management of models.Example:
4. Follow Programming Patterns and Precedents from Existing Models
blank=True
,null=True
, default values).related_name
andon_delete
behavior based on existing models.5. Soft Deletion and Historical Records
Soft deletion:
is_active = models.BooleanField(default=True)
to indicate whether the record is active.soft_delete()
method to setis_active
toFalse
without actually deleting the record.Historical Records:
HistoricalRecords()
for auditing purposes.6. Meta Class: Internationalization, Auto-Documentation, and Optimization
Internationalization (i18n):
verbose_name
,help_text
) ingettext_lazy
to provide future translation capabilities.Example:
Auto-Documentation:
help_text
for documentation and admin clarity.Indexes and Permissions:
is_active
,course
,department
):7. Inheritance and Abstract Models
abstract = True
in theMeta
class to ensure the base model itself does not create a database table:8. Field Defaults for Migrations
9. Handle Hierarchies with Parent-Child Relationships
For models requiring hierarchical relationships, use self-referencing foreign keys with optional relationships:
Ensure the hierarchical structure is flexible and optional, unless explicitly required.
10. Avoid Redundancy and Unnecessary Fields
Do not introduce redundant models or fields unless absolutely necessary:
Department
already handles subject domains, avoid creating a newSubject
model unless explicitly required.Avoid unnecessary complexity: If the user has a simpler method of managing data, do not introduce over-engineered solutions.
11. Cross-Check and Update All Related Files
Cross-check and update all files that reference the models, including:
Ensure that all files are accurately updated to reflect changes made in the models, ensuring no references are left out.
12. Clarify with the User When in Doubt
13. Test Migrations and Model Behavior
This comprehensive set of instructions ensures that all code created or revised for this project follows the established modular structure, adheres to existing conventions, and provides clarity for future development. Let me know if there are any further refinements needed!