I've started splitting the original HTMLPageCreator code into modules.
It took me some time because I wanted to get a clear picture of how the various modules could be desinged to be as reusable as possible, so that in the future if the need arises to create more tools the modules will already be flexible enough to cover any use.
So, while creating modules, I'm making no assumption about the tool that might be using each module (wether is a GUI app, a console app, or just some code run in the IDE with the debugger on).
Two Types of Tools
The general criteria I'm following right now is to keep in mind that there will be two main categories of tools:
tools working with the whole Archiv
tools targetting single resources
... therefore I try to keep modules separate by these criteria (at the cost of creating an extra module in the process).
So, all the functionality of the current HTMLPageCreator is going to be split into smaller modules, some of which deal with single resources, others with the whole Archiv.
CodeArchiv Module
I'm currently working on the CodeArchiv Module, which will handle scanning the Archiv and creating lists of all Categories, resources, etc. Basically, it works like it did before in the single app, but I'll be exposing more statistics about the Archiv, and also allow more ways to iterate through contents.
I also think it will be a good idea to expose some iterative procedures, which take a Procedure pointer as parameter; these would allow to invoke that Procedure at each iteration cycle of either
All Categories
All Resources
All Resources in the currently iterated Category
... which spares the tool the bother of having to manually iterate through them, and also ensures that internal code changes of the module will not affect the API functions.
Furthermore, iteration of resources should have an optional parameter to filter which resources to iterate through:
PB sources
PB include files
Foldered Resources (CodeInfo.txt)
By default (if no param is passed) all three will be iterated through and invoke the Procedure pointer of the parameter. But the user could specify to process only certain types (using flags).
This would simplify tasks like integrity checks on resources:
Header comments validation (all types)
Check syntax via compiler (only PB types)
... and so on. In real use, a tool could invoke a Procedure on every resource this way (more or less):
... and the tool's MyProc() will be invoked on every resource that is either a PB file or a PB include file. The module will also expose all required info about the hosting Category, paths, etc., via structured public vars.
Logger Module
I've noticed that you're working on the logger module. Cool. Keep me up to date with how its API is going to be used.
Any Proposals?
Right now I'm modularizing in an attemptative way, addressing problems as I face them; but the more I work on it, the more I get a clearer picture of the potentials that modularization opens up (but also the problems).
If you have any ideas and thoughts on how to maximize modules reusability, or some standard approaches to how the API should look like (consistency between modules would be a good thing), drop some comments here.
I'll also post here any significant updates, and when I have a clearer roadmap of the modularization process I'll create a Status Issue for it.
In the meanwhile, I'm jotting down notes and free thoughts in the MODULARIZATION_NOTES.md file.
I've started splitting the original HTMLPageCreator code into modules.
It took me some time because I wanted to get a clear picture of how the various modules could be desinged to be as reusable as possible, so that in the future if the need arises to create more tools the modules will already be flexible enough to cover any use.
So, while creating modules, I'm making no assumption about the tool that might be using each module (wether is a GUI app, a console app, or just some code run in the IDE with the debugger on).
Two Types of Tools
The general criteria I'm following right now is to keep in mind that there will be two main categories of tools:
... therefore I try to keep modules separate by these criteria (at the cost of creating an extra module in the process).
So, all the functionality of the current HTMLPageCreator is going to be split into smaller modules, some of which deal with single resources, others with the whole Archiv.
CodeArchiv Module
I'm currently working on the CodeArchiv Module, which will handle scanning the Archiv and creating lists of all Categories, resources, etc. Basically, it works like it did before in the single app, but I'll be exposing more statistics about the Archiv, and also allow more ways to iterate through contents.
I also think it will be a good idea to expose some iterative procedures, which take a Procedure pointer as parameter; these would allow to invoke that Procedure at each iteration cycle of either
... which spares the tool the bother of having to manually iterate through them, and also ensures that internal code changes of the module will not affect the API functions.
Furthermore, iteration of resources should have an optional parameter to filter which resources to iterate through:
CodeInfo.txt)By default (if no param is passed) all three will be iterated through and invoke the Procedure pointer of the parameter. But the user could specify to process only certain types (using flags).
This would simplify tasks like integrity checks on resources:
... and so on. In real use, a tool could invoke a Procedure on every resource this way (more or less):
... and the tool's
MyProc()will be invoked on every resource that is either a PB file or a PB include file. The module will also expose all required info about the hosting Category, paths, etc., via structured public vars.Logger Module
I've noticed that you're working on the logger module. Cool. Keep me up to date with how its API is going to be used.
Any Proposals?
Right now I'm modularizing in an attemptative way, addressing problems as I face them; but the more I work on it, the more I get a clearer picture of the potentials that modularization opens up (but also the problems).
If you have any ideas and thoughts on how to maximize modules reusability, or some standard approaches to how the API should look like (consistency between modules would be a good thing), drop some comments here.
I'll also post here any significant updates, and when I have a clearer roadmap of the modularization process I'll create a Status Issue for it.
In the meanwhile, I'm jotting down notes and free thoughts in the
MODULARIZATION_NOTES.mdfile.