Forum |  HardWare.fr | News | Articles | PC | Prix | S'identifier | S'inscrire | Aide | Shop Recherche
1643 connectés 

 



Pour ou contre du changement sur le topic ?


 
35.7 %
 5 votes
1.  Oui, faq / bonnes pratiques + blabla@php
 
 
0.0 %
        0 vote
2.  Oui, blabla@php uniquement
 
 
7.1 %
 1 vote
3.  Ce topic mérite la poubelle. Pauvre poubelle
 
 
21.4 %
 3 votes
4.  Non, ce topic reste tel quel
 
 
35.7 %
 5 votes
5.  Obiwan n'aime pas le php
 

Total : 16 votes (2 votes blancs)
Ce sondage est clos, vous ne pouvez plus voter
 Mot :   Pseudo :  
  Aller à la page :
 
 Page :   1  2  3  4  5  ..  63  64  65  66  67  68
Page Suivante
Auteur Sujet :

blabla@php | faq et bonnes pratiques page 1

n°2331594
depart
Posté le 09-04-2019 à 10:00:43  profilanswer
 

Reprise du message précédent :
Donc de votre côté vous passez directement les var du type $_POST['nom'], $_POST['adresse'], $_POST['commentaire'], ... aux "prepared statements" d'une requête SQL ?

mood
Publicité
Posté le 09-04-2019 à 10:00:43  profilanswer
 

n°2331600
ydalb
In Crêpes n' Cidre I Trust!
Posté le 09-04-2019 à 11:45:03  profilanswer
 

Yes, avec éventuellement un trim histoire de vérifier les espaces superflus.


Message édité par ydalb le 09-04-2019 à 11:45:28

---------------
:o
n°2331601
ratibus
Posté le 09-04-2019 à 11:46:52  profilanswer
 

depart a écrit :

Donc de votre côté vous passez directement les var du type $_POST['nom'], $_POST['adresse'], $_POST['commentaire'], ... aux "prepared statements" d'une requête SQL ?


Je t'invite à te renseigner sur le concept d'injection de dépendance.

n°2331604
depart
Posté le 09-04-2019 à 12:26:31  profilanswer
 

ratibus a écrit :


Je t'invite à te renseigner sur le concept d'injection de dépendance.


 
Je ne vois pas le rapport.
 
Là typiquement j'ai un formulaire compliqué mais qui ne sert qu'une fois dans l'appli (genre de panneau de config on va dire), avec une centaine de champs de tout type (case à cocher, dates, noms, texte libre, même un champ avec un ckeditor donc du html...), je cherche juste le moyen 'minimum' le plus propre et efficace pour faire un bête update de tout ça en bdd, j'ai pas d'objet, juste du bon vieux procédural.
 
Après je veux bien comprendre que si on passe par des objets, on ne balance pas les variables $_POST[] à l'intérieur de l'objet...
 
Bon donc en gros là ça me donne qqch du genre :
 
HTML :

<input id="prenom" type="text" name="prenom">
<textarea id="papier_entete" name="papier_entete"></textarea>
...


PHP


if( !isset($_POST['prenom']) ) {
 array_push($err,"Le champ prenom est incorrect" );
} else {
 $prenom= trim($_POST['prenom']) ;
}
if( !isset($_POST['papier_entete']) ) {
 array_push($err,"Le champ entête est incorrect" );
} else {
 $papier_entete = trim($_POST['papier_entete']) ;
}
...
if (count($err)>0) {
 foreach($err as $e){
  echo $e."<br>" ;
 }
 die() ; // un peu brutozaure mais en même temps on n'est pas censés être dans ce cas car c'est géré en amont en JS
}
 
 


éventuellement pour certains champs je rajoute des is_numeric() ou !='' dans le if selon les attentes. Je suis en train de me construire une petite fonction de tests genre verif($chaine,"H:i" ) ou verif($chaine,"numerique_ou_vide" ) ou ce genre de chose, qui retourne 0/1 en fonction de tests du type est-ce que la chaine ressemble à "17:32" ou pas, histoire de ne pas stocker "toto" dans un champ où je suis censé avoir une heure... et ne pas réécrire 10 000 fois les mêmes tests ou regex.
 
et après ma requête :

$query = "
   UPDATE client  
   SET papier_entete = :papier_entete,
