You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "M. van Renswoude" <ma...@x2software.net> on 2004/05/27 22:42:51 UTC

SVNIndexXSLT, server-side processing?

Hi,

because Opera does not support client-side XSLT processing, I was messing
around with getting it to work server-side. With Apache's filters and
xsltproc I got to the point where it would output the HTML code and Opera
accepted it. Initial problem was that the Content-Type is set to XML,
therefore the output needs to be compliant; however, when using
output="html" in the XSL it doesn't for the <meta> and <link> tags. Using
output="xml" solves that, but then IE renders it as it would any XML file
due to the <?xml?> header that's added, even if I specify all the XHTML
doctypes... (insert mumbles here)

Long story short; it doesn't work. Of course I could live with the default
listing, but I'd rather have it blend in nicely with the rest of the pages.

So my question is: does anyone know of a way to have Subversion output HTML
the way I want? Be it using XSL sheet or not... I noticed the "Version
control" on the SubVersion website has a customized layout as well, which
doesn't use XML output, so perhaps anyone knows if that's easy to do?


Thanks in advance,

Mark

RE: SVNIndexXSLT, server-side processing? [solution]

Posted by Mark <ma...@msdhub.com>.
Imagine that, IE does the right thing...

What with IE now respecting content-types AND being the only browser that
complies with the URI RFC (i.e. not allowing user:password@host for http
urls), maybe it's time for some of that life insurance...

Mark

-----Original Message-----
From: M. van Renswoude [mailto:mark@x2software.net] 
Sent: Friday, May 28, 2004 7:30 AM
To: users@subversion.tigris.org
Cc: Robert Koberg
Subject: RE: SVNIndexXSLT, server-side processing? [solution]

Either way, the real problem was the Content-Type: text/xml which caused IE
to render it as an XML tree even after the XHTML output was completely
valid, so that just needed the source change to text/html...

- Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: SVNIndexXSLT, server-side processing? [solution]

Posted by "M. van Renswoude" <ma...@x2software.net>.
> There might be another problem. Are you sure you have closing tags for
> things like <title/> and <script/>? If they are rendered closed then the
> page will not display. You need to force the close tag to show, E.g:

The XSL had <link href="/svnindex.css"/> in there, but due to the
output="html" setting it removed the last /. It did that with the <meta> tag
as well. I tried <link></link>, I even tried an <xsl:element> to build the
link tag that way, but the output remained the same. It treats those tags
differently it seems, because when I did <blah/> it outputted it correctly.

Either way, the real problem was the Content-Type: text/xml which caused IE
to render it as an XML tree even after the XHTML output was completely
valid, so that just needed the source change to text/html...


- Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: SVNIndexXSLT, server-side processing? [solution]

Posted by Robert Koberg <ro...@koberg.com>.
M. van Renswoude wrote:

>>Try putting
>><xsl:output omit-xml-declaration="yes"/>
>>in your xsl file, that should remove the XML PI.
> 
> 
> That does the job for the XML declaration, thanks! Unfortunately, IE still
> refuses to render it, and I have found out why: the Content-Type header is
> text/xml. No Apache directive (such as 'Header') will solve that, so it's
> time to hack the SubVersion source. As a note to the authors; I think
> server-side XSLT processing is much nicer, and of course much more
> compatible with older clients, so here's the suggestion for such a feature
> :).

There might be another problem. Are you sure you have closing tags for 
things like <title/> and <script/>? If they are rendered closed then the 
page will not display. You need to force the close tag to show, E.g:

<title>something</title>
<script src="boo.js">//</script>

FWIW, another gotcha is textarea -- you need to force an end tag to 
render for that too.

best,
-Rob

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: SVNIndexXSLT, server-side processing? [solution]

Posted by "M. van Renswoude" <ma...@x2software.net>.
> Try putting
> <xsl:output omit-xml-declaration="yes"/>
> in your xsl file, that should remove the XML PI.

That does the job for the XML declaration, thanks! Unfortunately, IE still
refuses to render it, and I have found out why: the Content-Type header is
text/xml. No Apache directive (such as 'Header') will solve that, so it's
time to hack the SubVersion source. As a note to the authors; I think
server-side XSLT processing is much nicer, and of course much more
compatible with older clients, so here's the suggestion for such a feature
:).


