The Readable Programming Language - Handbook



A role is defined by a least one "can" sentence.
In the menu of any page, the reviewer can click on "choose project" to open the "Select project" page.

The roles collected from the "can" sentences build an automatically defined enumeration.

Predefined Roles

There are 3 predefined roles:

  • A user is somebody who's logged in to the application.
  • A visitor is somebody who's looking at the application but hasn't logged in.
  • An admin is a special user who can everything and more.

The visitor will automatically find a login form on the (predefined) "Home" page.

It is a good idea to provide the (logged in) user with a possibility to logout, for instance:
In the menu of every page, the user can click "Logout" to logout.
The user will also be logged out if he terminates the session, for instance by closing his browser.

If the visitor can do something (apart from logging in), then any logged in user can do it also. The user could do it anyway by logging out and becoming a visitor - we spare him this step.

A user who has the admin role can do anything that other users can do, plus the actions that have been specifically programmed for this role Motivation.

X The motivation for the existence of the admin role comes from the following experience:

  • There's always somebody who can modify the database and the data in the database, at least a programmer in charge of the maintenance.
  • There are always users that come to the support service with urgent and justified needs for a quick operation that the user interface doesn't (yet) allow.
    "I clicked too quickly on "send to reviewer"! I'm so sorry, but I can't wait until the reviewer sends my submission back, because tomorrow is a holiday and if the submission isn't accepted before friday, we lose 250,000 € of subventions! Please please let me add something to my submission!"
  • Since it is possible and needed, there will be quick operations made directly in the database (Murphy's law: everything that can happen will happen).
    "OK I set back your submission status to "in definition", you can edit it again."
  • Quick operations made directly in the database lead to data inconsistencies, unexpected application and object states, and other catastrophes.
    "I've received yesterday an automatic email from your application telling me that I have a submission to review urgently, but I can't open it, because its status is "in definition" instead of "in review"! Now if I look at the submission's history, it says that it has been sent to me for review but that it's still being edited by the submitter. I don't understand! Your application isn't reliable!
  • That's why it is more reasonable to give a possibility to play all roles and correct errors using the normal procedures defined by the UI and published in the handbook (in the code), even if quickly.
    In the example, the support admin would say "OK, I've taken over the reviewer role and sent you back your submission", the reviewer would eventually receive a second email, or at least he would see in the submission's history that it has been legally sent back by an admin and not by a program failure.

If you don't like admins, just don't give this role to any user. X

Role Objects

A structure may have the same name as a role (except the visitor role), allowing the programmer to add attributes to users depending on their roles.
Every reviewer has a signature, which is a password.

There's a predefined structure corresponding to the "user" role. It has 3 predefined attributes:

  • a username, which is a short string
  • a password
  • a list of roles

If a structure is defined with the same name as a role, when the role is added to a user's role list, an instance of this structure (a role object) is automatically created and attached to the user.

All operations made on a role object (creating one, storing it in a variable, adding it to a list, destroying it, etc.) concern in reality its owner user: "a reviewer" means "a user who has the reviewer role".

When a role is removed from the role list of a user, the corresponding eventual role object may be destroyed or just detached from the user and archived, depending on the translator.

The attributes of a role object are handled as if they'd belong to its owner user. They will be null (meaning: not accessible) if the user hasn't got this role.

No structure can be named "visitor" and associated with the visitor role. Use the session structure instead.