«

I'm just getting started with XSLT to see if it can solve my task at
hand, and so far it looks really good. But I can't get my head around
how to present only a subset of a large data set at a time in the
browser.

Everything must take place on the client. The user opens the data.xml
file and, after the XSLT processing, sees the XHTML. Since the full
data set in data.xml can be quite large, I'd like to offer a familiar
Prev|1|2|3|...|Next type of page navigation. How can this be done?

I've searched on the Internet, but found it remarkably quiet on the
subject. Maybe I'm looking the wrong places. And perhaps it's not even
an XSLT issue?

The solution must support the mainstream browsers, not just IE.

Thanks for your time,
Joachim

On Apr 4, 10:34 am, "Bondo" <ostes...@hotmail.com> wrote:
> Everything must take place on the client. The user opens
> the data.xml file and, after the XSLT processing, sees
> the XHTML.

Poor choice. XHTML is not supported by MSIE. Transforming
on the client side should be avoided unless you know very
well what you're doing.

> Since the full data set in data.xml can be quite large,
> I'd like to offer a familiar Prev|1|2|3|...|Next type of
> page navigation. How can this be done?

If you want to transfer the entire data.xml to client and
transform it client-side, the question has nothing to do
with XML, since it boils down to implementing some
JavaScript-driven UI gimmick that would hide portions of
the resulting document. comp.lang.javascript is ===> that
way.

> I've searched on the Internet, but found it remarkably
> quiet on the subject. Maybe I'm looking the wrong places.
> And perhaps it's not even an XSLT issue?

Consider doing it the right way. Transform server-side,
serve HTML 4.01 Strict.

--
Pavel Lepin

On Apr 4, 10:05 am, p.le...@ctncorp.com wrote:
> On Apr 4, 10:34 am, "Bondo" <ostes...@hotmail.com> wrote:
>
> > Everything must take place on the client. The user opens
> > the data.xml file and, after the XSLT processing, sees
> > the XHTML.
>
> Poor choice. XHTML is not supported by MSIE. Transforming
> on the client side should be avoided unless you know very
> well what you're doing.
>
> > Since the full data set in data.xml can be quite large,
> > I'd like to offer a familiar Prev|1|2|3|...|Next type of
> > page navigation. How can this be done?
>
> If you want to transfer the entire data.xml to client and
> transform it client-side, the question has nothing to do
> with XML, since it boils down to implementing some
> JavaScript-driven UI gimmick that would hide portions of
> the resulting document. comp.lang.javascript is ===> that
> way.
>
> > I've searched on the Internet, but found it remarkably
> > quiet on the subject. Maybe I'm looking the wrong places.
> > And perhaps it's not even an XSLT issue?
>
> Consider doing it the right way. Transform server-side,
> serve HTML 4.01 Strict.
>
> --
> Pavel Lepin

Thanks for your prompt reply, Pavel. I understand your points -- I
failed to provide adequate details about the situation:

I have a native GUI application (.NET on the PC, Cocoa on the Mac)
that manipulate some data (photos and their meta data). As a function
in the application, the user must be able to locally generate web
pages of the data for later upload to a webserver (a web photo
gallery). The data set is exported to the XML file and then opened in
an embedded web view in the application. The user can also choose a
theme (a CSS file) that is referred to from within the XHTML output.
The user is ultimately looking at CSS-styled XHTML page which is what
I want.

This already works as a proof of concept, but I need to provide some
sort of navigation as mentioned in the original post.

Since this is a photo gallery, I suspect the amount of XML data will
perhaps be of the size of one full-size preview image, so bandwidth-
wise I don't have a problem transferring the whole XML file. But
perhaps there are other reasons not to.

So my dream scenario was simply to generate the XML file, containing
meta data and image paths, process that with an XSLT stylesheet and
have the resulting XHTML nicely presented with the mentioned page
navigation (index view: next page, previous page, jump to page, and
for detail view: next photo, previous photo, index).

As an alternative, I could generate a number of XHTML files, each
containing the relevant photo and data presentation, (still using
XSLT?), and upload these to the server.

Suggestions are highly appreciated.

Thanks in advance,
Joachim

On Apr 4, 11:54 am, "Bondo" <ostes...@hotmail.com> wrote:
> On Apr 4, 10:05 am, p.le...@ctncorp.com wrote:
> > On Apr 4, 10:34 am, "Bondo" <ostes...@hotmail.com>
> > wrote:
> > > Since the full data set in data.xml can be quite
> > > large, I'd like to offer a familiar
> > > Prev|1|2|3|...|Next type of page navigation. How can
> > > this be done?
>
> > If you want to transfer the entire data.xml to client
> > and transform it client-side, the question has nothing
> > to do with XML, since it boils down to implementing
> > some JavaScript-driven UI gimmick that would hide
> > portions of the resulting document.
> > comp.lang.javascript is ===> that way.

