XSLT & hello

[Denis S. Filimonov]

I second that. XSLT really belongs to the application level. For instance, you 
might want to allow users to select different stylesheets for the same page 
(e.g., different skins). If you offload the XSLT outside your application, 
you lose this ability.

Besides, I don't think nginx would be able to do it considerably faster, it'd 
probably use the very same libxslt.

On Tuesday 08 April 2008 06:08:04 mike wrote:
> Again - I see this as being still making sense to reside in the
> application layer, since the possibilities of inputs and outputs are
> infinite (well, could be...)
>
> I'm not sure the browser reliably reports it's XSL processing
> capabilities without using JavaScript, in which case, you've probably
> already side-stepped the webserver (or, you have to use all this in
> combination with each other)
>
> I don't believe there is still any consistent client-side XSL that can
> be adopted that is safely cross browser and such. Last I checked
> Google had an XSL processing library that was as close to
> cross-browser as it got, but it still wasn't 100%.
>
> I'm not saying it's not worthwhile for some folks. I am just not sure
> it's meant to be in an nginx supplied module. Extensions obviously
> anyone can cook up for any reason... and XML/XSL offloading is a
> common desire (ZXTM does it, there's some hardware appliances even
> that will do it for you) - someone has already said they'd love it for
> their application - the need -is- there, but I'd rather it be
> something external to core nginx development as there are some other
> features that should reside in the server that have not been finished
> yet...
>
> On 4/8/08, Chris Farmiloe <chris at oxdi.eu> wrote:
> > The main benifit I'm after is being able to decide from the nginx.conf
> > something like this (pseudo):
> >
> > if($user_agent is unable_to_perform_xslt){
> >   xslt on;
> > }
> >
> > This would allow me to offload the majority of the XSLT processing
> > client-side, but still support some of the older browsers, text-only,
> > screen readers etc.
> >
> > I'm also a fan of a complete separation from application level code...
> > although XSL is about presentation, XSLT is simply the process of
> > conversion and unlikely to need modifying.
> >
> > I see you're point about converting between random formats, but if you
> > think about it... YES... if there was an XSLT module you could handle
> > almost any output you could create with XSL. and maybe even override
> > the style-sheet to use ie..
> >
> > location ~* .csv$ {
> >  xslt on;
> >  xslt_stylesheet /xsl/csv.xsl;
> > }
> >
> > It could allow you to create application servers that only talk one
> > language (XML) while allowing you to still build REST style services
> > that respond to multiple content types.
> >
> > chrisfarms.



-- 
Denis.