[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Re: [xsl] [Very off-topic] Using Apache MultiViews option (was: How to throw transformation to browser)
Subject: Re: [xsl] [Very off-topic] Using Apache MultiViews option (was: How to throw transformation to browser)
From: Antonio Fiol <fiol@xxxxxxxxxx>
Date: Fri, 28 Jun 2002 17:23:21 +0200
|
(Sorry for the off-topic. But as it may be helpful to others, I'll
keep this on the list)
Well... Let's go for your case...
This is information published by your web browser every time one
requests a web page from www.ballsome.com:
Server: Apache/1.3.26 (Unix) FrontPage/5.0.0.0 mod_ssl/2.8.10 OpenSSL/0.9.6a
For the Apache server, I found the following HOWTO (from our company's
docs):
1. Enable MultiViews on your apache configuration.
2. Add the MIME types for the extensions you need (xml and xsl, both
text/xml IIRC)
3. For each file you need compressed, do:
cp file.xml file.xml.xml
gzip -9 file.xml
4. You'll end up with double files (file.xml.xml and file.xml.gz).
IMPORTANT: The original file, named "file.xml" should disappear from
sight...
5. You're ready. Let's test it.
6. Launch a net sniffer, like ethereal, either on your client or your
server.
5. Point your browser to the address of the former file.xml.
If everything is OK...
a) Your browser should show the page to you.
b) Your net sniffer should NOT show the XML in the HTTP response, but
the compressed version.
If you look at the headers, there should be a "Accept-Encoding: gzip"
header on the request packet.
And there should be a header on the response indicating that it is
serving file.xml.gz instead.
If the "Accept-Encoding: gzip" header is not present on the request,
that means that your browser does not support compressed content.
However, the file.xml.xml should be served instead, so the content will
still be viewed.
If file.xml still existed, no content negotiation would occur, and so
the original uncompressed file would be served.
NO CHANGES ARE REQUIRED IN YOUR PAGES.
Thought 4: (Continues the saga)
If you have a relevant part of common templates, and you want to keep
the impact on the user who comes for the first time low, while also
avoiding impact on the user that wants to access the homepage, you may
take the common part away, and use <xsl:import/> or <xsl:include/> to
include it in your stylesheet.
That way, a user who comes in for the first time on an article should
load: article.xml article.xsl common.xsl
A user who comes in for the first time on the homepage: home.xml
home.xsl common.xsl
And a user who switches from article to home: home.xml home.xsl (not the
common part)
And vice-versa: article.xml article.xsl (not the common part)
However, this may be counter-effective, as there is one more file to
load the first time, and one more file to load when you switch.
Real measuring of times should be done to decide on onw or the other
possibilities:
Rule of thumb:
If the common part is big enough, taking it apart would be good.
If the individual parts are small enough, integrating them (and the
common part) in a single file would be better.
Now, the question "how big is big?" and "how small is small?" are
impossible to answer without knowing:
- The "distance" between your server's location and your visitors location.
- Your visitors technology (56K, ISDN, xDSL, broader).
- Your server's bandwidth.
These factors, (and maybe also humidity ;-) will determine whether a
file is big or not and whether a file is small or not.
Good luck!
Antonio Fiol Bonnín
Joel Konkle-Parker wrote:
Yeah, those are two good points, but here's my thoughts on the subject. First,
being a review site, alot of our users enter the site through the article pages.
Now I know it's not asking much to download another few k worth of homepage
stylesheet, but everything counts, right? Of course, compression could solve
that problem... Unfortunately I don't know anything about it. A few tips please?
-joel
Quoting Antonio Fiol <fiol@xxxxxxxxxx>:
Thought 1:
Wouldn't the browser store the single stylesheet in its cache? I bet
so...
Thought 2:
If it is big, compress it ;-)
Compression support in browsers is older than XML support, so that
should be no problem.
Thought 1 + Thought 2 = Thought 3:
This formula is usually true:
compressed_size(file1+file2) <
compressed_size(file1)+compressed_size(file2)
In my company, we are experts at website optimizing. If you need
detailed advice (read: consultancy service), our company will be glad to
help you.
Antonio Fiol Bonnín
Joel Konkle-Parker wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Haha, yes, that's true. That's only for the front page, though, where
the only thing we need is the attribute page="home" to tell what page
it is. The real beauty of our system is with the articles
(http://www.ballsome.com/test/games/hardware/articles/20011107-1.xml).
We decided it would be better to split it up into two stylesheets,
one for the main pages, one for the article pages, so users don't
have to download a huge stylesheet for each page.
Any thoughts would be welcome, however.
- -joeljkp
- ---------------------------------------
http://www.ballsome.com
- -----Original Message-----
From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx
[mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of
Braumüller,
Hans
Sent: Friday, June 28, 2002 4:45 AM
To: 'xsl-list@xxxxxxxxxxxxxxxxxxxxxx'
Subject: RE: [xsl] How to throw transformation to browser
Hi Joel,
it makes no sense to use xml if you have all your content in your
xsl-stylesheet!
You have wrapped your entire html page in a template!
Greetings,
Hans Braumüller
- -- + --
Networking Artist
http://crosses.net
http://kunstserie.com
-----Ursprüngliche Nachricht-----
Von: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx
[mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx]Im Auftrag von Joel
Konkle-Parker
Gesendet: Mittwoch, 26. Juni 2002 16:42
An: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Betreff: Re: [xsl] How to throw transformation to browser
Actually, part of your statement isn't true. My site
(http://www.ballsome.com/test/) combines XML and XSLT
client-side, and works
with both IE 6+ and Netscape 6+. Perhaps it's something
specific to your code?
-joeljkp
Quoting Scott Purcell <spurcell@xxxxxxxxxxxxx>:
Hello,
I have a good xml file and a good xslt file. Up until today, we
have included a stylesheet reference in the xml to the xsl file
and let the
browser combine them for display. (Works only in IE).
I have been told to investigate combinining the two files
(xml and xsl)
server side. I investigated some avenues and came up with
Cocoon, and
Xalan. Are these the best ways to do this? Which is easiest to
implement.
Also a coworker mentioned that we may possibly do a dom
thing and build
the html dynamically? Does this make sense?
Thanks
XSL-List info and archive:
http://www.mulberrytech.com/xsl/xsl-list
- -------------------------------------------------------
http://www.ballsome.com
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use
<http://www.pgp.com>
iQA/AwUBPRxLcn880CLOJa2eEQKOYwCeOAEcDLksJ+cyLPRZZWGI5zjDtYgAnRko
Qw7Zxn4ulpne2MxoIhKv26Gf
=vS+/
-----END PGP SIGNATURE-----
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
Mac OS X
Linux/Unix
data server software 