Documentation de la solution web de gestion OpenFlyers version 3 - Contributions de l’utilisateur [fr]

Fichier:Of key.png

2006-06-11T13:16:26Z

KAeL :

Discussion:Coding rules

2006-01-04T08:17:51Z

KAeL : /* Votes */

=Format des variables=
Je suis pour le respect du format suivant concernant les variables :
$thisIsAnExample

J'ai pas trouvé de telle obligation dans PEAR alors que je pensais que c'était le cas... En fait c'est restreint aux fonctions. De même je pensais que c'était clairement décrit dans notre propres règles et il n'en n'est rien.

Donc le sujet est ouvert...

--[[User:Claratte|Christophe]] 15:53, 30 December 2005 (CET)

Je suis d'accord, j'aime aussi ce format, mais uniquement pour les variables php.

Par contre, pour les variables html (ce qui passe en POST ou en GET), je préfère les underscore, tout simplement parce que je n'aime pas voir des majuscules dans la barre d'adresse :)

En gros, j'aime assez le format suivant :
Variables php :
$thisIsAnExemple
"Variables" html :
this_is_an_exemple
Functions php :
thisIsAnExemple()
Et les noms de classes avec une majuscule

--[[User:Zebuline|Zebuline]] 15:59, 30 December 2005 (CET)

Dans ce cas pourquoi ne pas re-formater lors de "l'import" :
$thisIsAnExample = getPost('this_is_an_example')

Néanmoins, je préfère même pour html utiliser la règle générale. Je ne vois pas où est le problème (avec html).

Y'a un truc aussi : normalement dans la barre d'adresse doit y avoir que l'adresse, pas de variable. Ces dernières doivent être passées par POST.

--[[User:Claratte|Christophe]] 16:06, 30 December 2005 (CET)

Heu, le reformattage, je le fais déjà ? Où est le pb ? --[[User:Zebuline|Zebuline]] 16:13, 30 December 2005 (CET)

Je voyais tellement de fois aircraft_id dans ton fichier open_flight que je pensais qu'il s'agissait de la variable php...

