Current behaviour

The methods createInstance() or createInstanceWithArguments() of this interface must be called with an internal type name!. This name is used internaly to search a suitable (mostly the default) filter for this type then. The found filter will be created, initialized and returned then. Creation of a filter by using it's internal filter name directly can be reached by using createInstanceWithArguments() with an optional property "FilterName" only. See the following example:

 private com.sun.star.uno.XInterface createFilterDirect( com.sun.star.lang.XMultiServiceFactory xFilterFactory ,
 java.lang.String sInternalFilterName )
 {
 com.sun.star.beans.PropertyValue aFilterProp = new com.sun.star.beans.PropertyValue();
 aFilterProp.Name = "FilterName";
 aFilterProp.Value = sInternalFilterName;

 com.sun.star.uno.Any[] lProps = new com.sun.star.uno.Any[1];
 lProps[0] = aFilterProp;

 java.lang.Object aFilter = xFilterFactory.createInstanceWithArguments("", lProps);
 return (com.sun.star.uno.XInterface)UnoRuntime.queryInterface(com.sun.star.uno.XInterface.class, aFilter);
 }
 

Proposed behaviour

Searching of a suitable filter for a given internal type name, must be done by the new interface ::com::sun::star::container::XContainerQuery, available on this factory too. The factory interface can be used to create filter components by it's internal filter name only.

How it can be distinguished?

The new prosposed implementation will throw an ::com::sun::star::container::NoSuchElementException if the first parameter of createInstance() or createInstanceWithArguments() does not match to a valid container (means filter) item. Further it will throw an ::com::sun::star::lang::IllegalArgumentException if the optional parameter "FilterName" could not be detected inside the argument list of call createInstanceWithArguments().

Initialization of a filter component

Every filter, which was created by this factory can(!) be intialized with it's own configuration data and may given optional arguments of the corresponding createInstanceWithArguments() request. To do so the filter instance must support the optional interface ::com::sun::star::lang::XInitialization. The arguments parameter will have the following structure:

• sequence< Any >[0] contains a sequence< PropertyValue >, which represent the configuration data set of this filter. The used properties are the same, as they are available at the container interface of this factoyr service. (see below)
• Every following item of the argument list sequence< Any >[1..n] contains the copied argument of the corresponding createInstanceWithArguments() call. That means: Item 0 or the original list was copied as item 1 of the destination list ... etc.

Every container item is specified as a set of properties and will be represented by a sequence< PropertyValue > structure. Follow properties are supported: (But note: not all of them must be present everytimes!)

Note:
All elements of this container will be adressed by his internal name, and it must be an unambigous value.

Against simple property search it provides some complex algorithms too. For further informations please read the SDK documentation.

Because the complexness of such configuration set can be very high, it seams not very usefull to update the undelying configuration layer on every container change request immediatly. Another strategy can be to make all changes (adding/changing/removing of items) and call flush at the end. That will validate the whole container and reject inconsistent data sets. Only in case all made changes was correct, they will be written back to the configuration. Further this interface provides the possibelity, that interested changes listener can be registered too.