Location: PHPKode > scripts > Lightweight Club Calendar > lc-calendar-0.9.4/documentation/architecture.txt
| LCC Architecture |

This document describes briefly how the LCC-core works.
It is mainly intendet for developers who want to enhance LCC.

I.      Briefly Overview
II.     Details of the components
II. a)    UserInterface
II. b)    Controller
II. c)    LCC Core
II. d)    Drivers
III.    Permission management
IV.     Event field security

Firstly some kind of graphic:

                  UserAgent (Browser)
                |   UserInterface    |
                | (SMARTY-Templates) |
        | Controller (lcc_standalone.php) +---- LCC configuration
      |                LCC Core                |
          |               |                |
   +------+------+  +-----+------+  +------+-----+
   | EventDriver |  | NoteDriver |  | UserDriver |
   +------+------+  +-----+------+  +------+-----+
          |               |                |
      Events data     Notes for   User- and Group data,
                       events         Permissions

I. Briefly overview:
The UserAgent (Browser) sends requests to the LCC-Core, like it is in other applications.
This is nothing else than the User clicking on some link provided by the templates.
LCC now uses the drivers to retrieve or set the information requested from the UA. This
is performed with standardized calls to the drivers.
After all is processed, the data is fed to the templates and provided to the User.

II. Details of the components
a) UserInterface
The UserInterface is nothing else than a set of SMARTY-Templates files. However they are not arbitary,
they need to meet some criteria. They need to provide some variables for objects generated by the core,
for example.
It is possible to have several designs installed, because the files are seperated from each other.
Much of the applications logic lives within the UserInterface, because it is, what a user sees and
what actions a user can trigger, however, the action needs to be available in the LCC core.
The UI is provided via the core.

b) Controller
The controller is the interface between the calls made from the UI and
the LCC core. The term "Controller" is the php-file that sets up the instance
of LCC_Core and loads the drivers.
This gives you 100% control in which way LCC is started. You even may catch
lcc-actions and rewrite them in some way, if you wish, or you may extend
LCCs capabilitys like adding usermanagement.

c) LCC core
This is where the hard work is done. Here all possible actions the UI can provide
are coded, and this is, where all the stuff is glued togehter.
The core relies heavily on the loaded drivers to gain the necessary data.

d) Drivers
There are different types of drivers:
- UserDriver:     This drivers are responsible for
                  stuff like getting user and group data but also for providing
                  permission management and login.
                  Usually "login" means no true login, but the retrieval of a users name.
                  But it is of course possible to implement a custom driver that is
                  able to perform a full featured login.
                  However, LCC is meant to be used in combination with some already logged in
                  user from another application.

- EventDriver:    The EventDriver is responsible for storing/getting events data and for
                  associations (subscriptions) of Users to a specific event.
                  The Storage is used by the LCC core to store and retrieve the event data.
                  It must provide standardized interfaces so the core is able
                  to actually process the data.

- NotesDriver:    Notes are short notices that users can (depending on their permission)
                  add to an event to, for example, tell more details on their
                  participation or just to leave a message.
                  The notes are separated from the events to enable you to
                  use different storage places for notes and events.

III. Permission management
Permission management is very simple.
The UserDriver provides a method for getting the "level" of a specific user. This is a simple integer, and the higher
the number is, the higher the level of the user is. It is the job of the driver to determine the level of the user,
the core just use these numbers to compare them with the preset rights.
Nearly every Action of LCC is connected to a level, that is at minimum required to perform a certain action and can
be configured in LCCs core configuration.
Additionally it is common that users are part of groups. LCC group management is very easy too, the UserDriver provides
methods to retrieve the group information about a user. The actions of LCC are not only linked to the level mentioned
above but also to groups. You can specify for every action to which group a user must belong to be able to trigger
this action.

LCC is able to create a anonymous login if the user isn't logged in so far. This is configurable.

This all sounds very complex, but in fact it isn't because every stuff that needs to be done is capsulated inside
a responsible area and can managed autonomusly.
For example, it is possible to change the storage place (eg. from flat files to mysql) just with replacing the storage object.
No user would recognise this change, everything else remains the same.

IV. Event field security
Since every EventDriver must work in such a way, that every field can be read/stored, it is possible to
store everything in the backend. To prevent evil people forcing LCC to store data LCC was not planned to,
every field that should be used by LCC must be explicitely defined.
The definition of a field provides all informaton neccessary to make security based decisions such as
if a field is only readable and what format it should have. If something violates this rules, LCC will
refuse to store or display the data.
Return current item: Lightweight Club Calendar