Sinon, voici un lien concernant les [http://www.port80software.com/support/articles/nextgenerationurls urls propres]

--[[User:Claratte|Christophe]] 16:17, 30 December 2005 (CET)

Je n'ai aps donné mon avis pour le format javascript ...

D'ailleurs, qu'appelles-tu variable javascript ? Les trucs avec un var devant ? Si oui, je suis favorable au format thisIsAnExample. Sinon, si tu appelles des variables javascript ce qu'on récupère sur un formulaire, comme c'est du html, je suis pour le format this_is_an_example.

--[[User:Zebuline|Zebuline]] 23:38, 3 January 2006 (CET)

Je parlais des deux à la fois. Mais on peut encore plus dissocier. Je rectifie donc la présentation du vote.

--[[User:Claratte|Christophe]] 23:52, 3 January 2006 (CET)
==Votes==
Concensus pour utiliser le format thisIsAnExample dans les variables PHP et JavaScript.

Vote sur le format des variables transmises dans les formulaires HTML :
{| {{prettytable}}
!Proposition!!Votant pour
|-
|utiliser le format thisIsAnExample||--[[User:Claratte|Christophe]] 15:58, 30 December 2005 (CET)
|-
|format this_is_an_example, par analogie avec les varaibles qui passent en GET : pour ne pas avoir de majuscules dans l'url ||--[[User:Zebuline|Zebuline]] 23:56, 3 January 2006 (CET)
|-
|moi je suis pour uiliser thisIsAnExample partout en PHP. Pour les variables GET, je suis pas contre utiliser my_var. En javascript, je sais pas du tout ce qui est couremment utilisé comme convention d'écriture, mais pourquoi pas myVar. ||--[[User:KAeL|KAeL]] 09:17, 4 January 2006 (CET)
|}

Discussion:Main Page

2005-11-03T13:40:18Z

KAeL : /* Dans tous les cas */

''Cette page de discussion peut être l'équivalent du "bar du coin" ou on parle des choses en général.''

==Multilanguisme & xml/xsl==
Plusieurs possibilités s'offrent à nous sur la façon de "moderniser" l'implémentation existante dans la version 1.2 d'OF du mulilanguisme.

===Tout d'abord, il y a deux méthodes de stockage des traductions :===
*par base de données (dans ce cas on se tournerait vers la classe Translation2)
*en mettant les textes dans du xml. Mais on perd en facilité de maintenance, ou alors on crée (ou on trouve) une classe qui gère ça.

Mon avis :
la base de donnée n'est pas adapté : les données sont statiques, et la base de données c'est trop lent (on va pas faire 40 requetes par page).
xml : soit on parse à chauqe fois le fichier pour trouver la traduction (trop lent), soit on le parse une fois et on le met en mémoire (et donc, autant utiliser un fichier type .ini avec identifiant=valeur, c'est plus léger)
--[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:29 (CET)

===Ensuite, vient la méthode de conversion de la feuille xsl :===
Dans les deux cas, on part d'une feuille xsl qui va contenir des balises <text> définissant le texte à remplacer dans la bonne langue par exemple :

<nowiki><center>
<text>aircraft list</text>
<xsl:value-of select="registration"/>
</center></nowiki>

On a donc deux choix :

*soit on effectue la transformation du <text>aircraft list</text> en premier puis on obtient une deuxième feuille XSL (en fait la même que celle de Joël)
*soit on effectue la transformation du xml via la feuille de style "générique", on obtient alors une sortie presque-html avec les <text> puis on les remplace par la langue finale.

Intérêt de la première méthode : on peut mettre en cache nos feuilles de styles adaptées à chaque langue, sachant que les modifications sur les langues ne doivent pas apparaitre dans une version stable d'OF.

Intérêt de la seconde méthode : elle me parait plus simple...

Ã‡a me parait assez lourd comme approche --[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:30 (CET)

===Dernier point : mappage xml/base de données===
Dans translation2, les textes sont référencés selon 2 éléments (cf. [[Translation_Table]]) : un id qui "nomme" le texte et un page_id. Ainsi on peut avoir deux ids identiques mais sur des pages différentes. D'ou ma question : comment en verriez-vous l'utilisation concrète ? (quelles règles on se fixe ?)

Je vous propose la suivante, on fait un "mappage" base de données/xml ainsi :

<text page="admin">aircraft list</text>

avec le contenu élément de text qui correspond à l'id de la base de données et l'attribut page qui correspond au page_id.

Avantage : on peut définir une page générique (champ page_id vide dans la base et sans attribut page sur le xml) qui contient les intitulés qui reviennent le plus souvent (comme "valider", "annuler", etc.)

Inconvénient : la présence très fréquente de l'attribut page qui n'apporte pas grand chose.

Une autre méthode : on ne met pas d'attribut page, et pour faire la relation on utilise le nom de la feuille xsl comme page_id.

Avantage : c'est plus léger pour la page xsl

Inconvénient : faut ré-écrire pour chaque page des mots identiques

J'attend vos avis ;-)
--[[Utilisateur:Claratte|Christophe]] 30 Sep 2005 à 01:47 (CEST)

pareil qu'avant, je ne pense pas que ni xml ni une base de données ne soient les plus adaptés à la situation --[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:32 (CET)

== Dans tous les cas ==

Je pense que dans tous les cas, on devrait commencer par se faire une classe OfTranslator avec qq méthodes génériques :
setLang('fr')
getLang() -> renvoie 'fr'
getAvailableLangs() -> renvoie array('fr', 'en', ...)
tr('hi') -> salut (tr comme translate)

Après derrière, on peut coder nos fonctions à nous où utiliser une classe PEAR comme Translation2.

La question est : comment on stocke les données ?
* en xml (qd on choisit la langue, on stocke les traductions en mémoire)
* ds un fichier .ini (même remarque)
* en base de données (lent, pas adapté)
* en utilisant gettext (des infos ici : [http://www.gnu.org/software/gettext/manual/html_mono/gettext.html#SEC1 GNU gettext]) (supporté par Translation2)

--[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:40 (CET)

Discussion:Main Page

2005-11-03T13:40:00Z

KAeL : /* Multilanguisme & xml/xsl */

Discussion:Main Page

2005-11-03T13:32:00Z

KAeL : /* Dernier point : mappage xml/base de données */

Discussion:Main Page

2005-11-03T13:31:47Z

KAeL : /* Dernier point : mappage xml/base de données */

''Cette page de discussion peut être l'équivalent du "bar du coin" ou on parle des choses en général.''

==Multilanguisme & xml/xsl==
Plusieurs possibilités s'offrent à nous sur la façon de "moderniser" l'implémentation existante dans la version 1.2 d'OF du mulilanguisme.

===Tout d'abord, il y a deux méthodes de stockage des traductions :===
*par base de données (dans ce cas on se tournerait vers la classe Translation2)
*en mettant les textes dans du xml. Mais on perd en facilité de maintenance, ou alors on crée (ou on trouve) une classe qui gère ça.

Mon avis :
la base de donnée n'est pas adapté : les données sont statiques, et la base de données c'est trop lent (on va pas faire 40 requetes par page).
xml : soit on parse à chauqe fois le fichier pour trouver la traduction (trop lent), soit on le parse une fois et on le met en mémoire (et donc, autant utiliser un fichier type .ini avec identifiant=valeur, c'est plus léger)
--[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:29 (CET)

===Ensuite, vient la méthode de conversion de la feuille xsl :===
Dans les deux cas, on part d'une feuille xsl qui va contenir des balises <text> définissant le texte à remplacer dans la bonne langue par exemple :

<nowiki><center>
<text>aircraft list</text>
<xsl:value-of select="registration"/>
</center></nowiki>

On a donc deux choix :

*soit on effectue la transformation du <text>aircraft list</text> en premier puis on obtient une deuxième feuille XSL (en fait la même que celle de Joël)
*soit on effectue la transformation du xml via la feuille de style "générique", on obtient alors une sortie presque-html avec les <text> puis on les remplace par la langue finale.

Intérêt de la première méthode : on peut mettre en cache nos feuilles de styles adaptées à chaque langue, sachant que les modifications sur les langues ne doivent pas apparaitre dans une version stable d'OF.

Intérêt de la seconde méthode : elle me parait plus simple...

Ã‡a me parait assez lourd comme approche --[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:30 (CET)

===Dernier point : mappage xml/base de données===
Dans translation2, les textes sont référencés selon 2 éléments (cf. [[Translation_Table]]) : un id qui "nomme" le texte et un page_id. Ainsi on peut avoir deux ids identiques mais sur des pages différentes. D'ou ma question : comment en verriez-vous l'utilisation concrète ? (quelles règles on se fixe ?)

Je vous propose la suivante, on fait un "mappage" base de données/xml ainsi :

<text page="admin">aircraft list</text>

avec le contenu élément de text qui correspond à l'id de la base de données et l'attribut page qui correspond au page_id.

Avantage : on peut définir une page générique (champ page_id vide dans la base et sans attribut page sur le xml) qui contient les intitulés qui reviennent le plus souvent (comme "valider", "annuler", etc.)

Inconvénient : la présence très fréquente de l'attribut page qui n'apporte pas grand chose.

Une autre méthode : on ne met pas d'attribut page, et pour faire la relation on utilise le nom de la feuille xsl comme page_id.

Avantage : c'est plus léger pour la page xsl

Inconvénient : faut ré-écrire pour chaque page des mots identiques

J'attend vos avis ;-)
--[[Utilisateur:Claratte|Christophe]] 30 Sep 2005 à 01:47 (CEST)
pareil qu'avant, je ne pense pas que ni xml ni une base de données ne soient les plus adaptés à la situation

Discussion:Main Page

2005-11-03T13:30:20Z

KAeL : /* Ensuite, vient la méthode de conversion de la feuille xsl : */

Discussion:Main Page

2005-11-03T13:29:11Z

KAeL : /* Tout d'abord, il y a deux méthodes de stockage des traductions : */

''Cette page de discussion peut être l'équivalent du "bar du coin" ou on parle des choses en général.''

==Multilanguisme & xml/xsl==
Plusieurs possibilités s'offrent à nous sur la façon de "moderniser" l'implémentation existante dans la version 1.2 d'OF du mulilanguisme.

===Tout d'abord, il y a deux méthodes de stockage des traductions :===
*par base de données (dans ce cas on se tournerait vers la classe Translation2)
*en mettant les textes dans du xml. Mais on perd en facilité de maintenance, ou alors on crée (ou on trouve) une classe qui gère ça.

Mon avis :
la base de donnée n'est pas adapté : les données sont statiques, et la base de données c'est trop lent (on va pas faire 40 requetes par page).
xml : soit on parse à chauqe fois le fichier pour trouver la traduction (trop lent), soit on le parse une fois et on le met en mémoire (et donc, autant utiliser un fichier type .ini avec identifiant=valeur, c'est plus léger)
--[[Utilisateur:KAeL|KAeL]] 3 Nov 2005 à 14:29 (CET)

===Ensuite, vient la méthode de conversion de la feuille xsl :===
Dans les deux cas, on part d'une feuille xsl qui va contenir des balises <text> définissant le texte à remplacer dans la bonne langue par exemple :

<nowiki><center>
<text>aircraft list</text>
<xsl:value-of select="registration"/>
</center></nowiki>

On a donc deux choix :

*soit on effectue la transformation du <text>aircraft list</text> en premier puis on obtient une deuxième feuille XSL (en fait la même que celle de Joël)
*soit on effectue la transformation du xml via la feuille de style "générique", on obtient alors une sortie presque-html avec les <text> puis on les remplace par la langue finale.

Intérêt de la première méthode : on peut mettre en cache nos feuilles de styles adaptées à chaque langue, sachant que les modifications sur les langues ne doivent pas apparaitre dans une version stable d'OF.

Intérêt de la seconde méthode : elle me parait plus simple...

===Dernier point : mappage xml/base de données===
Dans translation2, les textes sont référencés selon 2 éléments (cf. [[Translation_Table]]) : un id qui "nomme" le texte et un page_id. Ainsi on peut avoir deux ids identiques mais sur des pages différentes. D'ou ma question : comment en verriez-vous l'utilisation concrète ? (quelles règles on se fixe ?)

Je vous propose la suivante, on fait un "mappage" base de données/xml ainsi :

<text page="admin">aircraft list</text>

avec le contenu élément de text qui correspond à l'id de la base de données et l'attribut page qui correspond au page_id.

Avantage : on peut définir une page générique (champ page_id vide dans la base et sans attribut page sur le xml) qui contient les intitulés qui reviennent le plus souvent (comme "valider", "annuler", etc.)

Inconvénient : la présence très fréquente de l'attribut page qui n'apporte pas grand chose.

Une autre méthode : on ne met pas d'attribut page, et pour faire la relation on utilise le nom de la feuille xsl comme page_id.

Avantage : c'est plus léger pour la page xsl

Inconvénient : faut ré-écrire pour chaque page des mots identiques

J'attend vos avis ;-)
--[[Utilisateur:Claratte|Christophe]] 30 Sep 2005 à 01:47 (CEST)

Discussion:Coding FAQ

2005-07-03T21:09:22Z

KAeL :

'''Pourquoi je n'aime pas " l'url unique " :'''

le fait d'avoir plusieurs fichiers en racine permet tt de même de protéger certains fichiers en les mettant ds des sous dossiers en 'deny all'.

au niveau sécu :
c'est pas compliqué d'include ds chaque page pouvant être appelée un truc genre secu.php qui gère ça. (utilisation courante qd on utilise la classe PEAR::Auth par exemple)

au niveau maintenance :
il faut maintenir une page en plus : index.php, qui a rapidement tendance à devenir une usine à gaz

au niveau des chemins d'accès, mettre tout les fichiers pouvant être inclus dans un répertoire 'include' (ou plusieurs) et configurer php pour mettre ces dossiers ds le include_path par défaut, ça se fait bien aussi. (les fichiers ne bougeant pas de place, on peut aussi utiliser des chemins relatifs).
et sinon, on peut toujours utiliser $_SERVER['DOCUMENT_ROOT'] par exemple pour faire le ini_set include_path...
(je reconnais qu'avec un fichier c'est plus pratique, mais avec plusieurs ça n'a rien d'insurmontable)

Je vois pas le pb pour un utilisateur de referencer une page autre que index ? il fait ce qu'il veut.

au niveau de la simplicité de l'url, je ne comprends pas en quoi c'est si bien ? des sites genre google, amazon et quasiment tout ceux que je connais ne se posent pas trop cette question.

Discussion:Flight Table

2005-06-01T17:17:51Z

KAeL :

Attention à la gestion des compteurs qui comportent généralement une virgule la valeur en mémoire devra être x 100 N'ayant pas de compteur négatif on pourrait choisir longword

== Choix du type de colonne numérique pour les compteurs ==

En fait, ni longint ni longword n'existent ;-) (c'est du delphi)

Voici les types qui peuvent aller :

{| {{prettytable}}
!nom du type!!valeur max en non signé
|-
|tinyint||255
|-
|smallint||65535
|-
|mediumint||16 77 215
|-
|int||4 294 967 295
|-
|bigint||18 446 744 073 709 551 615
|-
|decimal(x,2)||
|}

Modèle:Prettytable

2005-06-01T17:16:48Z

KAeL :

border="2" cellpadding="4" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse; font-size: 95%;"