Discussion :

[arnofly]

Slt !

Je suis en train de remettre à plat ce qui me sert de base pour pour le développement d'applications web et j'aimerai bien avoir votre retour d'expérience sur votre façon d'organiser vos dossiers et vos fichiers.

A l'époque, j'avais suivi une des structures les plus courantes qui ressemble à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
|— app
|    |
|    |— Controllers
|    |    |— ActuController.php
|    |    |— PostController.php
|    |    |— UserController.php
|    |
|    |— Models
|    |    |— ActuModel.php
|    |    |— PostModel.php
|    |    |— UserModel.php
|    |
|    |— views
|          |— actu.php
|          |— post.php
|          |— User.php
|
|— http
|    |
|    |— css
|    |
|    |— img
|    |
|    |— js
|    |
|    |— index.php
|
|— config.php

Avec le temps, j'ai fait des progrès j'ai commencé à utiliser les Interfaces et les Traits ont fait leur apparition. Comme en plus les projets prennent de l'ampleur, je réfléchis à modifier la structure de mes projets en pensant "module", un peu comme un plugin en fait.

Si je reprends l'exemple au dessus ça donne ça dans le dossier "app" :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
|— Actu
|    |— ActuController.php
|    |— ActuModel.php
|    |— actu.php
|
|— Traits
|    |— ReuseCodeTrait.php
|
|— Post
|    |— PostController.php
|    |— PostModel.php
|    |— post.php
|
|— User
|    |— UserController.php
|    |— UserModel.php
|    |— user.php

Seulement voilà, je suis un peu emmerdé maintenant avec les classes que je souhaite partager. Admettons que Post soit un Trait ou qu'il soit le contrôleur parent de Actu et User, qui sont 2 entités différentes, il était plus facile de charger Post avec l'ancienne structure, puisqu'un autoload savait d'office où aller chercher le contrôleur. Avec la nouvelle structure je devrai inclure les fichiers "manuellement" depuis le contrôleur de le requête. Bon, je dois pouvoir créer un autoload capable de charger les fichiers à inclure, mais avant de valider ma nouvelle structure j'aimerais bien avoir des avis. J'ai pensé aussi à mettre toutes les classes qui ne sont pas des entités dans un dossier commun que je pourrais appeler "shared" ou "class" par exemple.

Je discuterais bien de tout ça avec plaisir à la machine à café, mais je suis freelance et je bosse chez moi...

[arnofly]

Bon, je vois que ma question ne déchaine pas les passions

C'est dommage, parce que je me demande si ce n'est pas une connerie en fait, de tout réorganiser. D'autant que j'ai simplifié au maximum le premier exemple et que la structure réelle des dossiers est plus évoluée que ça.

A la racine de tous projets, j'ai en fait plusieurs dossiers avec des structures différentes :

• un dossier pour mon "framework maison" qui contient tous les fichiers indispensables à la logique applicative, comme un dispatcher, une classe d'abstraction pour la base de données, un dossier "lib" qui contient en autres une classe pour manipuler les fichiers, une autres les images, etc.
• un dossier pour le frontend qui correspond au premier exemple avec les dossiers MVC
• un dossier pour le backoffice qui correspond aussi au premier exemple avec les dossiers MVC
• un dossier accessible depuis un navigateur pour les ressources comme les images, css, JavaScript, etc. qui sont organisées chacune dans un répertoire qui lui est propre.

J'ai organisé tout ça de cette façon avant de connaître l’existence de l'autoload. J'ai créé des méthodes qui vont piocher les fichiers où il faut pour les inclure facilement. Ça marche bien, mais c'est pas automatique... En parallèle je prévois de modifier mon code pour utiliser les namespaces, dont je m'étais passé sans problème jusque là. J'ai déjà commencé avec les nouvelles classes. Leur usage semble faciliter la mise place d'un autoload et puis ça sera toujours bon de cloisonner mon code, ne serait ce que pour l’autocomplétion.

[oooopppp]

