Yes I see what you mean.
The concept of actionsgroup mta-files and metagroup mtg-files is just a vehicle not a fitting solution.
So what should it be?
- User can create a user defined action (UDA) by picking an action type out of the pool of predefined generic action types, then filling in the appropriate values, then storing this one UDA into a folder in the filesystem using a descriptive name (maybe somewhat automatically named).
One UDA --> one (ini-) file, e. g. file extension '.mta' (human readable).
UDA object has the methods: new UDA, delete UDA, rename UDA (*1).
- In order to perform a complex task the user can compose a set of UDA's by picking UDA's out of the pool of UDA's, then store this UDA-group list into a folder in the filesystem using a descriptive name.
One UDA-group --> one (ini-) file, e. g. file extension '.mtg' (human readable).
UDA-group object is an orderded list of UDA's and has the methods: new UDA-group, delete UDA-group, rename UDA-group (*2), insert UDA, delete UDA, (manually) order UDA entries in current UDA-group list.
- User can create more complex workflow by defining a meta UDA-group (similar to 'Utils' now) by picking UDA-group's out of the pool of UDA-groups.
An 'utils' meta UDA-group object is just an orderded list of UDA-groups and has the methods: new meta-UDA-group, delete meta-UDA-group, rename meta-UDA-group, insert UDA-group, delete UDA-group, (manually) order UDA-group entries in current meta-UDA-group list.
One meta-UDA-group --> one (ini-) file, e. g. file extension '.mtm' (human readable).
- To perform a quick action the application should offer three (sortable, searchable) picklists, each containing all known
- UDA's
- UDA-group's
- meta-UDA-group's.
(*1), (*2): Renaming causes a broken reference into the pointerlists on higher level. If an UDA resp. UDA-group has been renamed, then all references must be updated automatically within related UDA-group's resp. meta-UDA-group's.
DD.20090407.1144.CEST