[...]

> Since this is a photo gallery, I suspect the amount of
> XML data will perhaps be of the size of one full-size
> preview image, so bandwidth-wise I don't have a problem
> transferring the whole XML file. But perhaps there are
> other reasons not to.
>
> So my dream scenario was simply to generate the XML file,
> containing meta data and image paths, process that with
> an XSLT stylesheet and have the resulting XHTML nicely
> presented with the mentioned page navigation (index view:
> next page, previous page, jump to page, and for detail
> view: next photo, previous photo, index).

There are many possible solutions for the problem you've
described, and there are simply too many imponderables to
tell which one would be best (and I don't even mention the
fact that decisions like that are always subjective to an
extent, depending on your biases, preferences and
practices).

But as I said, in case you decide to publish the resulting
gallery or whatever as a single XML document, transforming
it client-side, the problem of paged interface will lie in
the domain of client-side scripting, and will have nothing
to do with XML, probably relying on HTML/CSS DOM
manipulation to achieve the desired effect.

> As an alternative, I could generate a number of XHTML
> files, each containing the relevant photo and data
> presentation, (still using XSLT?), and upload these to
> the server.

Replace XHTML with HTML, and that would be the solution I
would be naturally gravitating towards, thanks to *my*
biases and practices. YMMV.

The simplest argument in favour of this approach is that if
you're developing an application that exports some data, it
is usually a good idea to do it in as interoperable way as
possible, and in my experience, there's nothing that beats
static HTML+CSS's readiness for deployment pretty much
anywhere from litehttpd to PWS to Apache to IIS (as well as
its accessibility to a wide UA base).

--
Pavel Lepin

On Apr 4, 2:19 pm, p.le...@ctncorp.com wrote:
> Replace XHTML with HTML, and that would be the solution I
> would be naturally gravitating towards, thanks to *my*
> biases and practices. YMMV.
>
> The simplest argument in favour of this approach is that if
> you're developing an application that exports some data, it
> is usually a good idea to do it in as interoperable way as
> possible, and in my experience, there's nothing that beats
> static HTML+CSS's readiness for deployment pretty much
> anywhere from litehttpd to PWS to Apache to IIS (as well as
> its accessibility to a wide UA base).

Thanks for taking the time to reply, I really appreciate that.

I think going with a static(X)HTML+CSS files approach is the way
forward. This leaves me with 2 general questions at this time:

1) Can XSLT output to a file or in some other way so that I can grab
the HTML data?
2) If I have 80 photos, 8 on each page, do I generate an XML file 10
times in order to generate the (X)HTML 10 files, or can XSLT do it in
one go?

Finally, I'm not sure why you shy away from XHTML (IE issues, you
say). I've made several sites in XHTML 1.0 Strict, and IE and other
major browsers display the pages just fine.

Happy Easter,
Joachim

On Apr 4, 7:05 pm, "Bondo" <ostes...@hotmail.com> wrote:
> On Apr 4, 2:19 pm, p.le...@ctncorp.com wrote:
> > Replace XHTML with HTML, and that would be the solution
> > I would be naturally gravitating towards, thanks to
> > *my* biases and practices. YMMV.
>
> 1) Can XSLT output to a file or in some other way so that
> I can grab the HTML data?

Normally, you use your XSLT API to create a Processor
instance, feed it a DOMDocument source tree and get a
DOMDocument or DOMDocumentFragment tree as a result.
Serializiation is usually up to you (that is, up to the DOM
API you're using). Of course, that's just one of the
possible scenarios, it is entirely possible to use a
standalone XSLT processor, for example, either feeding it
XML document files and getting transformation results as
files as well, or using pipes for I/O.

> 2) If I have 80 photos, 8 on each page, do I generate an
> XML file 10 times in order to generate the (X)HTML 10
> files, or can XSLT do it in one go?

XSLT1 processors may only generate one result tree per
transformation. There are ways to work around this (for
example, if you're using a DOM+XSLT API, you may try a
transformation that would return all the results glued
together, then use DOM to yank the appropriate fragments
out of it and serialize them separately).

XSLT2 processors should support multiple result trees, but:

