Devin

^{Devin 1.0}

Category / Domain:	Database
Compatibility SCOL Voy@ger	V 2.0c and superior
Update:	12/2000

Function

This module delivers random prediction on demand.
These predictions come from a table, in a database accessed through ODBC.
Moreover, this module edit the predictions table.

Predictions are asked with an event.
User must wait 24 hours to have a different prediction.
If he asks one before this delay, the module sends him the last he gets, or nothing, depending on module configuration.
This delay is linked to his login.

To work, this module requires 2 tables : one for the logins, and one for the predictions.
The login table is made of the user login, his last prediction date, and the last prediction number.

These fields MUST have the folowings names :

“login” : test field, that is the table key.
“DernierePrediction” long int field
“NumDernierePrediction” long int field.

This table is not the main login table. User is supposed to have logged on before asking a prediction.
The prediction table is made of a number identifying the prediction, and the prediction text.
These fields MUST have the folowings names :

“NumPrediction” : a long int field, that is the table key.
“TxtPrediction” a text type field, with a size of 256.

The name of these tables can be specified with the module editor.
They can contain other fields, but the module will not manage them during insertion and modification. So, this is not recommanded.

The client part of the module manage prediction table edition. Login table is managed internally by the module.
This edition is executed with an event : editDatabase.
Site builder must check that only allowed people can execute this event.
The module don’t prevent 2 people from working in the same time.
But, their modification could overwrite one another. In case of problem, operator can refresh their window.
When a second operator open the edit window, he receives a message, telling him that someone else is currently working.

Database can also be managed through events ( see below ).

Configuration

Figure 1 : Devin interface module

(1) : Database name : => Defines the database name, or to be more precise, the name of the ODBC alias used to access the database.

(2) : Database Login : => Defines the login used to access to the database.

(3) : Database Password : => Password used to access to the database.

(4) : Login table of Devin : => Name of the table where the module will seek the information about the last prediction given to the user.

(5) : Prediction Table : => Name of the table where the module will seek the prediction.

(6) : Give the previous prediction on a new demand : => If the check box is checked, a user who ask a prediction, and who has already asked one in the last 24 hours will have the same that the last time. If not checked, he will receive nothing.

Implementation

Open the SCS creation tree and select the Db folder. Double-click on the Devin 1.0 icon
Establish links according to the project.

Action	Fonction
module.event à Devin.askRandomPrediction	Main action for the module. It asks a random prediction for a user. He must be logged before. If he has already asked a prediction in the last 24 hours, he receive the last again, or not, depending on module configuration. To answer, this module sends an event : sendRandomPrediction.
module.event à Devin.askPrecisePrediction	This action asks for a precise prediction. Its parameter is the number of the prediction. The answer is given with a sendPrecisePrediction event.
module.event à Devin.createPrediction	This action creates a new prediction. Its parameter is a string that is the text of the new prediction. Its answer is send through an event : sendModificationResult.
module.event à Devin.updatePrediction	This action is used to modify a prediction that already exists. Its parameter is a string made of the number identifiying the prediction, a space and the new prediction text, that can contain spaces. The answer is send through an event : sendModificationResult.
module.event à Devin.deletePrediction	This action deletes a prediction that already exist. Its paameter is the prediction number. The answer is send through an event : sendModificationResult.
module.event à Devin.editDatabase	This action launches the client, to edit the database, as described below. No authorization check is done. So if a link is made to this action, it must be checked that user is allowed to modify the database.

Event	Function
Devin.sendRandomPrediction à module.Action	This event is sent to answer to the action askRandomPrecision. It contains the text of the prediction, or nil if the user already asked a prediction in the last 24 hours, and if module is configured that way. If an error occurred, no event is sent.
Devin.sendPrecisePrediction à module.Action	This event is sent to answer to the askPrecisePrediction action. It contains a string made of a number, a space, and the text of the asked prediction. This number is the result of the request on the database. 0 means that the request was succesfull, and 1 means that an error occurred. In that case, the prediction text is nil.
Devin.sendModificationResult à module.Action	This event is sent to answer to an action that modify the database ( creation, update, delete ). It contains a string made of a number corresponding to the action result. This number is 0 if the action was successful, and 1 otherwise.

Zone	Function	Interface	Assignment
Devin. ListeDesPredictions	Contains the list of all the predictions inside the table. A click in that list sends the prediction in the zone DetailDesPredictions.	Client	Yes
Devin.DetailDesPredictions	Contains 2 fields that describes a prediction, and are used to handle that prediction.	Client	Yes
Devin.PaletteBoutonAction	This zone contains 3 buttons, that act on the selected prediction in the zone DetailDesPredictions.	Client	Yes
Devin.PaletteBoutonFenetre	This zone contains the 2 buttons used to handle the window. Refresh load the list from the server, and exit close the window.	Client	Yes

Foot notes

The suppression of a prediction does not just delete the prediction from the database. There must be no hole inside the prediction numbers. So when the operator deletes a prediction, the text of the last one replaces the text of this prediction, and the last one is deleted instead. If the user want to delete the last prediction, it is just deleted from the table.
The search of a login inside the login table is case sensitive.
The module does not behave differently with a default login like “guest X”. So if module sends nothing when a second prediction is asked in 24 hours, a new visitor will receive nothing. For that reason, it is recommended to send the last prediction.
The login table is not updated when prediction table is modified. So the last prediction of a user could have been destroyed. In that case, like any other errors, a message is logged in the server log, and no event is generated. >li>If 2 operators are editing the database in the same time, with the same module, or with 2 differents devin module that use the same prediction table, they may overwrite their modifications.
When a second operator is opening the edition window, he is alerted that someone else is working. But the first operator is not alerted. Moreover, an operator is not aleterd when an action modifies the database. But if one of its action is not possible anymore, he gets a message, and he is proposed to refresh its predictiosn list.