Anubis / Anubis

Commit c03918397b6a70d07e182ebbbb606c9ddcc5460e

Authored by Alain Prouté
1 parent 26ece201

*** empty log message ***

Showing 6 changed files with 95 additions and 56 deletions   Show diff stats
Inline Side-by-side
anubis_dev/library/compil_all.anubis
  Show/Hide comments   View file @c039183
1 1  
2   - *Project* The Anubis Project
  2 + *Project* Anubis
3 3  
4   - *Title* Automatic generation of all library source files.
  4 + *Title* Automatic compilation of all library source files.
5 5  
6 6 *Copyright* Copyright (c) Alain Prouté 2005.
7 7  
8 8  
9 9  
10 10  
11   - *Created: 2006 01 02
  11 + *Created* 2006 01 02
12 12 *Author* David René
13 13 *Author* Alain Prouté
14   -
15   - Compile all examples
  14 +
  15 + *Status* Released 2006 05 28
  16 +
  17 + Compile all files.
16 18  
17 19 read examples/args.anubis
18 20 read examples/conditional_examples.anubis
... ... @@ -24,17 +26,18 @@ read examples/kbd.anubis
24 26 read examples/ls.anubis
25 27 read examples/mkdir_test.anubis
26 28 read examples/OOCounter.anubis.cpp
27   -read examples/peano.anubis
  29 +read examples/logic/peano.anubis
  30 +read examples/logic/church_integers.anubis
28 31 read examples/restart.anubis
29 32 read examples/saturate_example.anubis
30   -read examples/syracuse.anubis
  33 +read examples/mathematics/syracuse.anubis
  34 +read examples/mathematics/runge_kutta.anubis
31 35 read examples/try_protect.anubis
32   - read examples/watt.anubis
  36 + read examples/watt.anubis does not compile, but this is normal. See the file itself.
33 37 read examples/cryptography/sha1.anubis
34 38 read examples/graphism/diaporama.anubis
35 39 read examples/graphism/paint.anubis
36 40 read examples/graphism/paint2.anubis
37   -read examples/graphism/runge_kutta.anubis
38 41 read examples/graphism/show_image.anubis
39 42 read examples/graphism/try_window.anubis
40 43 read examples/network/client_server.anubis
... ...
anubis_dev/library/examples/church_integers.anubis renamed to anubis_dev/library/examples/logic/church_integers.anubis
  Show/Hide comments   View file @c039183
anubis_dev/library/examples/peano.anubis renamed to anubis_dev/library/examples/logic/peano.anubis
  Show/Hide comments   View file @c039183
anubis_dev/library/examples/graphism/runge_kutta.anubis renamed to anubis_dev/library/examples/mathematics/runge_kutta.anubis
  Show/Hide comments   View file @c039183
anubis_dev/library/examples/syracuse.anubis renamed to anubis_dev/library/examples/mathematics/syracuse.anubis
  Show/Hide comments   View file @c039183
anubis_dev/library/web/making_a_web_site.anubis
  Show/Hide comments   View file @c039183
1 1  
2   - *Project* The Anubis Project.
  2 + *Project* Anubis
3 3  
4 4 *Title* Making interactive Web sites.
5 5  
... ... @@ -12,17 +12,19 @@
12 12  
13 13  
14 14 *Overview*
15   - In this file we propose simple tools for making well structured interactive and secured
  15 +
  16 + In this file we propose simple tools for making well structured interactive and secured
16 17 web sites.
17 18  
18 19  
19 20 ----------------------------------- Table of Contents ---------------------------------
20 21  
21 22 * (1) Structure of a web site.
22   - ** (1.1) Overview.
23   - ** (1.2) What web pages are made of.
24   - ** (1.3) Actions.
25   - ** (1.4) States.
  23 + ** (1.1) Three sorts of data.
  24 + ** (1.2) How requests are handled.
  25 + ** (1.3) What web pages are made of.
  26 + ** (1.4) Actions.
  27 + ** (1.5) States.
