On 3/12/2010 10:51 AM, Szabó Árpád Zoltán wrote:
User experience first. Developer convenience close second.
I believe it's not hard to see the reason in these sentences. I've
borrowed (and simplified) them from Google Web Toolkit's design
principles, which can be roughly defined as a client side (i.e.
JavaScript) web application framework.
Docbook's web presentation nowadays relies on the chunked html files
with a table of contents (besides bightml), which can be arranged into a
html frameset, and main theme of its working is this: user clicks on
table of contents entry, browser gets html document from server and display.
I'm wondering about an another theme of working: user clicks on table of
contents entry, browser applies xslt stylesheet to the previously
downloaded docbook xml file, and display.
The potential of this method relies in the fact that there's no need for
browser-server communication - after the stylesheet and docbook
documents are loaded. Which is the disadvantage of the method of course:
user needs to wait for the whole document to download even if all she
needs is a part or a chapter only.
I say potential, because some other factors need to be considered to
make it work: the xslt transformation needs to be actually faster then
response from the server.
Then there's of course the question of browser compatibility of xslt
processing. In this regard, I've prepared a small proof of concept
example, using Google Web Toolkit's architecture. It's available at:
http://docbook-publishing.appspot.com/DocBookPublishing.html
The files there are simple but valid DocBook documents, the table of
contents are custom-made, so is the little xslt file which the processor
applies every time the user clicks on a table of contents item.
I've tried it in several different browsers ( recent versions of Mozilla
Firefox, Internet Explorer, Opera, Safari, Google Chrome ), and it seems
to work. An my impression is that it's really fast. (Again, I don't
count the initial load time of the document - I believe this can be made
acceptable with proper progress indication.)
Now the next step would be to apply this on arbitrary DocBook documents.
I can see some problems to solve. First, table of contents generation.
This should be very similar to that of HTMLHelp's TOC. I'm wondering
whether the "links" to different parts of the document could be xpath
path definitions instead of id-s of tags. This way those parts of the
document could be referred too, which don't hold id attribute (id
generation not being an option here: I don't think we should assign id-s
to the document's parts at this point).
Second, html formatting of selected parts. Main problem to solve here,
that I can see, is that for the sake of the xslt processors, the
stylesheet should be a single file. (Talking about developer
convenience, huh?) (Browsers' xslt processors can handle loading of
imported stylesheets, but something prevents it from loading documents
dynamically, around i18n. Maybe just the paths, I haven't investigated
thoroughly yet.) And if I concatenate all the files required to html
transformation, the size is around 1.4 megabyte.
So this is where I'm at now. Thanks for following my little train of
thoughs, I'm really interested in your opinions. (Or tell me if I've
invented the wheel or hot water or something like that, or it worths
nothing because...)
Yours,
Arpad
----
Szabó Árpád Zoltán
from Hungary
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
That looks pretty slick.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
