As far as patching it, I don't think it *needs* a patch. One suggestion might
be that when POI encounters a custom function and it throws an exception, the
comments of the exception point users to the UDFFinder docs.
This sounds like a good idea. If the formula evaluator stumbles on an
unknown function then the exception should suggest a workaround with UDF.
There can be tricky details - we need to tell unknown defined names from
unknown functions, this detection should work transparently for .xls and
.xlsx formats, etc. But anyway, I like the idea.
Your idea with configuration of UDFs also makes sense but I don't want
to make it too complicated. POI does not depend on Spring and I don't
think we will add a new dependency just for configuration of UDFs. So,
Java properties is the way to go.
In current implementation if UDFFinder is not specified then a default
instance is used, see UDFFinder.java:
public static final UDFFinder DEFAULT = new
AggregatingUDFFinder(AnalysisToolPak.instance);
I think it should be re-written into something like this
public static final UDFFinder DEFAULT = new
AggregatingUDFFinder.getInstance();
where getInstance() will search for a configuration file (system
property or classpath) and programmatically register UDFs, just like in
the test case.
This way future versions of POI will be compatible with existing user
code. If support for custom VBA functions is needed then all user needs
to do is to implement the VBA code as FreeRefFunction and register it in
the configuration file.
Yegor
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
