@Soma
The idea is not to just format values but to modify (filter) a variable, whatever that might be. I understand the confusion, because the hook in the init method we were discussing actually restricts the plugin usage to fields. Just brainstorming.
The real difference between using the Filter module and standard hooks is that the first was meant to run "on demand" (only when the function applyFilter() is executed), while the second is attached to any possible field that is output, even if you don't need it. About the naming convention, yeah, the word "filter" is some heritage from the WP concepts, but for the modules names, whenever is possible and if they don't collide, I personally prefer them short and single-worded. And yeah2 those helper functions might pollute the global namespace, they're probably not necessary as one could just call wire('Filter')->add(...);
Anyways, I believe that to use hooks would be fine, just a little more verbose but they would just work:
$this->addHookAfter("Fieldtype::formatValue", $this, function(HookEvent $event){
$field = $event->arguments("field");
if ($field->name = 'myfield') {
$value = $event->return;
$value = $event->arguments("value");
$page = $event->arguments("page");
$event->return = "new value";
}
});
With Filter it would be:
wire('Filter')->add('formatValue_myfield', function($value){
return 'new value';
});
But it only makes sense if somewhere else that value is filtered (like the init method of the Filter module, or inside template files etc...):
$value = wire('Filter')->apply('formatValue_myfield', $value);
I think I can go with the standard hooks even if it takes more code because I prefer to use core features, my only concern is: can we add many hooks without excessive overhead, for example due to the huge size of the $event object?
Thanks for the feedback!