Mercurial > urweb
comparison doc/manual.tex @ 1556:e1f5d9c4cc20
An abstract type of IDs
| author | Adam Chlipala <adam@chlipala.net> |
|---|---|
| date | Sat, 03 Sep 2011 12:51:05 -0400 |
| parents | d5c961c709f9 |
| children | df6a7a22760a |
comparison
equal
deleted
inserted
replaced
| 1555:d5c961c709f9 | 1556:e1f5d9c4cc20 |
|---|---|
| 1981 \mt{val} \; \mt{onKeyup} : (\mt{int} \to \mt{transaction} \; \mt{unit}) \to \mt{transaction} \; \mt{unit} \\ | 1981 \mt{val} \; \mt{onKeyup} : (\mt{int} \to \mt{transaction} \; \mt{unit}) \to \mt{transaction} \; \mt{unit} \\ |
| 1982 \mt{val} \; \mt{onMousedown} : \mt{transaction} \; \mt{unit} \to \mt{transaction} \; \mt{unit} \\ | 1982 \mt{val} \; \mt{onMousedown} : \mt{transaction} \; \mt{unit} \to \mt{transaction} \; \mt{unit} \\ |
| 1983 \mt{val} \; \mt{onMouseup} : \mt{transaction} \; \mt{unit} \to \mt{transaction} \; \mt{unit} | 1983 \mt{val} \; \mt{onMouseup} : \mt{transaction} \; \mt{unit} \to \mt{transaction} \; \mt{unit} |
| 1984 \end{array}$$ | 1984 \end{array}$$ |
| 1985 | 1985 |
| 1986 \subsubsection{Node IDs} | |
| 1987 | |
| 1988 There is an abstract type of node IDs that may be assigned to \cd{id} attributes of most HTML tags. | |
| 1989 | |
| 1990 $$\begin{array}{l} | |
| 1991 \mt{type} \; \mt{id} \\ | |
| 1992 \mt{val} \; \mt{fresh} : \mt{transaction} \; \mt{id} | |
| 1993 \end{array}$$ | |
| 1994 | |
| 1995 The \cd{fresh} function is allowed on both server and client, but there is no other way to create IDs, which includes lack of a way to force an ID to match a particular string. The only semantic importance of IDs within Ur/Web is in uses of the HTML \cd{<label>} tag. IDs play a much more central role in mainstream JavaScript programming, but Ur/Web uses a very different model to enable changes to particular nodes of a page tree, as the next manual subsection explains. IDs may still be useful in interfacing with JavaScript code (for instance, through Ur/Web's FFI). | |
| 1996 | |
| 1986 \subsubsection{Functional-Reactive Page Generation} | 1997 \subsubsection{Functional-Reactive Page Generation} |
| 1987 | 1998 |
| 1988 Most approaches to ``AJAX''-style coding involve imperative manipulation of the DOM tree representing an HTML document's structure. Ur/Web follows the \emph{functional-reactive} approach instead. Programs may allocate mutable \emph{sources} of arbitrary types, and an HTML page is effectively a pure function over the latest values of the sources. The page is not mutated directly, but rather it changes automatically as the sources are mutated. | 1999 Most approaches to ``AJAX''-style coding involve imperative manipulation of the DOM tree representing an HTML document's structure. Ur/Web follows the \emph{functional-reactive} approach instead. Programs may allocate mutable \emph{sources} of arbitrary types, and an HTML page is effectively a pure function over the latest values of the sources. The page is not mutated directly, but rather it changes automatically as the sources are mutated. |
| 1989 | 2000 |
| 1990 More operationally, you can think of a source as a mutable cell with facilities for subscription to change notifications. That level of detail is hidden behind a monadic facility to be described below. First, there are three primitive operations for working with sources just as if they were ML \cd{ref} cells, corresponding to ML's \cd{ref}, \cd{:=}, and \cd{!} operations. | 2001 More operationally, you can think of a source as a mutable cell with facilities for subscription to change notifications. That level of detail is hidden behind a monadic facility to be described below. First, there are three primitive operations for working with sources just as if they were ML \cd{ref} cells, corresponding to ML's \cd{ref}, \cd{:=}, and \cd{!} operations. |