Re: [Libreoffice] [PATCH] replace Saxon/J XSLT extension functions with libxslt/c++ equivalent

On 26/03/11 13:42, Peter Jentsch wrote:
> Hi,
>
> I now have a first working implementation of the XSLT extension
> functions which currently prevent the Office 2003 ML filters from using
> the libxslt based transformation service.
>
> The patch affects 3 modules:
>
> solenv: new PACKAGE2LIB variable defined in libs.mk
> components/package: made Inflater/Deflater classes (needed by the
> extension functions) available as DLL imports.
> filters/filter: added extenstion function impl., changed XSLT
> stylesheets to work with that and changed configuration of Word 2003 ML
> filters to no longer use the JAXT transformation service.
>
> I'm afraid the OleHandler class still needs a lot of love, esp.
> w/regards to exception handling, but as of now it even works somewhat
> better than the java based impl. which is currently completely broken
> (in both OOo and LibO, at least under Ubuntu 10.10).
wow this looks pretty impressive, but... I fear I am a little lost 
reviewing it . Any pointers to testing ? ( for the unitiated e.g. me )
Another thing that worries me is the windows build, I see there is a new 
PACKAGE2LIB defined but only for ( afaics ) the 'nixes, Have you tried 
to build it on windows, II think we might be able to get some of the 
windows experts to help ( iirc you will need a 'ipackage2.lib' file 
which afaik isn't always available and requires some magic something in 
a makefile somewhere )

Asking here Tor and Fridrich if they are ok with the possibility of 
breaking the windows build ( and asking can they help when that happens 
) should the consensus be it's a good idea to commit this now.

If I understand things correctly then mostly this is already integrated 
( and this goes a further step to remove more java-ication ) and being a 
new code/feature we certainly can tolerate the code needing 'more love' 
etc.
On that front as a suggestion there are some helper stream classes you 
might find useful that can wrap those the hard to use uno stream 
classes, there is also  there is a memory stream class helper ( that 
might allow to avoid ( or at least hide ) creating temp files ).  Those 
SvStream type classes at least help with some of the pain of 
reading/writing basic types and strings etc. to/from stream

e.g.
http://opengrok.libreoffice.org/xref/libs-gui/unotools/inc/unotools/ucbstreamhelper.hxx#66 
( helper for converting uno X*Stream types into SvStreams )
http://opengrok.libreoffice.org/xref/libs-gui/tools/inc/tools/stream.hxx#782 
( MemoryStream )

p.s. newfile package/inc/packagedllapi.hxx needs the standard licence foo


Noel