Documentation
1. URL
All our urls, except for login, have the universal format SITE/handler/role/mime/component?action=ACTION&.... where handler is handler name, usually a FastCGI program. In GENELET, each website has only one handler that handles all dynamical content. role is a visitor role or visitor type. One of them is for public viewers and the rest for authenticated roles. To make a new role in GENELET, developer defines it in Config.pm and Access/Config.pm, without coding. GENELET supports two popular authentication mechanisms: database and Oauth (both Oauth1 and 2). Although this covers 95% cases, developer is allowed to make his own authentication mechanism too. mime is a mime-type name, defined in Config.pm. Dynamic content could be delivered to client in any mime type by using corresponding template. GENELET completely separates code from html. There are two special mime types that do not have template: json and XML. In GENELET, developer automatically gets all json APIs by simply changing mime in URL.A component usually describes a database table. Web project consists of many components .
ACTION defines how to operate the component. The 5 RESTful actions, “topics” (list of entries), “edit” (get one entry), “update” (update an entry), “delete” (delete an entry) and “insert” (create a new entry), are always implicitly inherited in all components. Please read Section 3 for details.2. LOGIN and LOGOUT
To login against a database table, send POST form to SITE/handler with necessary input parameters like username and password, which are defined in Access/ Config.pm. GENELET has a built-in ticketing system that handles login and follow-up URL authentications. Specifically, a self-signed authorized token is stored in cookie, which also serves as the session (so the cookie is usually a bit long and always encrypted. GENELET does not use any other session storage).To login against an Oauth1 or 2 server, send GET to
SITE/handler/provider
where provider is provider’s name like “google”, which are defined in Access/Config.pm. GENELET handles the rest of Oauth processes.
To logout, send GET to
SITE/handler/role/logout
where the logout marker, “logout”, is also defined in Access/Config.pm
3. CODING: model.pm
To login against a database table, send POST form to
In GENELET, what developer really programs every day is to write two modules for each
component: Filter.pm and Model.pm. Usually it is fast to do! (So developing time is much shorter!)
Model.pm consists of two parts: 1) which table columns that the RESTful actions involve, and 2) new actions. A new action is defined as a “method”. To change the behavior of an existing RESTful action, just override the method.
Model.pm is about how to operate a database table. It is independent of roles (securities), mime types, whether or not a web program or a shell program. Important features of GENELET model include
! no ORM, instead GENELET provides an abstract layers for raw SQL statements. Since the RESTful actions are implicit, ORM is used rarely anyway.
! stored procedures are handled in the same way as standard SQLs in the abstract layer.
! “trigger” allows developer to easily call data from other components. This expands the power of GENELET’s database operation to the next level.
4. CODING: filter.pm
Because components share many common “controlling” tasks, such as authentication and templating, GENELET has moved them into the system controller module (GENELET/Controller.pm). Individual component does not needs its own controller, but only special filters in “Filter.pm”.
Specifically, Filter.pm defines:
! who can act on which actions in the component, i.e. ACL
! how to act
The first part is simply defined in an ACL hash. The second part is fulfilled by three filtering functions called “prefix”, “before” and “after”. “prefix” is a pre-processor for web input parameters. “before” is also a pre-processor but specifically for database. “after” is a post-processor after the database interaction.
5. EMAIL, SMS, PUSH NOTIFICATION & etc.
GENELET has also built-in modules to process emails, sms messages and mobile push notifications. Developers does not need to write any code for the tasks, but just to define them in the configuration file and input the recipients information in Filter.pm, wherever needed.
There are many carefully designed features in GENELET to make it be simple, straightforward and easy in development. It also has the minimal dependence on 3rd part modules.