[xslt] Re: xslt digest, Vol 1 #64 - 6 msgs
- From: Luke Kenneth Casson Leighton <lkcl samba-tng org>
- To: xslt gnome org
- Subject: [xslt] Re: xslt digest, Vol 1 #64 - 6 msgs
- Date: Wed, 20 Jun 2001 15:24:45 +0200
> Message: 2
> Date: Mon, 18 Jun 2001 13:12:26 -0400
> From: Daniel Veillard <firstname.lastname@example.org>
> To: email@example.com
> Subject: Re: [xslt] Release of libxslt-0.12.0
> Reply-To: firstname.lastname@example.org
> > i sent in a patch to do
> > a state+next() fn, hope you like it :) it keeps the
> > legacy fns that still take char **, with an example
> > state+next() fn based on getting the next 'var=val' in the
> > char ** array,
> Well it wasn't looking an urgent thing to fix. It also sort of
> break the XSLT processing model.
> The XSLT process does the evaluation
> of the parameters, it don't receive them precomputed.
parameters. the char** array? it's just an array
of var, val, var, val, NULL.
> This is a
> significant difference and checking whether your patch was a clear
> spec violation or something acceptable, I didn't yet had the time to
> really look at it. It still looks more a possible serious problem
> than an enhancement honnestly. I tend to prefer computing again this
> fixed set of values (initially) than introducing potential serious
> hazard in the way the computation gets done (which is a real pain
> to debug and get fixed when this occurs). I hope you understand my
> hesitation ant why I didn't incorporated it so far.
take a look at it more carefully: it's not doing pre-evaluation
or anything, or expecting to do any kind of dynamic evaluation.
it's functionally directly equivalent to what was already there,
a char **, except with a void*state and a function with the
same type of semantics as the unix pwd / NIS pwd / dbm getnext() set
of functions. pass in the void* to the function, get back the
next char*var and the next char* val.
there's nothing fancy about it, i just didn't want to have to
convert an apr_table_t's entries into a char **, it seemed
like a silly thing to have to do, and i thought other people
might want to do likewise.
i _can_ think of a better way to do it, though.
you pass in a function and a void* with the same semantics as
the fn's prototype should be:
const xmlChar * /* the variable value: NULL if it doesn't exist */
xsltStyleUserParamGet(xsltStyleUserParamTable *state, const xmlChar *varname);
[match this against apr_table_get's prototype, it's identical]
then you _could_ potentially get user params that depend on the
document or the stylesheet, but personally i don't think that's
a good idea.
the impact of adding and using a function like this was quite heavy,
so i decided not to do it: unfamiliar code.
whereas, the patch i sent you was trivial to implement, and
> > a suggestion. you have a xsltSaveToFile, to Fd, and to a buffer,
> > but not save-to-memory, like in libxml.
> Hum, building an Output buffer for memory is doable easilly. I
> can add this into libxslt directly since it's a fairly common API.
ack! great! because i had to cut/paste your code and use that :)
> > also, someone else mentioned problems saving to xxxx because of
> > dumping doc *without* the stylesheet.
> > based on this, what i did was set up a memory buffer,
> > called xsltSaveTo, then _re-parsed_ the memory buffer _back_
> > into a document.
> I am not sure I fully understand. the transform function puts
> everything possible onto the tree but some things cannot be saved
> in the tree (like the indent = ...), so it is really needed to
> do a serialization to get them, yes.
is that to do with the global variable [xmlIndent??...]
> > so, i have a couple of suggestions that may make this a little
> > easier:
> > how about either a)
> > create a xsltSaveToMem
> > b)
> > 'create' a doc using the stylesheet and the source doc document, saaay.... as
> > xsltSaveToDoc.
> > xmlDocPtr *xsltSaveToDoc(xmlDocPtr *cur, xsltStyleSheet *sheet);
> this should be idempotent.
oo. i _should_ know what that means. had to look it up.
idempotent: first usage of 'thing' has an effect. subsequent uses
do not. i.e. 'set thermostat to 20 deg' is idempotent.
'increase thermostat by 5 deg' is _not_ idempotent.
> Except for formatting spaces added to the
> tree. What else are you missing ?
nothing that i don't know about :) :)
> > what do you think?
> that I will provide an XSLT serialization to memory. the xsl:document
> construct may require an update of this API anyway, as well as streaming
> on output. So this may change a bit within the next month anyway.
ack. will follow with enthusiasm :)
p.s. you'll be pleased to know that i can view the REC-xml-2e.xml xml
spec test WITH the markup diffs, using xvl:
the xvl page is this:
<page raw="yes" xmlns:xvl="http://undefined"
<xslt:input file="REC-xml-20001006.xml" style="REC-xml-2e.xsl" args=""/>
the base64 encode is needed because the document output cannot be re-parsed
as xml but only as html [or it couldn't when i was playing around, so
i did the encoding for safety /paranoia reasons]. only when it arrives
at mod_virgule is the document un-encoded and sent out untouched as an
HTML page for the browser to deal with :)]
i think that using libxslt like this is amazingly powerful.
it's possible to have xvl specify a different stylesheet based on
the HTTP headers received from apache. i.e. you can decide at run-time,
if the client's browser is netscape, use a different stylesheet.
if it's a text-only lynx browser, use a different stylesheet.
or even pass in user-params to one stylesheet to get it to do
different browsers for itself.
this is very cool :) _and_ it's a standard. love it, daniel :)
] [Thread Prev