- you'll have to either ask someone else about it or look
it up yourself in the docs/specs;
- the only readily available seemingly-fully-compliant
XSLT2 processor that I'm aware of is Saxon8, and I'm not
certain how hard it would be to use it as a
transformation engine under .NET framework. Again, ask
someone else or, well, GIYF.

> Finally, I'm not sure why you shy away from XHTML (IE
> issues, you say). I've made several sites in XHTML 1.0
> Strict, and IE and other major browsers display the pages
> just fine.

Again, GIYF. In short, XHTML is unsupported by MSIE. To
make it work you have to serve it as invalid HTML with
text/html MIME type. Being invalid it triggers quirks mode.
Once you're in quirks mode, you're in what C++ crowd calls
Undefined Behavior Land. You don't want to be in UBL, just
trust me on this one.

I don't even mention the fact that serving XHTML as
text/html places certain constraints on its serialization,
which mean you cannot process it as pure XML anymore.

I don't even mention the fact that to get any use out of
it, you have to serve it as application/xhtml+xml to
Gecko-baseds, which requires a small bit of Apache mojo to
pull of and strikes me as slightly silly.

All in all, using XHTML for public websites is ugly,
inelegant, useless and prone to causing Developer Brain
Explosion Syndrome at worst possible moments. The only
place where XHTML has its uses ATM is as an internal
representation of something you intend to actually serve
as HTML. There are advantages in it being XML, and
transforming XHTML 1.0 Strict to HTML 4.01 Strict is pretty
much effortless, the main difference between the two being
that one is an XML application, and the other is an SGML
application.

--
Pavel Lepin

> All in all, using XHTML for public websites is ugly,

Hmmm.

There's really little or no excuse for a browser not accepting XHTML
these days. I grant that for business-critical websites you may need to
code down to the limitations of the customer's preferred browser... but
there comes a point at which we, as customers ourselves, need to start
pressuring the vendors to provide proper support for modern standards.

Remember, W3C's intent was that XHTML replaces the old SGML-based HTML.

Nothing's wrong with XHTML. Demand working browsers.


Meanwhile, even if you have to serve old-fashioned HTML, there's
something to be said for using XHTML on the server end and converting it
to HTML only at final serialization onto the wire.


--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry

On Apr 5, 3:19 pm, Joe Kesselman
<keshlam-nos...@comcast.net> wrote:
> > All in all, using XHTML for public websites is ugly,
>
> There's really little or no excuse for a browser not
> accepting XHTML these days.

Oh, when was the last time Microsoft needed excuses for
anything? Excuses are for small businesses anyway.
Corporations use visions instead.

> I grant that for business-critical websites you may need
> to code down to the limitations of the customer's
> preferred browser...

If we're talking about public websites, customer's
preferred browser is unknown. At best we know the content
types the UA in question finds acceptable (and then some of
them lie shamelessly; okay, scratch that, I've no
supporting facts on this count, it's just that I find the
entire situation extremely annoying).

> but there comes a point at which we, as customers
> ourselves, need to start pressuring the vendors to
> provide proper support for modern standards.

Right. We might as well start kicking the dead whales down
the beach.

Actually, since we started talking about standards, Gecko
engine, for one, has quite a few ugly blotches all its own
on its face. I actually set that cute Foxy saying 'Please
don't hurt the web. Use open web standards' as my
wallpaper, but the web developers still can't push the
Gecko Dev Team into fixing that ugly, standards-incompliant
wart re 4096 octets max size on text nodes. Three years and
counting.

I'm pretty certain KHTML et al have more than enough
skeletons buried in their sources as well.

> Remember, W3C's intent was that XHTML replaces the old
> SGML-based HTML.

I agree fnord completely. In fact, I was thoroughly
disgusted when W3C chartered HTML 5 WG. Now, I don't know
about pushing Microsoft, but maybe we *could* push W3C into
ending this nonsense once and for all?

> Meanwhile, even if you have to serve old-fashioned HTML,
> there's something to be said for using XHTML on the
> server end and converting it to HTML only at final
> serialization onto the wire.

To be fair, there's nothing wrong with using HTML 4.01
Strict--assuming you're using it properly. It would be
great if we could switch to serving XHTML 1.0 Strict and
get away with it, but at the moment--we can't.

And if we're using HTML anyway, isn't it a bit more sane
to stick to *one* markup language instead of catering to
every UA's idiosyncrasies? HTML4.01, for all its faults,
is a working, workable standard. XHTML1 isn't. A shame,
really, but them's the breaks.

--
Pavel Lepin