26 28  
27 29 * (2) Carrying on.
28 30 ** (2.1) Describing your web sites.
... ... @@ -48,23 +50,49 @@ read mime.anubis
48 50  
49 51 * (1) Structure of a web site.
50 52  
51   - First of all we need to explain what a web site should be made of. Ideally, the client
52   - should see the web site working as any other interactive computer software. So, it
53   - should be clear that a 'session' (i.e. a visit to the web site, including the
54   - consultation of several pages) is some kind of conversation between the client and the
55   - web site, and that the web site should maintain a 'current state' of this conversation.
56   - At each new request (click) from the client, this state must be updated.
  53 + First of all we need to explain what a web site should be made of. Ideally, the
  54 + visitor (also called the 'client') should see the web site working as any other
  55 + interactive computer software. So, it should be clear that a 'session' (i.e. a visit
  56 + to the web site, including the consultation of several pages) is some kind of
  57 + conversation between the visitor and the web site, and that the web site should
  58 + maintain a 'current state' of this conversation. At each new request (click) from the
  59 + visitor, this state must be updated. This whole conversation is called a 'session' and
  60 + should not be confused with a single request.
  61 +
  62 +
  63 +
  64 + ** (1.1) Three sorts of data.
  65 +
  66 + All the data needed for putting a web site at work may be dispatched into three
  67 + categories:
  68 +
  69 + 1. Constant data (data that never change). These data may be hard coded into the
  70 + Anubis source files of the web site.
  71 +
  72 + 2. Permanent data (data which always exist independantly of the users connected to
  73 + the web site). These data are normally recorded into data bases.
  74 +
  75 + 3. Session data (data which depend on a particular visitor and which exist only
  76 + during the time he visits the web site). These data are stored into so-called
  77 + 'states'.
  78 +
  79 +
  80 + It is important to determine which data belongs to which category. This is part of your
  81 + design decisions.
  82 +
57 83  
58 84  
59   - ** (1.1) Overview.
  85 + ** (1.2) How requests are handled.
60 86  
61   - The data which are stored into the state should be considered as 'session data'. They
62   - do not encompass 'permanent data', which are typically stored into a data base. We
63   - want to separate the following two functionalities (which are used at each request
  87 + We want to separate the following two functionalities (which are used at each request
64 88 (click) during a single session):
65 89  
66   - - computing the new state from the previous state and from the client request,
67   - - computing the page to be sent to the client from the new current state.
  90 + - computing the new state from the previous state and from the client request, and
  91 + updating the data base,
  92 +
  93 + - computing the page to be sent to the client from the new current state and from
  94 + the informations in the data base.
  95 +
68 96  
69 97 The next picture shows the structure we have in mind:
70 98  
... ... @@ -73,7 +101,7 @@ read mime.anubis
73 101 .-------------------| client |<--------------.
74 102 | .-----------------| | |
75 103 | | previous state +---------+ |
76   - | | name |
  104 + | | name (if any) |
77 105 | | | client side
78 106 ............................................................................
79 107 | | | server side
... ... @@ -86,33 +114,33 @@ read mime.anubis
86 114 +---------------+ +---------------+ +--------------+
87 115 ^ | | ^ ^ ^ ^ ^
88 116 | | | | | | | |
89   - | | `--------------------+--------------------' |
  117 + | | `--------------------+--------------------' | |
90 118 | | new state | | |
91   - read | `------------------------+--------------------'
  119 + read | `------------------------+--------------------' |
92 120 write | new state name |
93   - update V
  121 + update V |
94 122 +-----------+ |
95   - | data base |<- - - - - - - - - - - - - - - - - - - - - -
96   - +-----------+ be careful with this link
  123 + | data base |--------------------------------------------'
  124 + +-----------+ read only
97 125  
98 126  
99 127 When the client begins a session, there is no previous state. In this case, a default
100 128 'initial state' is used instead.
  129 +
  130 + The data base may be updated by 'compute state' box, but should not be update by the
  131 + 'compute page' box. The 'compute page' box should be allowed only to read the data
  132 + base.
101 133  
102   - It may be important that computing the HTML page is performed only from the new state
103   - (and its name) not using the data base. This is because the data base may have been
104   - updated by another client since the computation of the new state. Doing another way
105   - could create an inconsistency between the page sent to the client and its current state
106   - recorded on the server's disk.
107   -
108   - In this file, all the above stuff is defined. You just have to provide the function for
109   - computing a new state (compute state) and the function for computing the page (compute
110   - page) from the new state. You don't have to worry about state names, saving and
111   - retrieving states and the like.
  134 + In this file, all the above stuff is defined, except the 'compute state' and 'compute
  135 + page' boxes. You just have to provide the function for computing a new state (compute
  136 + state) and the function for computing the page (compute page) from the new state. You
  137 + don't have to worry about state names, saving and retrieving states and the like.