Salut,
voici ce que je fais, mais à mon avis ça va gueuler,
par contre c'est très pratique pour développer rapidement ...
( -> je crée et je donne un jeton encrypté qui va faire la navette entre l'user et le serveur,
pour pas que n'importe qui vienne foutre le bordel)
Après c'est de la déviance d'objet pour faire
de la prog. fonctionnelle et je fait de gros trucs avec ...

Voici donc :

- index.php (toues les requêtes passent par là)
- BIBLIOTHEQUES_PHP
- PHP
- IMG
- JS
- CSS
- backend
| - BIBLIOTHEQUES_PHP
| - PHP
| - IMG
| - JS
| - CSS
| - index.php

ensuite dans mon index.php : - J'appelle mon controller -> control.php

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
<?php
/*
* PlACIDO FRAMEWORK - 2018, 2019, 2020
* Copyright - Raf
* @ <xxx@xxx.com>
* script name : index.php
*/
 
session_start();
 
date_default_timezone_set('Europe/Paris'); // DEFINE TIMEZONE
setlocale(LC_TIME, array('fr_FR.UTF-8','fr_FR@euro','fr_FR','French')); // SET LOCA.
 
// include MUSTACHE
require 'Mustache/Autoloader.php';
Mustache_Autoloader::register();
 
// CALL PHP CLASSES
spl_autoload_register(function ($class) { include 'PHP/' . $class . '.php'; });
 
// START CONTROLLER
control::start();
 
?>

spl_autoload_register va appeler et mettre en cache toutes mes classes,
il fa&ut juste nommer les classes comme les fichier class control -> dans fichier control.php,
Puis à l'intérieur de mon controller par exemple, j'appelle des "public static functions" qui sont toutes à disposition
n'importe quand, n'importe où dans toutes mes autres classes (ça va gueuler!)
ex : control.php (voisi la fonction ::start() qui est appelée par l'index.php quoiqu’il arrive,
elle fait le tri et appelle la fonction adéquate

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
 
<?php
/*
* © Copyright 2019 Raf
* Organisation: xxxxxxxxxxx
* Web site: https://xxxxxxx.com
* @link <xxxx@xxxxx.com>
* Script name:	control.php
*
* function control::start();
*
* CONTROLLER OF API
*
*/
class control {
 
public static function start(){
 
 
// default request
 
 if(  empty($_POST['api']) && empty($_GET) ){
 
          // ask program to give the home page
          program::get_home_page();
 
          exit;
    }
 
//-----------------------------------------------------
 
    // POST REQUESTS
    if( !empty($_POST['api']) ){
 
 
        switch( $_POST['api'] ){
 
          // GET TEMPLATES
          case 'get_templates' :
              tools::get_templates();
          break;
 
          // GET THE JS OBJECT
          case 'get_obj' :
              program::get_home_page();
          break;
 
        // etc ...
}
/*
* end function start()
* CONTROLLER OF API
*
*/
 
 
}
//END CLASS CONTROL
?>

Alors certes c'est très simple mais à partir du controller je sais quelle fonction est appelée
et quand je rencontre une fonction, le fait de pourvoir appeler les static class par MaClasse::Ma_fonction();
est très, très pratique, pour débeuuguer, pour savoir qui fait fait quoi et quand ...
ça a l'air peut-être con, mais je me prend pas la tête avec les concepts objets poussés.
A noter qu'en PHP par exemple rien ne nous oblige à passer à tout prix par du tout objet,
j'utilise des libs. tout objet, je regrade la doc, j'utilise. ok.
Mais mon concept est simple et permet de se concentrer sur la logique et de développer des outils utilisables
de partout, par exemple si je veux un parseur/réducteur de saut de lignes en trop (pour les réduire)
je me crée une public static function parse_line_break($text){ .... } que je peux utiliser de partout dans mon
programme grâce au spl_autoload_register de PHP
ex: $parsed_text = tools::parse_line_break($text);

j'ai pas appris à l'école, désolé, mais je réalise des applis. assez conséquentes (qui fonctionnent vite et bien) avec ce système,
il suffit de bien réfléchir au nommage des classes et des fonctions, après c'est du beurre !
Voilà mon humble réponse,
mais encore une fois, je ne suis pas un dieu de l'objet, loin de là ...
crdlt,
raf

[arnofly]

Merci !

Moi aussi tout passe par le fichier index.php. Par contre, par sécurité, le dossier accessible par le navigateur est un sous dossier de mon appli.

En fait je crois comprendre que tu ne cherches pas trop à cloisonner en fait. Comme toi, je cherche à me simplifier la vie pour améliorer la réutilisabilité de mon code. Pour illustrer l'idée de vouloir créer des dossiers par module/entité c'est par exemple, le client veut des fiches produits :

• OK copier/coller du dossier "product" dans lequel j'ai tout ce qu'il faut (classes et vue) vers le dossier admin du nouveau projet
• Création de(s) table(s) dans la DB
• Adapter le code pour le projet, mais entre 80% et 90% du job est déjà fait

Je procédè déjà comme ça, c'est juste que c'est plus chiant parce que je dois copier/coller fichier par fichier. Cela dit, je crois que je vais rester sur l'architecture "classique" des dossiers MCV, car un autoload efficace va m'apporter plus que ce petit confort du dossier de module à copier/coller. Là je suis en train de perdre un temps fou pour des conneries. L'autoload avec un structure en "modules" je vois comment le coder, mais l'idée que j'ai en tête va rendre mon appli moins performante puisqu'il va falloir passer en revue tous les dossiers susceptibles de contenir un fichier à inclure, alors qu'actuellement comme ils ont tous concentrer dans le même dossier c'est plus simple (les contrôleurs dans le dossier des contrôleurs, etc.).

Bon cela dit, j'ai vu sur stackoverflow.com (la communauté trop sympa) quelqu'un qui organise aussi son code par "module" et d'après ce que j'ai appris avec les namespace c'est peut être pas si déconnant, mais là je peux plus attendre l'avis des uns et des autres. Je pensais/espérais avoir plus de retours... Tout le monde bosse sur WordPress ou quoi ! En tout cas, je me passe de Framework PHP depuis mes débuts, mais dans ce genre de cas de figure, je me dis qu'un Framework m'éviterait sans doute de me prendre la tête. Cet aspect des Frameworks à imposer une structure me plait bien en fait. De là à sauter le pas... je crois que c'est trop tard, car ça fait trop longtemps que j'ai appris à faire sans.

Bref, en tous cas merci pour ton retour d'expérience. La nuit porte conseille

[oooopppp]

Salut,
j'ai exactement les mêmes doutes que toi ...
Mais bon il faut bien avancer et gagner sa croûte,
l’essentiel est que ça fonctionne et assez rapidement ...
Si tu veux on pourrait se capter en skype un de ces 4 (si j'arrive à dégager du temps ...)
pour en parler et comparer nos config. / nos espérances ...
Si tu veux voir mon modèle en action sur un gros site : www.severac.org ,
ça fonctionne pas mal, je fait de la réservation pour hôtels et gîtes aussi, là aussi ça fonctionne bien,
après il faut être malin, en objet ou en procédural, si on fait 3000 appels de suite à la DB, ça rame ...
A+!
Et bon courage !

p.s: oui les namespaces ça a l'air sympa, mais j'ai toujours pas compris si vraiment c'est aussi simple que de nommer
une classe ou si il y a des mécanismes qui m'échappe derrière ... Je ne l'utilise pas ... Mais je suis touours partant pour me foutre
des coups de pieds au cul et appendre de la techno !

[arnofly]

Slt,

Ouais échanger sur notre méthodologie, je suis partant aussi, mais comme toi, pas demain car je suis noyé par le travail en ce moment en grande partie à cause des changements que je n'arrête pas d'opperer sur mon code pour in fine devenir plus productif. Bref, content d'être freelance, mais me sens un peu seul au monde et parfois c'est pesant. Et quand tu rencontres une galère, là ou un dev dans une boîte peut demander à un collègue, et bien le freelance... ta compris. C'est formateur, c'est le moins que l'on puisse dire Je n'ai pas toujours était développeur (moi aussi je suis autodidacte) et avant j'étais dans les avions avec 150 passagers à distraire Le contraste est saisissant avec ma situation de développeur indépendant Mais bon, je suis passionné et je ne reviendrais pas en arrière.

Sinon, je suis mal placé pour te faire un cours sur les namespace, mais de ce que j'ai compris, ça facilite la mise en place d'un autoloader et ça permet d'avoir plusieurs méthodes avec un même nom dans un projet et par la même occasion de bien dissocier ton code des fonctions PHP et du coup ça se répercute sur l'auto-complétion de ton IDE. Je m'y suis intéressé principalement pour c'est ce dernier point ! Une auto-complétion "bien organisée" c'est cool. Sinon, c'est surtout pratique pour les gens qui utilisent pas mal de sources externes (ce qui n'est pas du tout mon cas) et les gros projets. Grâce aux namespace, tu vas pouvoir virer les préfixes que tu dois certainement mettre à tes méthodes pour les regrouper logiquement. Du coup, ton préfixe c'est plus ou moins ton namesapce En ce qui me concerne, j'ai un fichier dans lequel j'ai regroupé quelques fonctions et bien pour avoir un visu de toute la liste dans l'autocomplétion je les avais préfixé de mon vendor name. Ce préfixe va devenir un namespace. C'est plus propre et ça apporte aussi de la lisibilité. Pour les méthodes des classes je me passais de préfixe, mais par contre elles pouvaient être un peu "noyée" par les fonctions PHP dans l'auto-complétion, avec les namespace ça ne sera plus le cas. Honnêtement, je regrette de ne pas m'y être intéressé plus tôt, tout comme pour les Traits qui sont bien pratiques et que je commence tout juste à utiliser.

Bon à plus

PS : Je suis allé voir ton projet, effectivement il à l'air bien balaise, ce qui n’empêche pas les pages de se charger rapidement