...
WHERE client_id = :client_id";
$stmt = $pdo->prepare($query);
$stmt->bindParam(':papier_entete', $papier_entete, PDO::PARAM_STR);
$stmt->execute();
 


 
Ca vous parait ok ?
J'aimerai bien simplifier au max le code de "test" pour chaque champ, genre encapsulter la gestion d'erreur, vous avez des suggestions ? Il y a quand même un paquet de cas en dehors des simples "emails,numérique..."
genre  
- n'autoriser qu'une valeur parmi une liste (par ex, une var qui peut contenir 0 1 2 ou 3 mais rien d'autre)
- un seuil mini et maxi (ou un seul des 2)
- toutes une tripotée de formats de dates/heures
- de champs vides ou non
- une longueur de chaîne stricte
...
 
Ca serait bien également de pouvoir "préparer le travail" pour les $stmt->bindParam() par la suite histoire de ne pas avoir à se les retaper tous manuellement.


Message édité par depart le 09-04-2019 à 14:27:38
n°2331640
depart
Posté le 09-04-2019 à 16:14:06  profilanswer
 

Bon je poursuis, mode gros cracra mais ça marche...
 
Quelques fonctions  

function is_input_ok($chaine, $type, $longueur_max = 4000) {
 
 $rexSafety = "/[\^<,\"@\/\{\}\(\)\*\$%\?=>:\|;#]+/i";
 
 switch ($type) {
   
  // pour valider des champs courts comme un nom, prénom, ... qui ne sont pas censés contenir de caractères bizarres, de code html...
  // on se base sur une liste d'exclusion
  case 'chaine_simple' :
   if (strlen($chaine) == 0 ) return 0 ;
   if (strlen($chaine) > $longueur_max) return 0 ;
   if (preg_match($rexSafety, $chaine)) return 0 ;
   return 1 ;
  break ;
   
  case 'chaine_simple_ou_vide' :
   if (strlen($chaine) > $longueur_max) return 0 ;
   if (preg_match($rexSafety, $chaine)) return 0 ;
   return 1 ;
  break ;
   
  case 'chaine' :
   if (strlen($chaine) > $longueur_max) return 0 ;
   return 1 ;
  break ;
   
  case 'bool' :
   if($chaine != 0 || $chaine != 1 ) return 0 ;
   return 1 ;
  break ;
   
  case 'entier' :
   if ( !ctype_digit($chaine)  ) return 0 ;
   return 1 ;
  break ;
   
  case 'numerique' :
   if ( !is_numeric($chaine)  ) return 0 ;
   return 1 ;
  break ;
   
  case 'numerique_ou_vide' :
   if ( $chaine!='' && !is_numeric($chaine)  ) return 0 ;
   if (strlen($chaine) > $longueur_max) return 0 ; // compter une longueur sur un numérique c'est étrange ? pas tant que ça car on récupère des champs de form, donc tout le temp des strings
   return 1 ;
  break ;
   
  case 'password' :
   if (strlen($chaine) < 8 || strlen($chaine) > $longueur_max) return 0 ;
   return 1 ;
  break ;
   
  case 'password_ou_vide' :
   if (strlen($chaine) >1 && (strlen($chaine) < 8 || strlen($chaine) > $longueur_max)) return 0 ;
   return 1 ;
  break ;
   
  case 'email' :
   if (empty(filter_var($chaine, FILTER_VALIDATE_EMAIL)) ) {
    return 0 ;
   } else {
    return 1 ;
   }
  break ;
   
  case 'H:i' :
   if ( !preg_match("/^\d{1,2}:\d{2}$/", $chaine)) {
    return 0 ;
   } else {
    return 1 ;
   }
  break ;
   
  default :  
   return 1 ;
  break ;
   
   
  }
}
 
// corrolaire de la fonction au dessus, mais avec une couche de gestion d'erreur
function test_post_field($nom_champ,$type,$longueur = 4000) {
 if(!isset($GLOBALS['err'])) {
  $GLOBALS['err'] = array();
 }
 if($type != 'case_a_cocher') {
  if( !isset($_POST[$nom_champ]) || !is_input_ok(trim($_POST[$nom_champ]), $type, $longueur)  ) {
   array_push($GLOBALS['err'],"Le champ ".$nom_champ." est incorrect avec sa valeur ".htmlentities($_POST[$nom_champ]));
   return 0 ;
  } else {
   return 1 ;
  }
 } else {
  // pour les cases à cocher on ne peut rien tester, soit le champ existe soit il n'existe pas, on s'en fiche de la valeur
   return 1 ;
   
 }
}
// version spécifique dédiée à tester ET préparer un tableau de "prepared statements" PDO
function test_bind_post_field($nom_champ,$type,$longueur = 4000) {
 if(!isset($GLOBALS['tab_bind_params'])) {
  $GLOBALS['tab_bind_params'] = array();
 }
 
 
 if (test_post_field($nom_champ,$type,$longueur = 4000)) {
  switch ($type) {
   case 'bool' :  
   case 'case_a_cocher' :  $pdo_type = PDO::PARAM_BOOL ; break ;
   case 'entier' :   $pdo_type = PDO::PARAM_INT ; break ;
   default :     $pdo_type = PDO::PARAM_STR ; break ;
  }
  // les cases à cocher (booléens) sont un cas particulier : si le champ n'est pas défini c'est normal, c'est que la case n'est pas cochée
  // il faut convertir ça en vrai booléen : 0 et 1  
  if($type == 'case_a_cocher') {
   $valeur = (int)isset($_POST[$nom_champ]) ;
  } else {
   $valeur = $_POST[$nom_champ] ;
  }
   
  array_push($GLOBALS['tab_bind_params'],array($nom_champ,$valeur,$pdo_type)) ;
  return 1 ;
 } else {
  return 0 ;
 }
 
}


 
Du coup dans mes formulaires ça donne des trucs comme :
 

test_bind_post_field("news","case_a_cocher" ) ;
test_bind_post_field("prefixe_tel_defaut","entier" ) ;
test_bind_post_field("prenom","chaine_simple", 200) ;
test_bind_post_field("agenda_heure_debut","H:i" ) ;
...
 
if (count($err)>0) {
 foreach($err as $e){
  echo htmlentities($e)."<br>" ;
 }
 die() ;
}
 
$query = "UPDAte..." ;
$stmt = $pdo->prepare($query);
$stmt->bindParam(':client_id', $mon_client->get_client_id(), PDO::PARAM_INT);
...
foreach($tab_bind_params as $elt){
 $stmt->bindParam(':'.$elt[0], $elt[1], $elt[2]);
}
   
 


Message édité par depart le 09-04-2019 à 16:17:28
n°2332488
B4X
kebab-case
Posté le 26-04-2019 à 15:00:28  profilanswer
 

"qui ne sert qu'une seule fois dans l'appli". Pourquoi est-ce que tu t'embête tellement alors? Autant poursuivre ta démarche procédurale et tester chaque input un par un. Je ne comprends pas l'intérêt pour une petite appli.
 
Sinon dans l'idée c'est correct.
Tu pourrais améliorer tes fonctions pour autoriser la syntaxe suivante:

Code :
  1. test_bind_post_field([
  2.     'news' => 'case_a_cocher',
  3.     'prefixe_tel_defaut' => 'entier',
  4.     'etc' => 'etc'
  5. ]);


Et surtout, tu pourrais permettre de piper les tests:

Code :
  1. test_bind_post_field([
  2.     'motDePasse' => 'chaine|min:8|max:255',
  3.     'etc' => 'etc'
  4. ]);


 
Au final, tu vas réinventer la roue. Ceci devrait te plaire: https://github.com/Wixel/GUMP


---------------
In vanitas veritas.
n°2332491
depart
Posté le 26-04-2019 à 15:49:54  profilanswer
 

B4X a écrit :

"qui ne sert qu'une seule fois dans l'appli". Pourquoi est-ce que tu t'embête tellement alors? Autant poursuivre ta démarche procédurale et tester chaque input un par un. Je ne comprends pas l'intérêt pour une petite appli.


Ces champs précis ne servent qu'une fois dans l'appli. Mais dans l'appli j'ai pas mal de formulaires avec des saisies utilisateur (c'est une appli de gestion d'un type d'activité pro, ou le professionnel saisit des infos sur ses clients, ses rendez-vous avec eux, ...). Donc dans l'ensemble de l'appli je dois avoir une vingtaine de formulaires portant sur probablement 200 ou 300 champs d'où ma recherche de quelque chose avec le minimum de répétition de code.
 

B4X a écrit :

Sinon dans l'idée c'est correct.
Tu pourrais améliorer tes fonctions pour autoriser la syntaxe suivante:

Code :
  1. test_bind_post_field([
  2.     'news' => 'case_a_cocher',
  3.     'prefixe_tel_defaut' => 'entier',
  4.     'etc' => 'etc'
  5. ]);


Et surtout, tu pourrais permettre de piper les tests:

Code :
  1. test_bind_post_field([
  2.     'motDePasse' => 'chaine|min:8|max:255',
  3.     'etc' => 'etc'
  4. ]);


 
Au final, tu vas réinventer la roue. Ceci devrait te plaire: https://github.com/Wixel/GUMP


Sympa GUMP, un peu verbeux mais j'aime bien l'approche.
En effet l'idée de passer plusieurs champs d'un coup + des paramètres plus ou moins présents via une seule chaîne c'est pratique.
C'est ce que je n'aime pas trop sinon quand on commence à faire des fonctions un peu fourre-tout qui peuvent prendre ou non tout un tas de paramètres, à la fin on risque une confusion maxi. Genre :
$valide = teste("prénom","chaine",0,1,255) ;
alors 0 c'est pour "required" ou "longueur mini" ? et on passe quoi à ces paramètres quand on veut tester un entier ?
 
Bon par contre parser ce genre de chaine ça sent bien la galère... quand je vois le code de GUMP... autant en effet réutiliser cette lib :)
 
Ce qui me surprend c'est que j'ai l'impression de défricher un domaine ou poser des questions compliquées alors que c'est la base même de toute appli ou même site web depuis des décennies...

Message cité 1 fois
Message édité par depart le 26-04-2019 à 15:56:20
n°2332492
ydalb
In Crêpes n' Cidre I Trust!
Posté le 26-04-2019 à 15:52:20  profilanswer
 

B4X a écrit :


Au final, tu vas réinventer la roue. Ceci devrait te plaire: https://github.com/Wixel/GUMP


 
Cela dit, je trouve que c'est utile de réinventer la roue quand tu débutes, pour mieux comprendre les choses.
Combien de personnes utilisent des framework sans même comprendre comment tout est imbriqué, les middleware, etc ?


---------------
:o
n°2332507
B4X
kebab-case
Posté le 26-04-2019 à 17:21:48  profilanswer
 

depart a écrit :


C'est ce que je n'aime pas trop sinon quand on commence à faire des fonctions un peu fourre-tout qui peuvent prendre ou non tout un tas de paramètres, à la fin on risque une confusion maxi. Genre :
$valide = teste("prénom","chaine",0,1,255) ;
alors 0 c'est pour "required" ou "longueur mini" ? et on passe quoi à ces paramètres quand on veut tester un entier ?


 
Tu passe 2 parametres au lieu d'en passer 500 :
 

Code :
  1. $valide = teste("prenom","required|string|min:1|max:255" );


 
Ca a le mérite d'être très facile à modifier et lisible. Tu lis la ligne, tu as tout de suite compris à quoi elle servait.
Il faut ensuite dans ta fonction teste() decouper le 2nd parametre (explode() le pipe | ) et tout faire passer dans une boucle avec des sous-méthodes qui vont chacune verifier une condition (required, string, minimum length, max length, etc).


---------------
In vanitas veritas.
n°2332508
depart
Posté le 26-04-2019 à 17:36:09  profilanswer
 

B4X a écrit :


 
Tu passe 2 parametres au lieu d'en passer 500 :
 

Code :
  1. $valide = teste("prenom","required|string|min:1|max:255" );


 
Ca a le mérite d'être très facile à modifier et lisible. Tu lis la ligne, tu as tout de suite compris à quoi elle servait.
Il faut ensuite dans ta fonction teste() decouper le 2nd parametre (explode() le pipe | ) et tout faire passer dans une boucle avec des sous-méthodes qui vont chacune verifier une condition (required, string, minimum length, max length, etc).


 
ouais c'est ce queje disais (ou voulais dire maladroitement) : c'est ça que j'aime bien car sinon pour faire évoluer la fonction et la conserver lisible c'est la misère.
Genre là je me rends compte que mes "chaine_ou_vide" j'aurai mieux fait d'avoir un paramètre (facultatif) de longueur mini (et si c'est 0 c'est que le vide est accepté), mais pour modifier la fonction je suis un peu mal barré :(
J'apprends tous les jours...

mood
Publicité
Posté le 26-04-2019 à 17:36:09  profilanswer
 

n°2333656
kontas
Photographe amateur daltonien
Posté le 16-05-2019 à 18:30:33  profilanswer
 

Ça ressemble beaucoup au système de validation du framework laravel, c'est super lisible et bien fonctionnel

n°2333657
skeye
Posté le 16-05-2019 à 19:08:49  profilanswer
 

B4X a écrit :


 
Tu passe 2 parametres au lieu d'en passer 500 :
 

Code :
  1. $valide = teste("prenom","required|string|min:1|max:255" );


 
Ca a le mérite d'être très facile à modifier et lisible. Tu lis la ligne, tu as tout de suite compris à quoi elle servait.
Il faut ensuite dans ta fonction teste() decouper le 2nd parametre (explode() le pipe | ) et tout faire passer dans une boucle avec des sous-méthodes qui vont chacune verifier une condition (required, string, minimum length, max length, etc).


 
[:vomi]
 
...mais plus personne ne lit ce topic en fait?[:autobot]
 
Si tu veux passer tes critères de validation dans un seul paramètre tu fais un tableau, pas une immonde chaine de caractères à explode ensuite pour en faire quelquechose...
 

Code :
  1. $options = [
  2. 'required'=>true,
  3. 'type'=>'string',
  4. 'minLength'=>1,
  5. 'maxLength'=>255
  6. ];
  7. $valide=teste("prenom", $options);


---------------
Can't buy what I want because it's free -
n°2333680
B4X
kebab-case
Posté le 17-05-2019 à 19:49:22  profilanswer
 

skeye a écrit :


 
[:vomi]
 
...mais plus personne ne lit ce topic en fait?[:autobot]
 
Si tu veux passer tes critères de validation dans un seul paramètre tu fais un tableau, pas une immonde chaine de caractères à explode ensuite pour en faire quelquechose...
 

Code :
  1. $options = [
  2. 'required'=>true,
  3. 'type'=>'string',
  4. 'minLength'=>1,
  5. 'maxLength'=>255
  6. ];
  7. $valide=teste("prenom", $options);



 
[:vomi]
 
Quelle horreur :love:  
 
Fait ça à la limite si tu tiens tellement à ton garbage code :

Code :
  1. $options = [
  2.    'required',
  3.    'string',
  4.    'minLength:1',
  5.    'maxLength:255'
  6. ];
  7. $valide=teste("prenom", $options);


 
Pour éventuellement te rendre compte que cela nécessiterait un traitement subséquent pour le délimiteur ":" dans "minLength:1" par exemple.
Pour finalement admettre que tu vas nécessairement devoir te farcir ces tableaux associatifs dégueulasses :love:  
La gueule de ton code quand il faudra tester les 20 inputs d'un formulaire? :love: Tout ça à quel prix? parce que tu ne veux pas utiliser explode()  [:albounet]  
 
Au final j'ai une solution complètement élégante (cf lignes 436-448 : https://github.com/Wixel/GUMP/blob/ [...] .class.php ), lisible, compacte. Et toi?


---------------
In vanitas veritas.
n°2333681
MaybeEijOr​Not
but someone at least
Posté le 17-05-2019 à 20:14:08  profilanswer
 

Code :
  1. $valide=teste($data, $datatype, $required, $pattern = null);
 

Tu définies des patterns de base pour les données redondantes, sinon tu passes directement ton pattern à la fonction pour les données uniques.
Dans la fonction tu fais un preg_match sur ton pattern pour les datatype string, pour les nombres tu split un pattern avec min et max et ça devrait rouler.


Message édité par MaybeEijOrNot le 17-05-2019 à 20:14:45

---------------
C'est en écrivant n'importe quoi qu'on devient n'importe qui.
n°2333684
skeye
Posté le 18-05-2019 à 08:38:50  profilanswer
 

B4X a écrit :

 

[:vomi]

 

Quelle horreur :love:

 

Fait ça à la limite si tu tiens tellement à ton garbage code :

Code :
  1. $options = [
  2.    'required',
  3.    'string',
  4.    'minLength:1',
  5.    'maxLength:255'
  6. ];
  7. $valide=teste("prenom", $options);
 

Pour éventuellement te rendre compte que cela nécessiterait un traitement subséquent pour le délimiteur ":" dans "minLength:1" par exemple.
Pour finalement admettre que tu vas nécessairement devoir te farcir ces tableaux associatifs dégueulasses :love:
La gueule de ton code quand il faudra tester les 20 inputs d'un formulaire? :love: Tout ça à quel prix? parce que tu ne veux pas utiliser explode()  [:albounet]

 

Au final j'ai une solution complètement élégante (cf lignes 436-448 : https://github.com/Wixel/GUMP/blob/ [...] .class.php ), lisible, compacte. Et toi?

 

Complètement à coté de la plaque...ma réponse concerne la pratique de passer des données structurées dans une chaine de caractères, pas spécifiquement la solution adaptée à la question d'origine.
Les données dont tu as besoin SONT un tableau associatif. Ton langage propose cette structure de données nativement.
La compacité d'écriture du code n'excuse en aucun cas l'utilisation d'une structure de données inadaptée...j'ose même pas imaginer ta réaction si j'avais proposé une  solution avec un objet dédié plutôt qu'un simple tableau...
Je ne vais pas batailler plus loin, je perdrais manifestement mon temps...mais ce n'est même pas du PHP, là, c'est de la simple conception logicielle de base niveau 1ère année...

Message cité 1 fois
Message édité par skeye le 18-05-2019 à 10:02:15

---------------
Can't buy what I want because it's free -
n°2333685
depart
Posté le 18-05-2019 à 09:50:39  profilanswer
 

skeye a écrit :

 

Complètement à coté de la plaque...ma réponse concerne la pratique de passer des données structurées dans une chaine de caractères, pas spécifiquement la solution adaptée à la question d'origine.
Les données dont tu as besoin SONT un tableau associatif. Ton langage propose cette structure de données nativement.
La compacité d'écriture du code n'excuse en aucun cas l'utilisation d'une structure de données adaptée...j'ose même pas imaginer ta réaction si j'avais proposé une solution avec un objet dédié plutôt qu'un simple tableau...
Je ne vais pas batailler plus loin, je perdrais manifestement mon temps...mais ce n'est même pas du PHP, là, c'est de la simple conception logicielle de base niveau 1ère année...


Alors pour ma part je dis juste merci :jap: C'est d'une telle évidence que j'avais zappé.
C'est souvent le problème quand on développe, on est tellement la tête dans le guidon qu'on passe à côté des choses les plus basiques.
J'ai souvenir par exemple d'avoir moitié réinventé une méthode de chiffrement pour stocker des données de manière sécurisée en bdd... avant de retrouver que mysql proposait des méthodes aes_encrypt et decrypt !

 

Pour revenir à ma fonction, entre temps j'ai juste amélioré en définissant type + longueur mini + longueur maxi et avec ces 3 paramètres je m'en sors (pour l'instant) a tous les coups. Mais avec un tableau d'options ça aurait été plus évolutif.

n°2333690
MaybeEijOr​Not
but someone at least
Posté le 18-05-2019 à 14:02:38  profilanswer
 

Au passage : https://www.php.net/manual/fr/function.extract.php


---------------
C'est en écrivant n'importe quoi qu'on devient n'importe qui.
n°2333691
Bixibu
Ca ... c'est fait!
Posté le 18-05-2019 à 14:14:27  profilanswer
 

B4X a écrit :


 
Tu passe 2 parametres au lieu d'en passer 500 :
 

Code :
  1. $valide = teste("prenom","required|string|min:1|max:255" );


 
Ca a le mérite d'être très facile à modifier et lisible. Tu lis la ligne, tu as tout de suite compris à quoi elle servait.
Il faut ensuite dans ta fonction teste() decouper le 2nd parametre (explode() le pipe | ) et tout faire passer dans une boucle avec des sous-méthodes qui vont chacune verifier une condition (required, string, minimum length, max length, etc).


 
Pourquoi passer 2 paramètres, quand on peut en passer qu'un ?  

Code :
  1. $valide = teste("prenom=required|string|min:1|max:255" );


 
Pourquoi pas réécrire tout php comme ca d'ailleurs tellement c'est une idée qu'elle est bonne :

Code :
  1. if (in_array("toto", array("toto", "tata", "titi" ))) {
  2.     echo "OK";
  3. }


deviendrait :  

Code :
  1. if (test_in_array("toto=toto|tata|titi" )) {
  2.     echo "OK";
  3. }


 
Bref c'est pas parce que ta lib github préférée du moment pense avoir eu une bonne idée qu'elle l'est :o

n°2336634
depart
Posté le 10-07-2019 à 10:46:26  profilanswer
 

Nouvelle question...
 
J'ai une application web, qu'on va dire dédiée pour des électriciens. Il y a une partie promotionnelle (site web) et une partie d'accès restreint.
 
Aujourd'hui je veux décliner cette application pour (on va dire aussi) les plombiers. On peut imaginer que 90% du code va être le même, les différences vont être dans le css, le blabla marketing pour le site et la suppression de pas mal de champs et morceaux de l'appli non pertinents pour les plombiers et ajout pour eux de champs dédiés à leur profession.
 
Vous feriez comment ?
 
Actuellement j'ai tout dans 1 dépot git, ça prendrait 15 secondes à cloner et de partir du code de l'appli 1 à un instant donné pour développer l'appli2... mais du coup ça dédouble une grosse partie de code qui pourrait être commune... ça me semble être une très mauvaise idée pour la maintenance à long terme (correction de bug en double, développement de features en double...)
 
Du coup le plus logique reste de mutualiser le code autant que possible et de partir dans des fichiers de config différents, des switchs dans le code, éventuellement des objets (mais j'en ai très peu) "électricien extends professionnel" et plombier extends professionnel", des includes de fichiers dont le nom est basé sur une variable qui contient électricien ou plombier...
 
Vous avez des conseils pour ce genre de chose ? Genre actuellement mon fichier de config est inclus dans le git, donc quand je fais un pull pour mettre à jour mon serveur de prod, ça inclue le fichier de config aussi (et dedans il y a un test pour "détecter" si on est en dev ou en prod (chemin des fichiers, ip...). Ca va un peu se compliquer si le fichier de config intègre électricien et plombier.
 
Même chose en terme de bdd... je peux faire une bdd électricien et une bdd plombier, mais dedans 90% des tables et colonnes seraient communes... c'est probablement plus pertinent de conserver une seule bdd...  
 
Bref je suis preneur de tout conseil et retour d'expérience sur le sujet...


Message édité par depart le 10-07-2019 à 10:56:47
n°2336635
skeye
Posté le 10-07-2019 à 10:58:52  profilanswer
 

Difficile de répondre précisément sur une question si vaste, mais oui, typiquement ça ressemble à une appli unique dont tu actives/désactives simplement des fonctionnalités en fonction des besoins du client au déploiement.

 

Pour moi dans ce style de cas c'est une seule appli, un seul dépot git, et pas de fichier de conf "réel" dans le dépot, seulement un squelette. Ca implique de revoir pas mal ton process de déploiement par contre, j'imagine.

 

Ensuite concrètement coté modélisation il faut voir comment tu définis les fonctionnalités à activer/désactiver en fonction des clients (classification de tes clients par types et association d'un set de fonctionnalités à chaque type? Gestion individuelle par client, fonctionnalité par fonctionnalité? Il n'y a que toi qui peux vraiment répondre sur ce qui est adapté à ta situation...), et où tu stockes ça (fichier(s) de conf, paramétrage coté base de données? Typiquement chez nous c'est une/des table(s) de paramétrage dans la base pour les gros trucs, directement dans un fichier de conf pour les petits devs rapides).

Message cité 1 fois
Message édité par skeye le 10-07-2019 à 11:00:44

---------------
Can't buy what I want because it's free -
n°2336647
depart
Posté le 10-07-2019 à 12:07:12  profilanswer
 

skeye a écrit :

Difficile de répondre précisément sur une question si vaste, mais oui, typiquement ça ressemble à une appli unique dont tu actives/désactives simplement des fonctionnalités en fonction des besoins du client au déploiement.
 
Pour moi dans ce style de cas c'est une seule appli, un seul dépot git, et pas de fichier de conf "réel" dans le dépot, seulement un squelette. Ca implique de revoir pas mal ton process de déploiement par contre, j'imagine.
 
Ensuite concrètement coté modélisation il faut voir comment tu définis les fonctionnalités à activer/désactiver en fonction des clients (classification de tes clients par types et association d'un set de fonctionnalités à chaque type? Gestion individuelle par client, fonctionnalité par fonctionnalité? Il n'y a que toi qui peux vraiment répondre sur ce qui est adapté à ta situation...), et où tu stockes ça (fichier(s) de conf, paramétrage coté base de données? Typiquement chez nous c'est une/des table(s) de paramétrage dans la base pour les gros trucs, directement dans un fichier de conf pour les petits devs rapides).


 
Éventuellement pour la config, je peux faire un truc basique du genre un test de "dans quel dossier se trouve le fichier de conf" :  

if( preg_match("/home/plombier/i", $_SERVER['DOCUMENT_ROOT']) ) {
$app = "plombier" ;  
} else {
$app = "electricien" ;  
}


ou un switch sur une partie du document_root pour anticiper le jour où j'intègrerai les maçons ou autre :)
 
Et ensuite baser mes tests sur le contenu de $app...
 
Ca suppose de faire un pull par "site", donc en gros j'aurai le même code dans /home/electricien et /home/plombier ... peut-être un peu idiot ? Sinon tout dans le même mais avec un test sur l'hôte (www.electricien.com vs www.plombier.com)
 
 
Après oui ça va être des fonctions à activer ou non. Dans un premier temps c'est surtout en désactiver un paquet qui ne sont pas pertinentes pour la seconde profession par rapport à ce qu'il y a déjà. Il y aura aussi probablement pas mal de textes à adapter.
Le truc dont j'ai un peu peur c'est de créer un monstre d'imbrications de if(profession1) then... else... mais des fois c'est commun, mais des fois pas... et aussi d'avoir des requêtes sql un peu étranges.
Typiquement un formulaire de saisie qui peut avoir 10 champs pour la profession 1, 4 pour la profession 2, mais seulement 3 de commun... donc les vérifications d'existence de valeur puis d'insertion/maj en bdd ça risque un peut d'être le bazar.

Message cité 1 fois
Message édité par depart le 10-07-2019 à 12:11:28
n°2336652
skeye
Posté le 10-07-2019 à 13:51:25  profilanswer
 

depart a écrit :


 
Éventuellement pour la config, je peux faire un truc basique du genre un test de "dans quel dossier se trouve le fichier de conf" :  

if( preg_match("/home/plombier/i", $_SERVER['DOCUMENT_ROOT']) ) {
$app = "plombier" ;  
} else {
$app = "electricien" ;  
}


ou un switch sur une partie du document_root pour anticiper le jour où j'intègrerai les maçons ou autre :)
 
Et ensuite baser mes tests sur le contenu de $app...
 
Ca suppose de faire un pull par "site", donc en gros j'aurai le même code dans /home/electricien et /home/plombier ... peut-être un peu idiot ? Sinon tout dans le même mais avec un test sur l'hôte (www.electricien.com vs www.plombier.com)


 
Tu déploies tout sur le même serveur derrière?
Jadis j'avais un truc du genre - une install unique avec la conf commune, et le nom de domaine servait à déterminer dans quels dossiers aller chercher la conf et les templates spécifiques. Ca évitait de dupliquer le code et de multiplier les opérations à chaque MAJ, l'inconvénient c'est que si tu as besoin un jour de désynchroniser les instances c'est le merdier.:o
 

depart a écrit :


Après oui ça va être des fonctions à activer ou non. Dans un premier temps c'est surtout en désactiver un paquet qui ne sont pas pertinentes pour la seconde profession par rapport à ce qu'il y a déjà. Il y aura aussi probablement pas mal de textes à adapter.
Le truc dont j'ai un peu peur c'est de créer un monstre d'imbrications de if(profession1) then... else... mais des fois c'est commun, mais des fois pas... et aussi d'avoir des requêtes sql un peu étranges.
Typiquement un formulaire de saisie qui peut avoir 10 champs pour la profession 1, 4 pour la profession 2, mais seulement 3 de commun... donc les vérifications d'existence de valeur puis d'insertion/maj en bdd ça risque un peut d'être le bazar.


 
Si tu découpes proprement le code tu peux limiter pas mal tes besoins de if(professiontruc)...Un exemple simpliste : avoir simplement des templates par profession pour chaque page. Tu pourrais ainsi par exemple avoir pour tes formulaires une version complète comprenant tous les champs pour celle qui a besoin de tout, et des champs hidden avec des valeurs par défaut sur le template pour la deuxième profession qui veut pas tout voir. Ca te permet de conserver toute la logique commune derrière et de personnaliser à peu de frais...


---------------
Can't buy what I want because it's free -
n°2339314
SOF40
Mon Vachoux Sur
Posté le 20-09-2019 à 14:23:20  profilanswer
 

Bonjour, une idée du pourquoi j'ai ²² qui apparait sur mage page? pas sur que ça soit un soucis de php mais bon  
 
https://reho.st/self/551d2db0b17b9927c2c3079f289077bca3b34d8f.png


---------------
[Topik Unik] - Clash Royale        
n°2339315
MaybeEijOr​Not
but someone at least
Posté le 20-09-2019 à 15:09:36  profilanswer
 

C'est ce qu'on appelle un site fait en deux deux.


---------------
C'est en écrivant n'importe quoi qu'on devient n'importe qui.
n°2339316
SOF40
Mon Vachoux Sur
Posté le 20-09-2019 à 15:10:47  profilanswer
 

[:caudacien]


---------------
[Topik Unik] - Clash Royale        
n°2339317
MaybeEijOr​Not
but someone at least
Posté le 20-09-2019 à 15:12:25  profilanswer
 

Ou alors du langage ternaire !


---------------
C'est en écrivant n'importe quoi qu'on devient n'importe qui.
n°2339321
mechkurt
Posté le 20-09-2019 à 15:56:49  profilanswer
 

SOF40 a écrit :

Bonjour, une idée du pourquoi j'ai ²² qui apparait sur mage page? pas sur que ça soit un soucis de php mais bon  
 
https://reho.st/self/551d2db0b17b99 [...] b34d8f.png


tage page on peut la voir quelque part (en message privé si tu veux pas la voir sur un forum public) pacque la sans  [:michaeldell] ça va être difficile de t'aider...
 
...ca peut être dans ton code, un problème d'encodage ou même du css ou du js.
 
Quand tu fait un clic droit dessus => inspecter l’élément; est que ça te donne une indice ?


Message édité par mechkurt le 20-09-2019 à 15:57:16

---------------
D3
n°2339323
SOF40
Mon Vachoux Sur
Posté le 20-09-2019 à 16:17:38  profilanswer
 

C'est pas directement ma page, en faite c'est un serveur tuleap
 
donc c'est la même que celle la https://tuleap.net/
 
mais avec mon bug  
https://reho.st/self/eac914a7a6e6a76d90904eace19d0f91bef7cc81.png
 
 
Après j'ai encore 2/3 autres bug php, donc c'est peut etre lié :/


---------------
[Topik Unik] - Clash Royale        
n°2339328
mechkurt
Posté le 20-09-2019 à 16:58:52  profilanswer
 

Est ce que tu vois ces caractères dans le code source dans les environs de la fermeture de la balise </header> et l'ouverture du <div id="main-container"> ?
Tu as regardé sur les logs d'erreur de ton serveur, tu as vérifié quelle conditions minimal était requise pour l'installation ?
Tu suis ce tutoriel : https://docs.tuleap.org/install.html ?


---------------
D3
n°2339329
SOF40
Mon Vachoux Sur
Posté le 20-09-2019 à 17:03:20  profilanswer
 

mechkurt a écrit :

Est ce que tu vois ces caractères dans le code source dans les environs de la fermeture de la balise </header> et l'ouverture du <div id="main-container"> ?
Tu as regardé sur les logs d'erreur de ton serveur, tu as vérifié quelle conditions minimal était requise pour l'installation ?
Tu suis ce tutoriel : https://docs.tuleap.org/install.html ?


 
J'ai suivi le tuto de maj, vu qu'il était déjà installé
 
Mais je pense que c'est la maj php 5.x vers 7.3 qui fout la merde


---------------
[Topik Unik] - Clash Royale        
mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3  4  5  ..  63  64  65  66  67  68
Page Suivante

Aller à :
Ajouter une réponse
 

Sujets relatifs
Problème pour une mise en page sous forme de tableauAfficher sur une page web directement le resultat d'une autre page web
[PHP] Fonction include plus rapide qu'un bout de code dans la page ?Ouvrir un fichier HTML en fin de page
[Résolu] Expirer la cache au niveau de la pageexecuter une page php sans rien afficher
inserer dans ma page wikiControler le changement de page
Certificat SSL a valider pour chaque élément de pageinstallé un mdp sur une page web avec Namo
Plus de sujets relatifs à : blabla@php | faq et bonnes pratiques page 1


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite) / Groupe LDLC / Shop HFR