112 138  
113 139  
114 140  
115   - ** (1.2) What web pages are made of.
  141 +
  142 +
  143 + ** (1.3) What web pages are made of.
116 144  
117 145 What the client can see in his browser's window may be called a 'page'. Within a page,
118 146 we have several sorts of components:
... ... @@ -123,7 +151,8 @@ read mime.anubis
123 151 - 'actioners', which, when clicked upon, open a connection with our web site; they
124 152 may appear as links or buttons, etc...
125 153  
126   - - 'foreign links', which when clicked upon, open a connection with another web site.
  154 + - 'foreign links', which when clicked upon, open a connection with another web site
  155 + (or ours eventually).
127 156  
128 157 Of course, what an actioner does is just ask our web site to perform an action. To that
129 158 end, the actioner essentially sends the name of the action to be performed. However, it
... ... @@ -136,10 +165,10 @@ read mime.anubis
136 165 operands.
137 166  
138 167 Restrictions must be put on the use of all theses gadgets. Indeed, for example,
139   - putting a form within another form is meaningless. HTML does not explicitly forbid such
140   - things, but the client's browser may be seriously disturbed. In this file, we propose
141   - an interface to the HTML language, which forbids such meaningless things, simply by
142   - imposing a strict typing of HTML concepts.
  168 + putting a form within another form is officially meaningless in HTML, and the client's
  169 + browser may be seriously disturbed by this. In this file, we propose an interface to
  170 + the HTML language, which forbids such meaningless things, simply by imposing a strict
  171 + typing of HTML concepts.
143 172  
144 173 Each web site may be accessible through two communication channels:
145 174  
... ... @@ -175,16 +204,21 @@ read mime.anubis
175 204 | |
176 205 +-------------------+
177 206  
178   -
  207 +
  208 + Notice that actioners need no be necessarily put into forms. In that case, they work as
  209 + ordinary links, but they still may receive operands as we shall see.
179 210  
180 211  
181   - ** (1.3) Actions.
  212 +
  213 +
  214 + ** (1.4) Actions.
182 215  
183 216 The client opens a new connection with our web site whenever he clicks on an
184 217 actioner. The result is that a request is sent, essentially made of a list of 'web
185 218 arguments'. Each web argument is a pair (name,value). One of these web arguments, the
186 219 'action' web argument (whose name is "a"), determines the action to be performed. The
187   - other web arguments (not including "s") are the operands for this action.
  220 + other web arguments (not including "s", used to identify the state) are the operands
  221 + for this action.
188 222  
189 223 Hence, the 'compute state' box in the picture above, splits naturally into as many
190 224 sub-boxes as there are actions. For this reason, we define the following type for
... ... @@ -262,6 +296,7 @@ public define Web_Action($State)
262 296 (HTTP_Info h, List(Web_arg) l, $State s) |-> do_it(l,s)).
263 297  
264 298  
  299 +
265 300 When you define your web site, you must provide the list of all the actions of the
266 301 site. When a new state has been computed, a graphical representation of this state
267 302 must be sent to the client. To that end, you must provide a function (named below
... ... @@ -276,16 +311,17 @@ public type HTML_Page:...
276 311  
277 312 It should be clear that states and pages are deeply linked together. Indeed, we really
278 313 understand the page shown to the client as a representation of the current state of the
279   - conversation between the client and the web site.
  314 + conversation between the client and the web site, but also containing informations
  315 + taken from the data bases.
280 316  
281 317  
282 318  
283 319  
284 320  
285   - ** (1.4) States.
  321 + ** (1.5) States.
286 322  
287   - Now, we explain how to define the type (say 'State') to be used as an instance of the
288   - type parameter '$State'.
  323 + Now, we explain how you can define the type (say 'State') to be used as an instance of
  324 + the type parameter '$State'. The following is just a suggestion.
289 325  
290 326 Each state determines a page (since 'compute_page' computes a page from a
291 327 state). However, some components of the state may be independant of the page. It may be
... ...