So finally I managed to migrate the function based views in the Django code to class based views. This has resulted in significant decrease in code repetition and the code is now much more readable and maintainable.
To start, I needed to create a class hierarchy. The base class in SimulationData which extracts the simulation model instance, reads the circuit files and processes them. The next layer is ListControlVariables that inherits SimulationData and extracts control files and their variables.
The class SimulationData is:
The methods of the class perform functions like retrieving the simulation model instance, getting the circuit schematic model instances, checking if there are errors in reading the circuit files, processing the simulation circuit files and updating the database.
A few are obvious like getting the simulation model instance or circuit files model instances. Some not so obvious. When the circuit schematics are processed, they are checked for errors. These errors are both errors like component not found, unmatching jump labels etc. Also, connectivity errors are found - broken branches, jumps next to nodes etc. This checking is done almost every time because the simulator uses the "component_objects" dictionary of Python objects to contain information about every component found in the circuit. This is essential because different types of components have different classes - example resistors have Resistor class while voltage sources have VoltageSource class. Every time a class is found, it is instantiated and added to component_objects. So component_objects is the key to processing circuit components. By having the process_circuit_schematics() method in the SimulationData class, it is available to all other classes that inherit it.
Another non-obvious class method in update_db(). The database contains every circuit component in its records. And the details include the cell position of the circuit component and the polarity if any. These can always change as a user can move the components around in the schematic spreadsheet. The update_db() method updates the information in the schematic with the database.
The SimulationData class is the base class as the above methods are needed for every simulation. The next layer in the class hierarchy is the control class which is called ListControlVariables class. This is because there may be some simulations that don't have control. However, to figure out how a control function works, the circuit files will need to be processed and this means control needs SimulationData. ListControlVariables is as below:
This class provides method to perform repeated tasks with respect to control files. Extracting the control file model instance. Providing a list of all special variables in the control file as context variables.
With these two classes implemented the amount of times the process circuit schematic code was written to get back the dictionary of component_objects or that of components_found has decreased. Moreover, with component_objects and component_founds class attributes rather than regular variables, the function call is much less cumbersome as compared to before.
The next blog post will describe how class based views for listing circuit items will be created.
To start, I needed to create a class hierarchy. The base class in SimulationData which extracts the simulation model instance, reads the circuit files and processes them. The next layer is ListControlVariables that inherits SimulationData and extracts control files and their variables.
The class SimulationData is:
The methods of the class perform functions like retrieving the simulation model instance, getting the circuit schematic model instances, checking if there are errors in reading the circuit files, processing the simulation circuit files and updating the database.
A few are obvious like getting the simulation model instance or circuit files model instances. Some not so obvious. When the circuit schematics are processed, they are checked for errors. These errors are both errors like component not found, unmatching jump labels etc. Also, connectivity errors are found - broken branches, jumps next to nodes etc. This checking is done almost every time because the simulator uses the "component_objects" dictionary of Python objects to contain information about every component found in the circuit. This is essential because different types of components have different classes - example resistors have Resistor class while voltage sources have VoltageSource class. Every time a class is found, it is instantiated and added to component_objects. So component_objects is the key to processing circuit components. By having the process_circuit_schematics() method in the SimulationData class, it is available to all other classes that inherit it.
Another non-obvious class method in update_db(). The database contains every circuit component in its records. And the details include the cell position of the circuit component and the polarity if any. These can always change as a user can move the components around in the schematic spreadsheet. The update_db() method updates the information in the schematic with the database.
The SimulationData class is the base class as the above methods are needed for every simulation. The next layer in the class hierarchy is the control class which is called ListControlVariables class. This is because there may be some simulations that don't have control. However, to figure out how a control function works, the circuit files will need to be processed and this means control needs SimulationData. ListControlVariables is as below:
This class provides method to perform repeated tasks with respect to control files. Extracting the control file model instance. Providing a list of all special variables in the control file as context variables.
With these two classes implemented the amount of times the process circuit schematic code was written to get back the dictionary of component_objects or that of components_found has decreased. Moreover, with component_objects and component_founds class attributes rather than regular variables, the function call is much less cumbersome as compared to before.
The next blog post will describe how class based views for listing circuit items will be created.
