1 .. -*- coding: utf-8 -*- |
|
2 |
|
3 Introduction |
|
4 ============ |
|
5 |
|
6 This book uses version 0.4.0 of `LAX`. |
|
7 |
|
8 What is `LAX` ? |
|
9 ---------------- |
|
10 |
|
11 `LAX` stands for `Logilab Appengine eXtension`. It is a web application framework |
|
12 based on `Google AppEngine`. |
|
13 |
|
14 `LAX` is a port of the web framework Logilab_ has been developping since 2001. |
|
15 This framework originally published data queried from different sources including |
|
16 SQL databases, LDAP directories and concurrent versionning systems |
|
17 (like subversion). In April/May 2008, it was adapted to run also on |
|
18 top of `Google AppEngine`'s datastore. |
|
19 |
|
20 `Google AppEngine` is provided with a partial port of the `Django` |
|
21 framework, but Google stated at Google IO 2008 that it would not |
|
22 support a specific Python web framework and that all |
|
23 community-supported frameworks would be more than welcome[1]_. |
|
24 |
|
25 `LAX` competes with other Python web application frameworks to get |
|
26 developers' attention and support. It originates from Logilab and is |
|
27 the result of about ten years of experience in developing large-scale |
|
28 web applications. |
|
29 |
|
30 Distinctive features include a data-model driven engine, a full-blown |
|
31 query language, a selection/view mechanism for HTML/XML/text |
|
32 generation, reuseable components, etc. It all sums up to very fast and |
|
33 efficient development. |
|
34 |
|
35 If you like Python and its standard library, chances are you will like |
|
36 `LAX` for it comes with batteries included thanks to its standard |
|
37 component library. |
|
38 |
|
39 Compare `LAX` with other frameworks and see for yourself what is your |
|
40 best option. |
|
41 |
|
42 .. _Logilab: http://www.logilab.fr/ |
|
43 .. [1] for more on this matter, read our blog at http://www.logilab.org/blog/5216 |
|
44 |
|
45 Essentials |
|
46 ---------- |
|
47 |
|
48 Schema |
|
49 |
|
50 The schema defines the data model of an application as entities and |
|
51 relationships. It is the core of an application. Entities and |
|
52 relationships are modeled with a comprehensive language made of |
|
53 Python classes. |
|
54 |
|
55 Query language |
|
56 |
|
57 A full-blown query language named RQL is used to formulate |
|
58 requests to the datastore. |
|
59 |
|
60 Result set |
|
61 |
|
62 A resultset encapsulates the results of a request sent to |
|
63 the datastore and informations about this request. |
|
64 |
|
65 Views |
|
66 |
|
67 A view is applied to a `result set` to present it as HTML, XML, |
|
68 JSON, CSV, etc. Views are implemented as Python classes. There is no |
|
69 templating language. |
|
70 |
|
71 Generated user interface |
|
72 |
|
73 A user interface is generated on-the-fly from the schema definition: |
|
74 entities can be created, displayed, updated and deleted. As display |
|
75 views are not very fancy, it is usually necessary to develop your |
|
76 own. Any generated view can be overridden by defining a new one with |
|
77 the same identifier. |
|
78 |
|
79 Components |
|
80 |
|
81 Pieces of schema and sets of views can be combined into |
|
82 components. Larger applications can be built faster by importing |
|
83 components, adding entities and relationships and overriding the |
|
84 views that need to display or edit informations not provided by |
|
85 components. |
|