28-12-2015, 01:16 AM
Un dossier "logs" est un dossier qui contiendra toutes les informations de journalisation du jeu. Par exemple, sur mes projets, j'ai un dossier "logs" dans lequel atterrissent les journaux de déploiement, les logs Apache ou (plus intéressant dans ton cas), les exceptions non-catchés du jeu (aka, quand une exception throw new ... n'est pas catch(ExceptionClass $ex), alors je la catch pour la journaliser dans logs/bugs/*.txt)
Bref, c'est un dossier où ranger les données générées par le code lui-même (on pourrait agrandir le principe à un dossier "codegen/", contenant "logs/" avec les journalisations, mais contenant aussi "cache/" où se trouvent des fichiers de cache).
Non, dans "config/", je n'ai pas les infos de connexion à la BDD. Ca, c'est la configuration liée au jeu. Et comme c'est celle utilisée par PHP, elle se trouve dans "php/eclerd/config/*.php". Dans config/, j'ai "apache/eclerd.vhost.conf" par exemple, qui est la configuration de mon hôte virtuel Apache (histoire d'avoir mon Eclerd en local à l'adresse 'eclerd.localhost'). J'ai la configuration pour Doxygen (génération de la documentation). Pour PHPUnit (tests unitaires, 'm'en suis pas trop servi... ^^ ) ou encore, des configurations pour d'autres scripts bash/batch.
Dans "sql/", j'ai mes fichiers SQL à exécuter sur la BDD pour l'initialiser (créer les tables et en rajouter ensuite; puis pour y mettre les données) et j'ai les fichiers SQL qui créent les procédures stockées utilisées ensuite par le jeu (je n'ai plus envie d'avoir des "SELECT ... FROM ..." et autres requêtes SQL chiantes dans mes codes PHP, je passe donc tout par des procédures; si c'est pas ton cas, tu n'auras pas ces fichiers de procédure, juste les fichier SQL d'initialisation de la BDD).
data/, je le réserve pour les fichiers générés par les utilisateurs. Par exemple, pour stocker leurs éventuels avatars. J'y mettrai aussi les données générées par le jeu, comme les cartes (Eclerd génère une carte du monde avec une info, comme la densité de population, et stocke cette image dans ce dossier, dans un sous-dossier "gen/map/*.png" par exemple).
C'est cela, www/handler contient les pages PHP qui vont aller appeler les codes PHP de php/eclerd/* qui eux, feront les vrais traitements. Et www/resources contient tous les fichiers statiques du site (css, js, images des batiments, etc).
resources/, t'en n'as peut-être simplement pas.
Perso, j'ai trouvé Mage (Magallanes) plus pratique que Jenkins (mais nécessitant Linux ou Cygwin). C'est plus léger à gérer.
Si tout n'est que popup, d'un avis personnel, je dirai que t'es dans la merde car tu n'auras aucune évolutivité et que "ça merde" sur les supports autres que ton écran 1920x1080 avec 1 barre d'outils en haut et 1 barre de favoris, en plein écran avec un clavier et ta souris. Bref, le navigateur est normalement là pour t'abstraire du support et tu perds cet avantage si tu fais des popup (on s'en contre-br*nle des "ouais mais Ajax ça évite de recharger la page, c'est plus performant" car c'est parfois faux, et surtout, gagner 1ms de temps réseau face à 100h de boulot de dev et une maintenance à s'arracher les cheveux, cela ne vaut pas le coup).
D'un point de vue moins personnel, le contenu de ta pop-up constitue une page. Ta page est l'URL appelée par ta requête Ajax. Popup ou pas, tu as donc toujours autant de pages
Donc, les pop-ups devraient appeler une page de ton "www/php/" (l'équivalent de mon "www/handler/") qui répercutera la demande au code php correspondant.
Le problème des chemins d'accès aux classes vient d'une mauvais configuration PHP. Pour ma part, j'ai ajouté à l'include_path (via ini_set ou set_include_path, je ne sais plus) le dossier "php/". Ensuite, SPL et son autoload (cherche sur duckduckgo tu trouveras) se démerde tout seul pour chercher les classes qui n'existent pas quand le code PHP en a besoin. Bilan: 0 require_once dans mes codes, 0 soucis avec ces histoires de chemins relatifs.
Bref, c'est un dossier où ranger les données générées par le code lui-même (on pourrait agrandir le principe à un dossier "codegen/", contenant "logs/" avec les journalisations, mais contenant aussi "cache/" où se trouvent des fichiers de cache).
Non, dans "config/", je n'ai pas les infos de connexion à la BDD. Ca, c'est la configuration liée au jeu. Et comme c'est celle utilisée par PHP, elle se trouve dans "php/eclerd/config/*.php". Dans config/, j'ai "apache/eclerd.vhost.conf" par exemple, qui est la configuration de mon hôte virtuel Apache (histoire d'avoir mon Eclerd en local à l'adresse 'eclerd.localhost'). J'ai la configuration pour Doxygen (génération de la documentation). Pour PHPUnit (tests unitaires, 'm'en suis pas trop servi... ^^ ) ou encore, des configurations pour d'autres scripts bash/batch.
Dans "sql/", j'ai mes fichiers SQL à exécuter sur la BDD pour l'initialiser (créer les tables et en rajouter ensuite; puis pour y mettre les données) et j'ai les fichiers SQL qui créent les procédures stockées utilisées ensuite par le jeu (je n'ai plus envie d'avoir des "SELECT ... FROM ..." et autres requêtes SQL chiantes dans mes codes PHP, je passe donc tout par des procédures; si c'est pas ton cas, tu n'auras pas ces fichiers de procédure, juste les fichier SQL d'initialisation de la BDD).
data/, je le réserve pour les fichiers générés par les utilisateurs. Par exemple, pour stocker leurs éventuels avatars. J'y mettrai aussi les données générées par le jeu, comme les cartes (Eclerd génère une carte du monde avec une info, comme la densité de population, et stocke cette image dans ce dossier, dans un sous-dossier "gen/map/*.png" par exemple).
C'est cela, www/handler contient les pages PHP qui vont aller appeler les codes PHP de php/eclerd/* qui eux, feront les vrais traitements. Et www/resources contient tous les fichiers statiques du site (css, js, images des batiments, etc).
resources/, t'en n'as peut-être simplement pas.
Perso, j'ai trouvé Mage (Magallanes) plus pratique que Jenkins (mais nécessitant Linux ou Cygwin). C'est plus léger à gérer.
Si tout n'est que popup, d'un avis personnel, je dirai que t'es dans la merde car tu n'auras aucune évolutivité et que "ça merde" sur les supports autres que ton écran 1920x1080 avec 1 barre d'outils en haut et 1 barre de favoris, en plein écran avec un clavier et ta souris. Bref, le navigateur est normalement là pour t'abstraire du support et tu perds cet avantage si tu fais des popup (on s'en contre-br*nle des "ouais mais Ajax ça évite de recharger la page, c'est plus performant" car c'est parfois faux, et surtout, gagner 1ms de temps réseau face à 100h de boulot de dev et une maintenance à s'arracher les cheveux, cela ne vaut pas le coup).
D'un point de vue moins personnel, le contenu de ta pop-up constitue une page. Ta page est l'URL appelée par ta requête Ajax. Popup ou pas, tu as donc toujours autant de pages
Donc, les pop-ups devraient appeler une page de ton "www/php/" (l'équivalent de mon "www/handler/") qui répercutera la demande au code php correspondant.Le problème des chemins d'accès aux classes vient d'une mauvais configuration PHP. Pour ma part, j'ai ajouté à l'include_path (via ini_set ou set_include_path, je ne sais plus) le dossier "php/". Ensuite, SPL et son autoload (cherche sur duckduckgo tu trouveras) se démerde tout seul pour chercher les classes qui n'existent pas quand le code PHP en a besoin. Bilan: 0 require_once dans mes codes, 0 soucis avec ces histoires de chemins relatifs.