RE: [xsl] Site structured on XSLT.

Wendell

Thanks for your reply. I wasn't able to answer it since yesterday was national holiday down here.
I'll take a look at LMNL.org asap. 
Mainly I would like to structure it with the concept that there's no server (since I don't have one where to run it), and though it will do it client side. This shouldn't be an issue when we move to it latter on. So, data file should be in a directory and processed in the client. I don't think batch mode should be the approach since this will limit the capability of dinamically change the environment. 

Regards, Claudio.


-----Original Message-----
From: Wendell Piez [mailto:wapiez@xxxxxxxxxxxxxxxx]
Sent: Martes, 08 de Julio de 2003 05:43 p.m.
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] Site structured on XSLT.


Claudio,

At 03:58 PM 7/8/2003, you wrote:
>As I've been addressing this issue tangencially, and I understand a little 
>bit where I want to be in my next step, I would like to know if somebody 
>can help me on this task: I would like to create a site entirely using XSLT.

That's cool.

>My initial approach was, as I said efore, an HTML with frames, which loads 
>a DOM,
>that passes parameters to an XSLT, which is run and fills the HTML fields.

This is fine -- but going down this road, you are in advance (considerably 
in advance!) of where web standards have specified behaviors on clients. 
There are simply no vendor-neutral specifications for loading an HTML 
document with a DOM, invoking an XSLT process (with or without parameters), 
and "fill[ing] the HTML fields".

It can certainly be done in a platform-dependent way: there are web 
browsers sufficiently advanced that you can achieve this kind of processing 
in the client. But the technology deployed simply won't work in another 
browser. "Must use IE8 to view" is a poor way to publish your stuff to the 
world.

It's this current status quo, combined with the large number of web users 
who don't have even the latest browsers, that leads many developers not to 
push too far ahead of this bleeding edge, but instead achieve the stated 
goal through other means.

And in fact, you'll find that web sites "created entirely using XSLT" are 
more and more common -- but using a server-side process, or batch process, 
as we have described earlier in this thread -- rather than relying on the 
browser to do the XSLT processing.

>This is the actual structure contains issues like Data Islands, Java 
>Script, and others, and it stands like this:
>
><HTML>
>
>         <body>
>                 onLOAD javascriptfunction
>
>                 <XML>
>                         sytlesheet
>                 </XML>
>         </body>
>
>         <script>
>                 Define javascriptfunction
>                 that loads dom and strlesheet.
>         </script>
>
></HTML>
>
>Constraints are:
>         a) Use simple XSLT 1.0 commands.

This won't allow that. The script that loads the DOM and stylesheet won't 
be XSLT, and will be browser-dependent.

>         b) Able to access dynamically an XML structure in a separate 
> directory where data file is kept.

On the client? Or over the network, using http? If the former, you're going 
to have hard problems with security issues. If the latter, it can be done, 
but this is another reason why processing the entire thing on the server 
might be preferable (then the file is just there).

>         c) Implement a good and simple approach that splits data, from 
> presentation, from data access.

Can be done even running server-side or in batch mode; it's just an aspect 
of good design.

>         d) Remove the data islands.

Don't like them anyway. Design pure XML, then convert to pure HTML. No 
hybrid formats. Can be done on the server, in a batch, whatever.

>         e) Reduce the usage of any javascript or any other external 
> function to the minimum possible.

This sounds like you want a server-side solution. You're simply not going 
to achieve processing on the client without some kind of "glue" language to 
control it.

Take a look at LMNL.org. It's a plain vanilla HTML web site, uses frames 
and CSS. It's entirely generated from XML source using XSLT -- no 
Javascript, no data islands. The transformation happens at home on a 
laptop, on the odd weekend when there's been a change to the documents. 
Then the changed files get uploaded to a very old-fashioned server, and 
voila. (Why generate from XML source? because it's easier to author, 
validate, quality-check and maintain, for one; it makes it trivial to 
change the site's look-and-feel anytime, for another, etc. etc.)

Others can point you to sites that are similarly generated dynamically from 
XML on a server, in response to specific requests for pages.

I hope this helps,
Wendell



======================================================================
Wendell Piez                            mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                    Direct Phone: 301/315-9635
Suite 207                                          Phone: 301/315-9631
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
   Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
<- Previous	Index	Next ->
RE: RE: [xsl] Site structured on XS, cknell	Thread	RE: [xsl] Site structured on XSLT., Claudio Russo
Re: [xsl] java Regex call, David Carlisle	Date	RE: [xsl] Site structured on XSLT., Claudio Russo
	Month
<-prev [Thread] next->	<-prev [Date] next->
Month Index \| List Home