thats actually not a trival problem. On the one hand you have to handle a lot of cases in the frontend. I still havent handled all for this plugin. As you can see revision capability is still on the todo list. Then there also is the issue of saving the data and if its a wise idea to use the pluginstore or not. The topic is touched on in this thread:
I also wrote this plugin because I wanted to figure out if real tables can actually bring a big benefit. This whole dependency logic and the error checking in the backend with a rollback if its just a “dry” shot would not be possible using only the plugin store. I think its a trade off. For some use cases the pluginstore is enough. But I think to do more complex stuff there is no way around “real” tables. I also want to write a blogpost about this after i explored this a bit more. If we look at this in a more abstract way, what we want to do is this: We want to use discourse to collectively edit structured data. At the moment its really hard to “just add” a custom field to a post or topic, but I think it can be made easier. Another thing that I want to do is to rip out the composer editor completely and use the topic just for data entry. I dont know what will come of it, but here is some brainstorming:Why not create an OPEN SOURCE platform dedicated to open source drug discovery ? · Issue #581 · OpenSourceMalaria/OSM_To_Do_List · GitHub
Maybe these two types of plugins can also be combined like i explain in this github issue. So you enter data in topics that have no normal d-editor, but a specialized data entry editor and then you reference this data in topics that still have the d-editor. These other topics might also have some extra fields, like in this projects management plugin.
Take all off this with a grain of salt, as I havent had the time to properly try this out. I will create a write up about this when I am back from vacation 