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.