In my never ending attempt refactor Xmldoom, it is turning into a monster. Here is the layout I envision for the future.
Move Definition.py and Parser.py into a new Definition/ module. These two are so tied together anyway. Then create a Compile/ (or "Compiler"?) module that contains the contents of SQL.py split into SQL.py and Compile.py. We can then include a parser/generator for a now-imaginary XML format for the compiled code. I am also considering eliminating Config.py and putting the SQL config stuff in the new Compile/ module. This would open up the possibily for moving the backend specific config into loadable modules like in Output/. The only problem is where to move the API config stuff since it is needed by both Output/ and PyRE.py.
This would make the following structure:
Xmldoom/Definition/ # dealing with the XML database definition
Xmldoom/Definition/Parser.py # parsing the XML
Xmldoom/Definition/Definition.py # the abstract in-memory version
Xmldoom/Definition/__init__.py # connects the parser and definition
Xmldoom/Compiler/SQL.py # the SQL query building code
Xmldoom/Compiler/Compiler.py # turns a definition into our compiled format
Xmldoom/Compiler/Parser.py # XML parser for the XML compiled format
Xmldoom/Compiler/__init__.py # connects all the parts into simple functions
Xmldoom/Output/ # does code generation
Xmldoom/PyRE.py # runtime engine (maybe make into directory?)
This would break the the whole Xmldoom process into distinct packages in the source tree:
Definition --> Compiler --> PyRE
- or -
Definition --> Compiler --> Output
Each part would, of course, have its own internal process and interaction of its modules that may be non-linear. But the new design would have the advantage of organizing all the major parts into there distinctly linear relationship.
This code base slowly turning from a convoluted mess into a coding masterpeice!