Les applications développées dans le cadre de nebule :
- bootstrap : le chargeur initial de la librairie et des applications.
- sylabe (blog indépendant) : l’application de référence des possibilités de nebule.
- klicty (blog indépendant) : l’application de partage d’objets à durée limitée.
- messae (blog indépendant) : l’application de gestion des conversations et messages.
- option : l’application de gestion des options.
- upload : l’application de chargement de mises à jours.
- defolt : l’application pour un affichage par défaut sans application interactive.
Fonctionnement
Dans la construction du code, il y a quatre niveaux. Chaque niveau de code est constitué d’un et un seul objet nebule ou fichier utilisé. Une seule application est utilisé à un instant donné mais il peut y avoir plusieurs modules utilisés par l’application. Les niveaux :
- le bootstrap, fichier ;
- la librairie en PHP orienté objet, objet ;
- une application au choix, objets ;
- des modules au choix, facultatifs, objets.
Les applications sont toutes construites sur le même modèle et dépendent (extend) toutes des mêmes classes de l’application de référence dans la librairie nebule.
Chaque application doit mettre en place les variables personnalisées :
- $applicationName
- $applicationSurname
- $applicationDescription
- $applicationVersion
- $applicationLevel
- $applicationLicence
- $applicationAuthor
- $applicationWebsite
Chaque application doit mettre en place les classes :
- Application
- Display
- Action
- Traduction
Elles dépendent respectivement des classes de l’application de référence Applications, Displays, Actions et Traductions dans la librairie nebule.
Créer une nouvelle application
La création d’une application se fait en deux étapes, le référencement et le code.
Tout se fait dans l’application sylabe. Un module sera créer pour faciliter ce travail…
Le référencement
Cette partie est à faire au début lorsque l’on veut rendre visible et utiliser la nouvelle application. Elle ne sera plus refaite par la suite. Le but est de permettre au bootstrap de retrouver l’application et de permettre à l’utilisateur de la sélectionner.
Le mot clé utilisé :
nebule/objet/interface/web/php/applications
On définit un objet de référence, un objet qui sera en quelque sorte virtuel puisqu’il n’aura pas de contenu. Sa seule contrainte forte est que l’empreinte est exprimée en hexadécimal. Par convention, il est recommandé que la taille de l’empreinte des objets virtuels soit comprise en 129 et 191 bits. Cet objet de référence peut être généré aléatoirement ou au contraire avoir un contenu pré-déterminé, ou mixer les deux.
Chaque application doit avoir un objet de référence qui lui est réservé. Utiliser l’objet de référence d’une autre application revient à tenter de mettre à jour l’application, non à en faire une nouvelle.
Par exemple avec la commande : openssl rand -hex 24
Cela donne une valeur, notre objet de référence, qui ressemble à ça :
e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
Pour finir avec l’objet de référence, la couleur de l’application dépend de lui. Cette couleur étant constituée des 6 premiers caractères de l’empreinte de l’objet de référence, il est possible de choisir volontairement cette couleur.
L’application doit avoir un nom et un préfixe. Ces deux propriétés sont utilisées par le bootstrap pour l’affichage des applications dans l’application de sélection des applications.
Le nom est libre mais si il est trop grand il sera tronqué pour tenir dans le carré de l’application.
Le préfixe doit faire 2 caractères. Si ce sont des lettres, systématiquement la première sera transformée en majuscule et la deuxième en minuscule.
Par exemple :
– sylabe
– Sy
Lorsque l’on a défini notre objet de référence et le nom de l’application, on crée les liens.
Le lien de type d’empreinte de l’objet de référence :
- action :
l
- source : objet de référence, par exemple =
e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
- cible : hash de la valeur de la caractéristique =
5d5b09f6dcb2d53a5fffc60c4ac0d55fabdf556069d6631545f42aa6e3500f2e
- méta : hash de la caractéristique =Â
8e2adbda190535721fc8fceead980361e33523e97a9748aba95642f8310eb5ec
Le lien du nom de l’objet de référence :
- action :
l
- source : objet de référence, par exemple =
e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
- cible : hash du nom, par exemple = sha256(‘
sylabe
‘) - méta : hash de la caractéristique =
940c75a60c14a24e5f8bda796f72bef57ab1f64713a6fefd9a4097be95a9e96a
Le lien du préfixe de l’objet de référence :
- action :
l
- source : objet de référence, par exemple =
e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
- cible : hash du préfixe, par exemple = sha256(‘
Sy
‘) - méta : hash de la caractéristique =
4e36fa58a64beebbfc69d2b3f3ecd75eeb2290780c39c14ff8f36473091544e5
Le lien de référence :
- action :
f
- source : objet de référence des applications =
e0150ff815bd5343034ff025624d20f723e2293842ab4eaedabda1ea5790e66b
- cible : objet de référence, par exemple =
e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
- méta : objet de référence des applications =
e0150ff815bd5343034ff025624d20f723e2293842ab4eaedabda1ea5790e66b
Pour que ces liens soient reconnus par le bootstrap, ils doivent tous être signés d’une autorité locale.
Le code
La création de la base d’une application est simple, il suffit de copier le modèle d’application dans un nouveau fichier et dans un premier temps d’adapter les variables et la fonction d’affichage.
Le modèle d’application est disponible ici :
http://sylabe.com/?mod=obj&view=disp&obj=8155d1b82703b18692748937ade2335510b568a3b17fc6e88fdc0d9e26acd113
Ensuite, ce fichier doit être nébulisé, c’est à dire transféré vers le serveur comme nouvel objet.
Une fois nébulisé, l’objet peut être déclaré par un lien comme code pour l’objet de référence de l’application :
- action :
f
- source : objet de référence de l’application, par exemple =Â
e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
- cible :Â hash du code
- méta : objet de référence des applications =
e0150ff815bd5343034ff025624d20f723e2293842ab4eaedabda1ea5790e66b
Pour que ce lien soit reconnu par le bootstrap, il doit être signé d’une autorité locale.
A chaque fois que l’on veut mettre à jour l’application, il faut nébuliser le nouveau code et générer un nouveau lien.
Les différentes classes de l’application héritent de leurs classes parentes tout un tas de fonctions préparées. Ces fonctions peuvent être utilisées par la nouvelle application, voire elles peuvent être surchargées si besoin pour avoir un comportement particulier.
Activer une application par défaut
Lorsqu’une application est fonctionnelle et reconnue par une autorité locale, il est possible de demander au bootstrap de charger par défaut cette application.
Soit par exemple l’objet de référence de l’application : e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
Ajouter ou modifier dans le fichier nebule.env
l’option :
defaultApplication = e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
La prise en compte se fait lors de la création d’une nouvelle session sur le serveur, une session PHP. Pour vérifier le bon fonctionnement, ajouter l’argument f
dans l’URL.
Activation/désactivation d’une application
L’application 0 de sélection des applications n’affiche que les applications activées. Une vérification est faite aussi au moment d’afficher une application demandée. L’application option est la seule application activée par défaut et non désactivable, elle est en liste blanche.
Le mot clé utilisé :
nebule/objet/interface/web/php/applications/active
L’activation d’une application se fait sur trois critères :
- C’est l’application par défaut définit par l’option
defaultApplication
, elle est par défaut activée et non désactivable. - C’est une des applications en liste blanche. La liste blanche est une constante définie dans le bootstrap et dans la bibliothèque. Elleet non désactivable.
- L’entité instance du serveur a activé explicitement l’application par un lien.
L’entité maître du code bachue ne peut pas activer une application sauf à modifier les constantes dans le code.
Une application peut être activée/désactivée via l’application option, la seule application aujourd’hui en liste blanche. Il faut aller dans la partie des applications et il faut être connecté avec l’instance entité du serveur.
Le lien d’activation d’une application a la forme :
- action :
f
- source : objet de référence de l’application, par exemple =
e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
- cible : objet de référence d’activation =
e0e9ce893ea87b91f6e276b3839fed99f050168a0eb986354adc63abb3d7335c
- méta : objet de référence de l’application, par exemple =
e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
Pour que ce lien soit reconnu par le bootstrap, il doit être signé de l’entité instance du serveur, uniquement.
La désactivation est un lien de type x
.
Désactiver le pré-chargement d’une application
Le pré-chargement des applications est systématiquement réalisé par le bootstrap. Cependant ce pré-chargement qui se fait dans une page web intermédiaire et passagère peut poser problèmes pour certaines applications dans le cas d’une indexation par les moteurs de recherches ou pour l’échange inter-serveurs.
Le mot clé utilisé :
nebule/objet/interface/web/php/applications/direct
Il est possible de désactiver le pré-chargement de l’application en ajoutant le lien :
- action :
f
- source : objet de référence, par exemple =
e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
- cible : objet de référence de non pré-chargement =
9d019716a5335ee1f3bad59cbb9cc93132b0726129b26b52d6441a66c7c59a8d
- méta : objet de référence, par exemple =
e5ce3e9938247402722233e4698cda4adb44bb2e01aa0687
Pour que ce lien soit reconnu par le bootstrap, il doit être signé d’une autorité locale.
Les modules dans l’application
Les modules permettent de découper l’application en de multiples parties présentes ou optionnelles et activables au besoin. Cela donne beaucoup de souplesse pour des applications étendues, elles deviennent modulaires.
Un certains nombre de modules peuvent être par défaut intégrés dans l’application même (le même objet). D’autres peuvent être optionnels et ne pas être présent par défaut. Les modules optionnels peuvent être synchronisés plus tard et mise à jours séparément.
Les modules ne sont pas activés par défaut.
Fonctionnement
Les modules peuvent être de type :
- Application
- Traduction
- Skin (plus tard)
Chaque module doit contenir certaines informations sur son fonctionnement ainsi que des méthodes (programmes). Les modules doivent pour cela être des extensions (extend) du module de référence Modules dans la librairie nebule. Ils ne sont pas pris en compte si ce n’est pas le cas.
Activer les modules
Pour activer la recherche et le chargement des modules dans l’application, il faut surcharger dans la classe Application la variable :
protected $_useModules = true;
Le mot clé utilisé :
nebule/objet/interface/web/php/applications/modules
Créer un nouveau module
La création d’un module pour une application se fait en deux étapes, le référencement et le code.
Tout se fait dans l’application sylabe. Un module sera créer pour faciliter ce travail…
Le référencement
Cette partie est à faire au début lorsque l’on veut rendre visible et utiliser le nouveau module. Elle ne sera plus refaite par la suite. Le but est de permettre à l’application de trouver et d’utiliser le module.
…
Pour que ces liens soient reconnus par l’application, ils doivent tous être signés d’une autorité locale.
Le code
La création de la base d’un module est simple, il suffit de copier le modèle de module dans un nouveau fichier et dans un premier temps d’adapter les variables.
…
2 réflexions au sujet de « Applications »