forked from cherokee/webserver
/
dev_ctk.txt
560 lines (435 loc) · 18.5 KB
/
dev_ctk.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
== link:index.html[Index] -> link:dev.html[Development info] -> Cherokee Tool Kit
Introduction to CTK
-------------------
CTK, the Cherokee ToolKit, is a toolkit originally implemented to
develop Cherokee-admin in Python. It aims to deliver all the fanciness
of modern web right to the hands of Python developers.
CTK was developed to allow a fast development pace for Cherokee-Admin,
while providing a modern & feature-rich web interface that fulfilled
two essential requirements:
. Having a maintainable code-base
. Lowering the entry barrier to encourage participation in the development of Cherokee.
CTK was developed with Cherokee-Admin in mind, but it is not confined
to Cherokee, and in fact some of its widgets aren't even used in
Cherokee-Admin. It is currently used in every Cherokee release since
1.0, and is also used by some other third party applications.
Rationale
~~~~~~~~~
The design of CTK makes developing rich web-applications easy and fun
once you've understood the rationale behind it. Of course, some
complex tasks might require a bit of extra effort, but overall you'll
be gladly surprised by the ease of development.
Everything is a widget in CTK. Everything, from the web page itself to
any web element you might want to use, is a widget. You just have to
instantiate a top-level widget (a container), add widgets to it, and
let CTK take care of the rest. This includes asynchronous transfers,
submitting and validating forms in the background, event binding to
refresh the render of specific sections, and many other goodies you
would expect in a modern web application. Just pick a widget from the
extensive Widget Hierearchy provided by CTK, and append it to your
container.
Some of the things provided by CTK:
. URL driven render
. URLs mapped to functions or classes
. Render as response (a page, or content)
. Complete requests as results of a render, no partial results support
(sent as render)
. Widget Hierarchy inspired in desktop-app toolkits like GTK+ or QT.
What make CTK particularly interesting is that everything can be
written and maintained in Python.
Overview
~~~~~~~~
CTK will communicate your application with the web server through the
well known SCGI protocol, so you'll just have to setup an information
source in Cherokee and access it through the SCGI handler to get
started.
CTK-run
^^^^^^^
You can quickly try out your CTK applications by using the provided
CTK-run command. It will launch an instance of Cherokee listening to
port 9091, and it will be set to communicate with any SCGI application
running on port 8000.
The syntax of CTK-run is pretty straight forward:
----
python CTK-run [-d /path/to/CTK] <file.py>
-----
Basic CTK app
^^^^^^^^^^^^^
The skeleton of a CTK application is also fairly simple:
. Import CTK into your app.
. Publish some URLs and define what functions or classes should take
care of rendering such URLs, handle submissions, etc.
. Add widgets
. Define a custom commit function if needed
. Specify a port in which CTK must be launched and let it run.
Simple examples
~~~~~~~~~~~~~~~
The examples listed here will set port 8000 for SCGI, so all of them
can be run quickly using CTK-run. Just copy and paste the scripts, and
launch them with CTK-run. You will be able to check the output by
accessing http://localhost:9091 on your web-browser.
Besides the basic examples listed here, you can take a look at
CTK/tests to see some very basic examples using CTK. Those have been
written as quick tests for some of the basic widgets. Any of them can
be run using the provided CTK-run command.
Hello World
^^^^^^^^^^^^^
The one example that can never be missing: Hello World!
----
# hello_world.py
import CTK
class default:
def __call__ (self):
page = CTK.Page()
page += CTK.RawHTML('Hello World!')
return page.Render()
CTK.publish ('', default)
CTK.run (port=8000)
----
As you can see, CTK is mapping the URL `''` to the default
class. Ordinarily you would map a specific URL, but since this
application is so simple we are using an empty URL. CTK processes
these mappings by matching the incoming requests against a list of
published paths. Those can be specified as regular expressions, so the
mechanism is very flexible. If a specific match is not found, every
request will fall through to the entry for `''`. In this case it means
that any request to http://localhost:9091 will yield a “Hello World”
as response.
Hello Button
^^^^^^^^^^^^
This one goes a little further, and binds click events to actions.
----
# hello_button.py
import CTK
class default:
def __call__ (self):
text = CTK.RawHTML ('Hello World!')
box = CTK.Box (text)
hide = CTK.Button ('Hide')
hide.bind('click', box.JS_to_hide())
show = CTK.Button ('Show')
show.bind('click', box.JS_to_show())
page = CTK.Page()
page += box
page += hide
page += show
return page.Render()
CTK.publish ('', default)
CTK.run (port=8000)
----
It is embedding the HTML contents into a CTK.Box, which is in reality
nothing more than the container that we will be showing and hiding on
demand. All CTK Widgets provide some basic methods, such as:
. bind: used to bind events and actions
. JS_to_hide: that renders Javascript code tohide the element
. JS_to_show: that renders Javascript code to show the element
. JS_to_trigger: that renders Javascript code to trigger a specific
event (it accepts parameters and selectors other than the default
one -the unique ID of the widget-).
Form submission
^^^^^^^^^^^^^^^
With CTK, validating, submitting, and processing forms is very
simple. Take a look at the following script.
----
# form.py
import CTK
import time
def validate_number (value):
try:
if int(value) in range(10):
return value
except:
raise ValueError('Not valid')
raise ValueError('Not in range')
VALIDATIONS = [
('number', validate_number),
]
def apply():
if CTK.post['show_delay']:
time.sleep(2)
return {'ret': 'ok'}
class default:
def __call__ (self):
submit = CTK.Submitter ('/apply')
table = CTK.PropsTable()
table.Add ('Delay 2secs',
CTK.Checkbox ({'name': 'show_delay', 'checked': 0}),
'Delay response for 2 seconds to notice the submitting status')
table.Add ('Number',
CTK.TextField({'name': 'number'}),
'Pick a number [0-9]')
submit += table
page = CTK.Page ()
page += submit
return page.Render()
CTK.publish ('', default)
CTK.publish ('^/apply$', apply, method='POST', validation=VALIDATIONS)
CTK.run (port=8000)
----
Notice the line where the '^/apply$' URL is published. As you can see,
there is a difference when comapared to the others shown until
now. Most remarkably, it specifies the method to be POST, since it
will be mapping a custom commit function to that URL, and it also
provides a list of validations to be applied when performing such
POST.
If specified, the validations will be checked even before the data
flow reaches the specified function, `apply` in this case. The logic
behind this is to raise an exception if validation tests are not
passed, and CTK will display the error right beneath the field that
fails to pass the tests.
Also notice how the form is built. A Submitter object is instanced,
that acts as a container for a variety of form elements (comboboxes,
input fields, textareas, radio buttons, checkboxes, etc). Each of
these is a widget itself. A submission button could have been added to
the form, but we've left it out to keep it as simple as possible.
As soon as the form can be submitted, all the data is sent using
POST. Notice that this does not necessarily imply that every field in
the form has been given a value. In fact, in the previous example,
altering the value of any of the widgets will trigger the submission
of the whole form. Every widget can be instanced with a set of
specific parameters, so it is not complicated to specify which fields
require being filled, which ones are optional, etc. Among those
parameters, 'class' is undoubtedly the most important one, since it
allows you to pass 'class' attributes directly to the HTML
elements. Some of these actually influence how the submission is
performed.
.Important class attributes
[cols="25%,75%"]
|===================================================
|required | Every widget marked as required needs to be filled up
before the submission can be performed
|noauto | Altering the value for the widget does not trigger the
submission of the form, as it would do by default.
|===================================================
Even when a SubmitterButton widget is present, all required fields
must be present before any data is actually sent. Clicking on the
button will do nothing unless all these are filled up.
Each widget has a specific syntax, so better the API in detail or dig
into the code.
Dialogs
^^^^^^^
Using dialogs with CTK is also easy. In this example we will instance
two dialogs, one of which is opened on-load, and the other one bound
to the click event of a CTK.Button.
----
# dialog.py
import CTK
class content_box (CTK.Box):
def __init__ (self):
CTK.Box.__init__(self)
self += CTK.RawHTML ('<h1>About</h1>')
note = CTK.Notice()
note += CTK.RawHTML ('<p>CTK dialogs are highly customizable.</p>')
self += CTK.RawHTML ('<p>By default, CTK dialogs are:</p>')
defaults = CTK.List()
defaults.Add (CTK.RawHTML('Modal'))
defaults.Add (CTK.RawHTML('Not resizable'))
defaults.Add (CTK.RawHTML('Not opened automatically'))
defaults.Add (CTK.RawHTML('Not draggabale'))
defaults.Add (CTK.RawHTML('Rendered on the center of the screen'))
self += CTK.Indenter (defaults)
class default:
def __call__ (self):
opened = CTK.Dialog ({'title': _('Automatically opened dialog'), 'width': 450, 'autoOpen': True})
opened += content_box()
opened.AddButton (_('Close'), "close")
closed = CTK.Dialog ({'title': _('Manually opened dialog'), 'width': 450})
closed += content_box()
closed.AddButton (_('Close'), "close")
button = CTK.Button('Open dialog')
button.bind('click', closed.JS_to_show())
page = CTK.Page ()
page += opened
page += closed
page += button
return page.Render()
CTK.publish ('', default)
CTK.run (port=8000)
----
Tabs
^^^^
As was mentioned before, you can add widgets to other widgets. Thanks
to this approach, using tabs is also intuitive. Just instantiate a
CTK.Tab object, and add as many tabs as you want. The contents of each
tab has to be a widget: an Image, a Box, etc.
-----
# tabs.py
import CTK
IMAGES = ['on', 'off', 'loading', 'tick', 'del']
class default:
def __call__ (self):
page = CTK.Page()
tabs = CTK.Tab()
for img in IMAGES:
tabs.Add (img.capitalize(), CTK.ImageStock(img))
page += tabs
return page.Render()
CTK.publish ('', default)
CTK.run (port=8000)
-----
Refreshable elements
^^^^^^^^^^^^^^^^^^^^
The CTK.Refreshable class allows the creation of objects that can be
rendered asynchronously in response to a given event. Normally every
CTK widget has a unique identifier that is generated automatically,
but since the contents of a Refreshable have to be written into a
specific container that you'll need to know in advance, this class
demands an explicit 'id' be given on instantiation.
----
# refresh.py
import CTK
import time
class Default:
class Content (CTK.Box):
def __init__ (self, refresh):
CTK.Box.__init__ (self)
button = CTK.Button ('Refresh')
button.bind ('click', refresh.JS_to_refresh())
self += CTK.RawHTML('<p>Rendered on %s.</p>' %(time.ctime()))
self += button
def __call__ (self):
r1 = CTK.Refreshable ({'id': 'r1'})
r1.register (lambda: self.Content(r1).Render())
r2 = CTK.Refreshable ({'id': 'r2'})
r2.register (lambda: self.Content(r2).Render())
page = CTK.Page ()
page += r1
page += r2
return page.Render()
CTK.publish ('', Default)
CTK.run (port=8000)
----
So, what does it do? It instantiates two CTK.Refreshable elements,
each with its unique identifier, and each one is refreshed when the
button is clicked. Easy, right?
Remember that identifiers must be unique for every DOM
element/node. Should you mistakenly provide the same identifier for
both Refreshable objects, clicking on anyone of the buttons would
probably update the same element (and only one of them).
Advanced examples
~~~~~~~~~~~~~~~~~
If the basic examples don't seem enough for you, there are lots of
more complex examples at your disposal. The best way to dive into CTK
is reading the code of Cherokee-Admin, and checking the CTK code
itself from time to time. Most of CTK has been written to provide the
specific needs of Cherokee Admin, so most likely you'll find examples
as complex as you want that will help you fully understand how things
are working.
Some considerations
~~~~~~~~~~~~~~~~~~~
So far you've seen some very basic examples. Before you begin hacking
on Cherokee-Admin, you'll probably need to know some more about other
CTK elements.
CTK.post
^^^^^^^^
This is used to access every element submitted using the POST
method. You've seen how it works on some of the previous examples. The
most useful methods in this class involve accessing reading and
popping values and keys. Elements can also be accessed using
dictionary-like notation. In the examples above, both:
-----
CTK.post['show_delay']
-----
and
-----
CTK.get_val('show_delay')
-----
Would return the same value, although the second appearance lets you
specify a default value as optional argument.
CTK.cfg
^^^^^^^
The class CTK.Config seamlessly handles the Cherokee configuration
tree. With it you can read and write a configuration file, parse and
serialize the configuration tree, clone configuration elements, and
manipulate branches ands leaves at will.
The class is instanced as soon as Cherokee-Admin loads, and it can be
accessed as CTK.cfg. Just like before, it can be accessed and
manipulated using its many methods, and dictionary-like syntax can
also be used. With little doubt, this is the most manipulated object
throughout the whole code-base. Study CTK.Config if you are interested
in the full details.
The most used methods are the ones involving setting and gettings
entry values. This is done just like in a dictionary. Among the other
methods available, probably the most used are:
. pop: to pop elements from the configuration tree.
. keys: access the list of subnodes of any given node
. get_val: retrieve the value of a configuration
key. CTK.cfg.get_val('server!timeout') would be equivalent to
CTK.cfg['server!timeout']
. apply_chunk: to apply a configuration chunk directly to the
configuration tree. This is a lifesaver when dealing with wizards,
for examples, where you have tamplates as large chunks that only
require some customization.
. normalize: also very useful when dealing with wizards, since it can
be used to renumber configuration entries. It is recommended to
always normalize the configuration after playing around with it.
. get_next_entry_prefix: provided a path, it will yield the next entry
in the sequence of currenlty existing elements.This is very used
when having to add any new element to the configuration, such as a
new rule, a new virtual server, a new information source, and so on.
The tmp configuration node
^^^^^^^^^^^^^^^^^^^^^^^^^^
Whenever the configuration three is altered, a flag is set indicating
the configuration tree has been changed. In turn, the 'Save' button on
the admin interface becomes clickable, and using it will dump the
configuration tree to the configuration file that is being used at the
moment. There is one exception to this rule: the *tmp* configuration
node. Everything hanging from that branch is ignored when loading and
saving the configuration tree. It is used extensively as a temporary
repository. For example, on multi-stage wizards, it is used to store
the intermediate values gathered along all the different stages.
Every configuration entry hanging from this node can be set and
retrieved exactly like the rest, but nothing will be saved to disk.
Config related widgets
^^^^^^^^^^^^^^^^^^^^^^
You have been some Widgets being used in the example about form
submission. What you haven't yet seen are all the variants specially
conceived to interact with CTK.Config. Many widgets have a variant
with a name ending in *Cfg*.
Normally, you would process form submissions in custom commit
functions that would extract the required data from CTK.post and
inject it into CTK.cfg. The *Cfg* widgets are bound to the
configuration tree itself, so the rest of the code can be simplified
by avoiding the need of duplicating logic for such repetitive tasks.
These widgets are instantiated with a configuration entry, and their
values are retrieved from the configuration tree itself. Once
submitted, one call to the method CTK.cfg_apply_post will set the new
values in the configuration tree as well.
HTTP responses
^^^^^^^^^^^^^^
Complex things can be achieved through the use of custom HTTP
responses. Of course, CTK provides a convenient way to do this.
For example, a custom commit function could decide that the user has
to be redirected to another location. Making it return a
CTK.HTTP_Redir response would redirect to whatever location was
specified.
Any response can be issued, just dig into the class and try it out if
needed.
CTK.url_request
^^^^^^^^^^^^^^^
Sometimes passing parameters through the URL migh come in handy. Just
access the CTK.url_request property and you'll be able to parse to
your heart's contempt.
CTK.cookie
^^^^^^^^^^
Basic cookie support is provided through this object. Cookies can be
set an read using the well known bracket-syntax:
-----
CTK.cookie['user'] = 'my_user'
-----
and
-----
user = CTK.cookie['user']
-----
Final notes
~~~~~~~~~~~
Although CTK was conceived as a tool to help in the development of
Cherokee-Admin, it has grown in complexity and flexibility to the
point that it is an Open Source project all by itself. Detailing every
last piece of it is far beyond the scope of this introductory
tutorial.
You can easily achieve relatively complex tasks using CTK with very
little effort. Review the API, check the provided examples, and dig
into Cherokee-Admin. As you can see, once you get the hang of it it is
really not complicated, and you can always turn to our development
mailing list for help.