Hi Jon, For documentation - see http://poi.apache.org/howtobuild.html
You will need Forrest to build documentation. It should be relatively easy to see where to put the docs. After having made changes to the docs myself I really wish we did it a different way - or at least added a supplemental Wiki. Please see http://poi.apache.org/guidelines.html for contribution guidelines. I'm looking forward to what others comment about your registration ideas. Regards, Dave > That example is very straightforward, thanks for pointing me to it. > Additionally, I would like to contribute some docs on this because I think > this > is a really nice feature. Are there instructions somewhere I can reference > for > adding such a contribution? > > 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. > > > I can see a way to add to it, though. This example works well when you have > a > single workbook with a small set of functions that need to be converted. But > what if you have an application built on POI that has a number of workbooks > with > a number of custom functions? This declarative approach might be cumbersome > (but certainly workable, so I am not criticizing). > > My suggestion would be to provide some ability to do this through > configuration. The code snippet: > > > UDFFinder udff1 = new DefaultUDFFinder(new String[] { "myFunc", > }, new > FreeRefFunction[] { new MyFunc(), }); UDFFinder udff2 = new > DefaultUDFFinder(new String[] { "myFunc2", }, > new FreeRefFunction[] { new > MyFunc2(), }); This is basically registration, not unlike registering beans > with > Spring or even something simple like a properties file. If this could be > moved > from code to a configuration I think it would make coding for these workbooks > with custom functions easier (though on the other hand there is an argument > to > be made for keeping it as it is because this makes it declarative that a > given > workbook has custom functions). Another benefit of going the configuration > route is that a developer could write the function, add it to a file and > basically forget about it because their POI instance would have it globally. > > On my project, we don't have an immediate need for this functionality, but > maybe > others do? > > > So my idea would be something like the following: > > UserDefinedFunctions.xml: > > <beans> > <bean id="myFunc" class="com.mycompany.my.project.MyFunction"/> > <bean id=="myFunc2" class="com.mycompany.my.project.MyFunction2"/> > </beans> > > or > > UserDefinedFunctions.properties > > myFunc=com.mycompany.my.project.MyFunction > myFunc2=com.mycompany.my.project.MyFunction2 > > If you prefer not to use Spring. There are probably other ways to achieve > this > part, these are just examples. > > In the application code: > > Workbook workbook = WorkbookFactory.create( "path/to/target/workbook.xls", > "path/to/UserDefinedFunctions.xml" ) ; > > Another way would be to have POI look in the classpath for a specific file; > if > it exists, POI loads the functions defined. Then in the code there is no > reference at all to this file (though again, it might make it more confusing). > > I realize that this is semantic, users of the API could easily add this > themselves. I like the idea of not having to code the registration myself. > > Anyway, hopefully this doesn't come off as a criticism because I am > definitely > not criticizing, this is great functionality as it is. I've used POI over > the > years and I think very highly of it. Please let me know if I can be of > assistance. > > > Sincerely, > > Jon > > > ----- Original Message ---- > From: Yegor Kozlov <[email protected]> > To: [email protected] > Sent: Mon, October 4, 2010 2:07:12 AM > Subject: Re: how to add functions to POI > > >> If after reading the code and the docs I can see how I might be of >> assistance > I >> will do as you suggested. Outside of the test case, is this feature >> documented? I don't recall reading about this. > > UDF is not well documented, all available bits of documentation are those in > the > source code and in Bugzilla. > > Perhaps, a good contribution would be an example how to use the UDF API. > Patches are welcome. > > Yegor > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
