Re: [xml-dev] Interactive XSLT [was RE: James Clark: XML versus the Web]

[Dimitre Novatchev <dnovatchev@gmail.com>]

Didn't press "reply all" :(



On Wed, Dec 1, 2010 at 8:06 PM, Dimitre Novatchev <dnovatchev@gmail.com> wrote:
> On Wed, Dec 1, 2010 at 4:19 PM, Michael Kay <mike@saxonica.com> wrote:
>> On 01/12/2010 23:51, Dimitre Novatchev wrote:
>>>
>>> We just need a standard F&  O function for this.
>>>
>>> See how this was done in the "XSLT calculator" 7 years ago:  :)
>>>
>>>
>>> http://fxsl.sourceforge.net/articles/xslCalculator/The%20FXSL%20Calculator.html#6._Putting_it_All_Together_-_the_XSLT_Calculator
>>>
>>> Although this is a desktop app, the same design can be applied towards
>>> a browser scripting application.
>>>
>> But this looks to me like a conversational user interface where the program
>> asks the user a question and waits for a reply. This is very different from
>> an event-based user interface where the sequence of events is controlled by
>> the user. What I'm trying to imagine is some kind of way of associating XSLT
>> templates with user interface events so the dialog structure is
>> user-controlled. Of course this raises question about how state is
>> maintained; I don't have any well-formulated thoughts on this. There must be
>> some relationship with XForms here, but I'm not sure what it is.
>
> Why this is possible (saxon:threads comes to mind), yes, it seems
> challenging for the different threads to share dynamically created
> data.
>
> On the other side, my initial example does accomodate  (although
> minimally) different user interactions.
>
 In this code:

  <!-- Start the calculator dialog with zero displayed -->
  <xsl:template match="/">
    <xsl:call-template name="keepDialog">
      <xsl:with-param name="pInput"
                      select="myObj2:dispResult('0')"/>
    </xsl:call-template>

    <xsl:value-of select="'Bye!'" />
  </xsl:template>


 the end of the transformation is result of the user pressing the "Quit" button.

 Also, the main template "keepDialog" can in practice respond to any
 user action (pressing of any button or key sequence) -- the fact that
 it isn't multithreaded is just an implementation detail.

 So, the idea is that the ui() function will return a data structure,
 containing any user action in addition to user input. This is like
 maintaining several "channels" of communication -- each with its own
 meaning and priority. Once the channels are analyzed, the appropriate
 reactions (possibly multiple) are carried out (possibly in a
 multi-threaded way using something like saxon:threads).

 So, this isn't a problem. There is only a problem if we need
 asynchronous communication. Maybe looking at Reactive Extensions for
 .NET  could give us some ideas?

 http://msdn.microsoft.com/en-us/devlabs/ee794896.aspx


-- 
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play