Such filters can be used for exporting a content.
Of course it's possible to combine it with the service ImportFilter
if import functionality should be available at same implementation too.
It's used to filter a document at saving time.
The source document should be already setted by using another interface
XExporter which is supported by this service too.
Tip:
If same implementation provides the service ImportFilter too,
code must distinguish between filtering from a source document (for export) or
filtering to a target document (for import). This can be recognized by saving
state of used interfaces XExporter or XImporter!
Otherwise it's not clear which action is required here.
support initialization of filter with its own configuration
A filter object must be created by global service FilterFactory.
If filter supports this optional interface, he will be initialized by the factory directly
after creation. The factory will pass follow informations to this new instance:
first item will be a set of configuration data of the filter
provides access to the internal name of this filter
This internal filter name can be used on service FilterFactory
to get further informations about it (e.g. his registration for mime types or extensions etc.)
It's important that returned string is the "internal name" of the filter which must be
unambigous against all other registered filter in current instalation.
Attention!
Supported method setName() sould be ignored or forwarded to the FilterFactory.
It's not allowed to set it directly to the configuration. Because it depends
from real implementation of the FilterFactory if it will be allowed or not!