plastikfan
commented
3 years ago Registering plug-ins can't or should not be done by sourcing a script. There needs to be a new function (let's call this Register-Plugin for now). One of the parameters would specify registering for rename-many command. This would allow the function to be augmented to be used by other commands in the future.
Another parameter would have to specify the required subscriptions as yet to be defined.
For each subscription, there needs to be a subscription type that indicates:
- must be called first (only 1 allowed)
- must be called last (only 1 allowed)
- order agnostic (many allowed)
So this is beginning to look like chain of responsibility, so check this out again.
There should be internal and external plugins
- Internal: implemented inside rexfs
- external: implemented in 3rd party modules ... both of which are treated with equal priority.
Plugins are an alternative to Transforms. Need to establish a new user plugin sub directory, (under the ./elizium directory), which contains the user defined plugins. With a plugin, the user does not have to specify it on the command line.
It might be a good idea to implement the post-processing as a plugin. A plugin can define its own config. The plugin needs to be registered somehow.
Also need to define 'life cycle events', such as OnBatchBegin, OnBatchEnd etc
The plugin would register for the events that it is interested in.
This functionality would be used by the accelerators feature; so when a formatter parameter contains an output accelerator, the plugin would resolve any accelerator references, eg
without the plugin, this would be an invalid specification of a format, because the Paste contains file system unsafe characters. The plugin should get a chance to modify the Paste formatter so it can resolve the @/DMY/ accelerator reference
Plugin registration/initialisation should occur at import time only, not on command invocation, this is to cut down on having to pay any latency hit every time the command is invoked.
A plugin should be a PSCustomObject with ScriptMethod members. Trying to implement as a class would be a nightmare and virtually impossible given that classes in PowerShell were not really designed to be used accross module boundaries.
Although having said this, it may be possible, since any client code could simply perform a using module on Elizium.RexFs to get full type safety. This needs to be prototyped, to see if this is feasible.
On further consideration, it may be best to use a hybrid approach. To retain the benefits of using a class, ie the polymorphism, we could define an internal wrapper class that takes the client defined PSCustomObhect as a constructor argument, and the class would delegate events to PSCO according to the plugin event registration.
At initialisation time, we would source all the plugin files in the plugin directory.