Re: [xslt] XSL Sort + ICU

["Cyberthymia" <cyberthymia yahoo co uk>]

Hi

New patch file attached.
I've put in the new context sort bit you requested, and added it to the
libxslt.def.src file.
I also tweaked a couple of the comments just to try and explain things a bit
better.

Also attached is an example replacement sort function using ICU.
Whilst adding it as an option to xsltproc won't be difficult, I haven't done
this because I
don't have time at present to find a way around all the strange linking
problems that are
likely to occur for the different platforms. I'm afraid I'm going to have to
leave this to
people who understand the different build processes.

To use it, you need the "icuin22" and "icuuc22" libs/dlls (although the ICU
makefiles
don't use a consistant naming scheme across platforms, so they may be called
some
thing similar on Linux)

Richard

----- Original Message -----
From: "Daniel Veillard" <veillard@redhat.com>
To: <xslt@gnome.org>
Sent: Wednesday, November 27, 2002 12:47 PM
Subject: Re: [xslt] XSL Sort + ICU


> On Wed, Nov 27, 2002 at 12:34:11PM -0000, Richard Jinks wrote:
> > From: "Daniel Veillard" <veillard@redhat.com>
> > >
> > >  I'm also wondering if we should not provide a way to register a
specific
> > sort
> > > function in a given context, sounds better for multithreaded apps,
> > something
> > > like xsltSetCtxtSortFunc(xsltTransformContextPtr ctxt, xsltSortFunc
> > handler);
> > > store it in ctxt, and have the transformation look first for it then
> > fallback
> > > to the global setting. Sounds relatively trivial,
> > >
> >
> > I did half consider this approach but decided against it purely because
it
> > would
> > involve changing the xsltTransformContext structure, something that will
> > break people's code if it changes.
> > If you're OK with this, then I'm happy to make these changes - I'll try
and
> > get it
> > done this afternoon.
>
>   just make sure you add the field at the end of the structure. This
breaks
> only if people *allocate* the structure themselve which they should not do
.
> I revamped slightly the API already to make xsltDoSortFunction a real
public
> function acting as a dispatcher for the globally registred one. See the
> patch commited:
>
http://cvs.gnome.org/bonsai/cvsquery.cgi?module=libxslt&branch=HEAD&branchty
pe=match&dir=libxslt&file=&filetype=match&who=veillard&whotype=match&sortby=
Date&hours=&date=explicit&mindate=11%2F27%2F02+07%3A34&maxdate=11%2F27%2F02+
07%3A36&cvsroot=%2Fcvs%2Fgnome
>
>   This make things easier because you just have to patch
xsltDoSortFunction()
> to check for a context specific function,
>
> > >
> > >   I should definitely be made availble, xsltproc could even use it,
but
> > > I don't want libxslt to globally embedd it or depend on it. Is there a
> > > known shared library exporting ICU ?
> > >   Send the code here, at least it will be archived and indexed :-)
> > >
> >
> > I'll send it along with the other code changes.
>
>   okay,
>
> > As a thought - would it be worth doing a similar thing for the number
> > formatting
> > (xsl:number) at some stage?
>
>   Hum, yes except that the interface is likely to be far more complex,
> let's stabilize Sort first and then we will see :-)
>
>    thanks,
>
> Daniel
>
> --
> Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
> veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
> http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
> _______________________________________________
> xslt mailing list, project page http://xmlsoft.org/XSLT/
> xslt@gnome.org
> http://mail.gnome.org/mailman/listinfo/xslt

icusortexample.c

sort2.diff