Mohammad,
I am doing something like this with a hack I discovered
Using plugin type infoWith a little more work or more hacking this could be very usable.
One reason I am keen to establish this process is it supports the development of a change and release process. You can install the first set of tiddlers as shadow tiddlers, make changes as needed and export the final result to release a new version. Always retaining the ability to fall back to the original tiddlers, and review which have changed (including differences?). This can occur across multiple wikis in time, not just in a single one.
My long term goal would be for example to install my design tools in each design project, enhancing those tools as I go, exporting the enhancements and using the enhanced package in the next project. Basically a process that supports continuous improvement each time I use the design tools in yet another project. Of importance here is they are enhanced as the result of real needs, identified in practical projects. However at the same time the design tools can be removed from the final product to reduce unnecessary bloat, and reduce complexity.
This workflow permits a cumulative design process. I have one project that is defining the functionality of fields and field-types and the ability to collect the "system or Generic" field definitions from each project, builds a library of field definitions over time.
- One observation already is shadow tiddlers are not necessarily seen as system tiddlers, so some list filters need to be improved to also look for the shadow tiddlers (inside the plugin bundle)
- I find having a checkbox on such tiddlers useful to indicate if they are required for the current wiki, and should not be removed on deletion of the plugin.
- An extra step is required to delete overwritten shadow tiddlers when removing the plugin (A feature we could add to the plugin mechanism)
Regards
Tony