Let us know how it goes - using XSLT that way is often desirable from
a developer's point of view, but is usually impractical due to the
processing overhead. If you end up successfully using this technique
in production without complaints from users please let the list know,
I'm sure a few
Marc M. Adkins wrote:
Well, I _am_ using XSLT for my template expansion. That kind of makes
XML important.
Thanks for the responses, and that's about what I figured I would try.
Just wondering if anyone would answer "no it won't work because..."
Let us know how it goes - using XSLT that way
Well, I _am_ using XSLT for my template expansion. That kind of makes
XML important.
Thanks for the responses, and that's about what I figured I would try.
Just wondering if anyone would answer "no it won't work because..."
John Drago wrote:
--- John ORourke <[EMAIL PROTECTED]> wrote:
I'v
--- John ORourke <[EMAIL PROTECTED]> wrote:
> I've no experience of parsing XML on every request
> (not that I'd want
> to, what an overhead!) but could you just output
> nothing in the response
> phase, and put the XML object reference using
> $r->pnotes('my_xml_object', $my_xml_object) then
Marc M. Adkins wrote:
The other side of this is that the response handler generates XML and
the output filter handler consumes it. I was thinking that I should
be able to hang the XML object (not the text representation thereof)
on the request object and avoid the overhead of printing the XML
Is there a performance advantage to using bucket brigades vs. just
"printing" to the request object? I assume the latter uses the former
at some level.
I have a PerlResponseHandler feeding into a PerlOutputFilterHandler.
The latter uses bucket brigades directly for both input and output. The