Here's what I did (based on the 1.0.4 source, compiled on Debian Sarge):

- Modify subversion/mod_dav_svn/repos.c, find:

----------------------------------------
  /* For a directory, we will send text/html or text/xml. If we have a delta
     base, then we will always be generating an svndiff.  Otherwise,
     we need to fetch the appropriate MIME type from the resource's
     properties (and use text/plain if it isn't there). */
  if (resource->collection)
    {
      if (resource->info->repos->xslt_uri)
        mimetype = "text/xml";
      else
        mimetype = "text/html; charset=UTF-8";
    }
----------------------------------------


then comment out the if-else to leave only text/html:


----------------------------------------
  if (resource->collection)
    {
      /*if (resource->info->repos->xslt_uri)
        mimetype = "text/xml";
      else*/
        mimetype = "text/html; charset=UTF-8";
    }
----------------------------------------


Assuming you already have it configured, go through the whole make clean /
make / make install cycle.

Now we need to process the XML output, for this I used xsltproc and a filter
written in Perl. I am planning to write an Apache 2 filter in C one day, but
my knowledge in that area is lacking at the moment so I'll just go for the
quick solution. Works fine for a quiet site.

First, the Perl script. Make sure it's executable by your webserver's user
of course. The source:


----------------------------------------
#!/usr/bin/perl
use strict;
use Digest::MD5 qw(md5_hex);

my @input       = <>;
my $input = join("\n", @input);

# Check for <svn> tag
if ($input =~ /<svn\s/)
{
  my $file;

  # Let XSLTProc process it
  # I have not found a satisfactory way to call xsltproc without
  # writing a file. Plenty of room for improvements, that's for sure...
  do
  {
    $file       = '/tmp/svn_' . md5_hex(localtime());
  } until (!-e $file);

  open (XML, ">$file");
  print XML $input;
  close (XML);

  system("xsltproc $file");
  unlink($file);
}
else
{
        # Just output it
        print @input;
}
----------------------------------------


Now we need to tell Apache to run it, here's my subversion virtual host:

----------------------------------------
<VirtualHost *:80>
  ExtFilterDefine svnxsl cmd="/web/subversion/xsltransform.pl"

  DAV svn
  SVNParentPath /var/lib/subversion/public
  SVNIndexXSLT "/web/subversion/svnindex.xsl"

  SetOutputFilter svnxsl
</VirtualHost>
----------------------------------------


I've left out all parts which aren't interesting (ServerName,
authentication, etc). One note here: SVNIndexXSLT is now an absolute path
instead of the old relative path. The reason for this is that xsltproc will
detect the stylesheet reference and apply it, which means we don't have to
provide the location on the command line. Makes it easier to apply different
stylesheets on different hosts...


So far this solution works like a charm.


- Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: SVNIndexXSLT, server-side processing?

Posted by Cristi BALAN <me...@gmail.com>.
----- Original Message -----
From: M. van Renswoude <ma...@x2software.net>
Date: Fri, 28 May 2004 00:42:51 +0200
Subject: SVNIndexXSLT, server-side processing?
To: users@subversion.tigris.org


Hi,
 
because Opera does not support client-side XSLT processing, I was
messing around with getting it to work server-side. With Apache's
filters and xsltproc I got to the point where it would output the HTML
code and Opera accepted it. Initial problem was that the Content-Type
is set to XML, therefore the output needs to be compliant; however,
when using output="html" in the XSL it doesn't for the <meta> and
<link> tags. Using output="xml" solves that, but then IE renders it as
it would any XML file due to the <?xml?> header that's added, even if
I specify all the XHTML doctypes... (insert mumbles here)
 
Long story short; it doesn't work. Of course I could live with the
default listing, but I'd rather have it blend in nicely with the rest
of the pages.
 
So my question is: does anyone know of a way to have Subversion output
HTML the way I want? Be it using XSL sheet or not... I noticed the
"Version control" on the SubVersion website has a customized layout as
well, which doesn't use XML output, so perhaps anyone knows if that's
easy to do?
 
 
Thanks in advance,
 
Mark


Try putting 
<xsl:output omit-xml-declaration="yes"/> 
in your xsl file, that should remove the XML PI.

Cristi BALAN

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org