09-20-2016, 12:12 PM
If I understand your requests correctly, you have read at least a part of our minds.
At the start of US5, I toyed with the idea of using a config table with Key/Value pairs like you describe (or as I understand you are describing them) and this is what Wordpress does. It also allows plugins to define their own config settings without an extra table. Now, we shouldn't use it "just because" Wordpress and others are using it, but I know that isn't your motivation anyway. At the start of US5, since there were a few other things I wanted to clean up, that idea got tossed by the wayside for a bit. But now, we have quite a few more options in the settings table, and a key/value lineup would work much nicer in some regards. On the other hand, running an ALTER query to add or modify a setting isn't the end of the work, but it is still a schema change in the end. @mudmin is doing another project with some intense table work, and is (maybe) now also really getting the idea and value of key/value pairs. The downside to this is that we would need to redo all the settings through the whole application. BUT, I don't consider that necessarily a downside, since it forces yet another review of the code. That being said, it also requires some planning upfront for key naming schemes, a get/set API type blocks of code, etc. It all boils down to "we still want to consider it, though there are quite a few things that stand in the way that we would need to commit to".
Again if I interpret you correctly about the forms, that was also an idea that I had. If the forms configuration could be stored in the database, with either some predefined snippets or classes or even just functions, then people could fully customize and store that form configuration in the DB, maybe with some JSON for each field, which contains validation requirements, limits, etc.
Do you think I understand at least those two points somewhat? If not, feel free to expand as needed.
At the start of US5, I toyed with the idea of using a config table with Key/Value pairs like you describe (or as I understand you are describing them) and this is what Wordpress does. It also allows plugins to define their own config settings without an extra table. Now, we shouldn't use it "just because" Wordpress and others are using it, but I know that isn't your motivation anyway. At the start of US5, since there were a few other things I wanted to clean up, that idea got tossed by the wayside for a bit. But now, we have quite a few more options in the settings table, and a key/value lineup would work much nicer in some regards. On the other hand, running an ALTER query to add or modify a setting isn't the end of the work, but it is still a schema change in the end. @mudmin is doing another project with some intense table work, and is (maybe) now also really getting the idea and value of key/value pairs. The downside to this is that we would need to redo all the settings through the whole application. BUT, I don't consider that necessarily a downside, since it forces yet another review of the code. That being said, it also requires some planning upfront for key naming schemes, a get/set API type blocks of code, etc. It all boils down to "we still want to consider it, though there are quite a few things that stand in the way that we would need to commit to".
Again if I interpret you correctly about the forms, that was also an idea that I had. If the forms configuration could be stored in the database, with either some predefined snippets or classes or even just functions, then people could fully customize and store that form configuration in the DB, maybe with some JSON for each field, which contains validation requirements, limits, etc.
Do you think I understand at least those two points somewhat? If not, feel free to expand as needed.