Reset command for content plugins (MRT improvement)

[MVV]

There are a lot of recent suggestions to improve MRT counters. It is impossible to put them all into single MRT. I have a quite-easy-to-realize idea. Currently WDX plugins can't be used for MRT counters because they don't know when they should start to count or reset counter when TC creates list of resulting names in MRT or updates it.

Idea is to request special 'ResetCounters' content field from every WDX plugin (that report supporting of such feature via ContentGetSupportedField) before updating MRT filenames list or before starting rename operation. This field shouldn't return any result but every plugin on such field request should reset its internal state so its normal fields would produce same value sequences after each reset.

Such feature would allow creating absolutely any kind of counters for MRT: cyclic, per-folder dependent, incremented by N every M files, with numbers (including exact bands), letters, words, counting from '10' to '15, counting from 'x' to 'z', etc etc etc. Every plugin counter may provide large number of positions (using units '0', '1', '2', '3' etc) so it will be possible to increment next position value on overflow (e.g. you could use [=myplug.counter2.1][=myplug.counter1.0] where counter1 counts from 'a' to 'c' and counter2 counts from '0' to '3', and resulting sequence after reset would be "0a", "0b", "0c", "1a", "1b", "1c" etc).

So I repeat: the only thing TC have to do is to request 'ResetCounters' field (or suggest a better name) from every WDX plugin [that supports this feature] before generating list of filenames in MRT. The rest will be done by plugin writers.

Probably it will have sense to call such field for retrieving fields in regular panels after changing folder (this will allow fields with e.g. accumulative sums of sizes).

[solid]

I'n not a plugin developer, so i don't exactly understand the meaning of the field, but if that can enhance the MRT the way you described it, than one big SUPPORT for this request from me

[MVV]

solid,
Currently content plugins may produce fields depending on file, on path, on date etc, or random one. But if you need a counter, plugin should return incrementing value for every call (1, 2, 3, 4, ...) independent of file, and you expect to see first sequence number for first file in MRT. MRT calls same plugin fields like panels, and plugins return next values, but it is currently impossible to detect that we want to restart counter from the beginning.

This idea may improve MRT-and-plugins interaction by informing plusins that 'hey, I wanna get new number sequence for enumerating files, please reset your counters' before retrieving plugin fields for new names.

[solid]

MVV, thanks for explanation.
If I understood well, if TC supports this feature, actually we would need just one plugin than can do the counting instead of rewriting each one as the counter can be added anywhere in the MRT placeholder.
I would like to hear from the author for chances on supporting this, or just include the feature in the TC itself.

[MVV]

Yes, one plugin may combine all these counter types, and its fields may be called multiple times in MRT templates. But there may be multiple plugins providing different kinds of such counters.

It is easy to make alphabets for every counter configurable, also number of counters may be read by plugin from same configuration file.

[xmeron]

2MVV:
Using plug-in to reset counter is a good idea, and according to your description, this WDX plug-in will be a powerful enough counter which can do many things, and the name 'ResetCounters' or 'CountersReset' seem both OK.
But I am not a plug-in writer, either. Hope someone can write such kind of a fantastic plug-in, the built-in counter in TC seems too weak.

[MVV]

I even would write such plugin if such feature would be implemented. Maybe someone would write its alternative too, different people has different view points and needs.

[xmeron]

Yes, different people has different needs, what we can do now, is waiting for others to request this kind of feature again and do something finally.