XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] RE: James Clark: XML versus the Web

On Wed, Dec 1, 2010 at 11:43 AM, Michael Kay <mike@saxonica.com> wrote:
> On 01/12/2010 16:45, Rob Koberg wrote:
>>
>> Another big problem I forgot to mention is handling browser events.
>> XML or XML apps (XSL) in the browser cannot catch browser events.
>>
>
> Yes, there's always been an uncomfortable asymmetry here - XSLT to handle
> the output, XForms to handle the input. Which doesn't really work well in an
> Ajax kind of world. I'd love to do something more integrated. In principle
> XSLT is an event-based language so it ought to be possible to find a way to
> make it handle user-input events (or data arriving from the server) by
> firing appropriate template rules. But I've no idea how this would look in
> detail.
>

Many years ago I suggested to the Cocoon project that it should be
possible to use XSLT as the Flow controller logic (instead of
Javascript with continuations) on the server side.  Basically, the
idea was that an XSLT template would be called with some XML
representation of the current request context and it would then spit
out the name of the XSLT pipeline to invoke to process it, though for
simple use cases you could obviously do it all within the initial flow
control processing pipeline.  Never did get any traction, but I still
think it would be pretty elegant...

-- 
Peter Hunsberger


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS