Cart
[Home] [By Thread] [By Date] [Recent Entries]
On 02/12/2010 04:53, Peter Hunsberger wrote: > On Wed, Dec 1, 2010 at 6:19 PM, Michael Kay<mike@s...> wrote: >> 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. > This is why I mentioned continuations... Basically, you use a model > where a call path from the server to the client browser returns back > to the same spot in the template after the client does a submit. State > is maintained on the server in a call tree. Reminds me that in ICL in the 1980s we had a 4GL called ApplicationMaster in which the application was written conversationally - that is, it called read() when it wanted user input - but was compiled to an event-driven inversion so it could run in a transaction processing monitor where the actual run-time code checkpointed session state automatically when waiting for input, to be restored when the user got around to responding. Like continuations, except that the programmer doesn't have to know about it. I think that's a great way to implement an application that wants to control the dialog structure (and I know there's something a bit similar in Cocoon). I'm not quite sure how well it translates to an event-driven dialog structure that's under the control of the user. But certainly, the advantage of a language like XSLT is that such compilation tricks really should be possible, because the state isn't too complicated. Indeed, it ought to be possible to compile a single stylesheet into a server-side component and a client-side component so the application developer doesn't have to worry about the low-level AJAX protocols. Michael Kay Saxonica
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
