Je pense mettre en dur, les jours fixes, par calcul pour les autres.
Le cas du samedi, en paramétre, ainsi qu'un systéme de zonne en paramétre, alsase ...
Je ne vois pas ce qui n'a pas été courtois là ? Ton code, en l'état, ne présente pas d'intérêt. Il est inutilisable et faux. Donc, j'attends une amélioration rapide, sous peine de quoi je vais le supprimer : je ne vais pas laisser un code incomplet et faux, ça ne servirait à rien ni à personne, tu n'es pas d'accord ? En l'occurence, je ne le supprime pas de suite, je te fais juste la remarque : si tu ne l'améliores pas, je vais le supprimer.
Le supprimer sans coup férir et sans commenter mes raisons, ça, ça aurait été un manque de courtoisie.
Mais ce n'est pas ce que j'ai fait.
Grand Mercie, pour cet accueil, les remarques technique sont interessantes, mais la derniére est vexante !
Si tu veux viré vire, je ne suis pas au piéces pour amélioré ce code, d'autant plus qu'il fait parti d'un projet plus grand.
rester calme et courtois tout au long de vos échanges ?
Donc on est d'accord que le script php peut-être amélioré sans problème.
Merci de tes remarques constructives.
Je suis développeur Java(J2EE) à la base et j'ai découvert le php il y a plusieurs années. J'apprend au fur et à mesure... :-)
Autre remarque, le développeur n'a pas réagit à notre argumentation...
Dans mon cas, inutile de le gérer, lol. Ce qui m'importe ce sont les transporteurs et eux bossent, dans ma région.
Mais si j'avais à le faire, ça dépend...je t'ai dit, les différents calendriers que je gère sont passés en paramètre sous forme de configurations. J'applique telle config pour tel type de calendrier. Et basta, je ressors les jours ouvrés (ou plus exactement, un nombre de jours ouvrés à partir d'une date donnée, et selon un delta X).
Et ces configs sont créées en amont. Et plus jamais retouchées puisque des jours non ouvrés sont parfaitement calculables pour un type de calendrier donné (avec ses spécificités donc) à la volée.
Sur ta dernière remarque : oui, évidemment. Mais le site n'est pas fait QUE pour les gros bonnets.
De même pour moi, l'application développée utilise des bases de plusieurs Giga.
Les logs sont dans des fichiers texte. Dans ton cas, comment géré le cas de l'alsace(Lorraine ?) qui a le 26 décembre de férié et pas les autres ?.
Mis à part un paramètre à positionner en dur (donc une retouche manuel) je ne vois pas comment faire.
Mais je partage bien évidemment ton avis sur le fait de devoir décharger un maximum le serveur de données des "petites" requêtes.
Mais je pense que les "gros" bonnets du développement ne viennent pas prendre un bout de code ici ... sans qu'il y est eu des notes et des commentaires le critiquant positivement
Parce que je n'en vois pas l'intérêt.
Déjà, ça peut se coder très simplement. Et il est toujours préférable d'avoir un code automatisé quand on le peut, plutôt que de laisser la main humaine s'en méler : c'est sujet à erreurs. Et une erreur de saisie dans un calendrier, quand on bosse par exemple dans la logistique, cela risque de s'avérer dramatique. Quitte à modifier un jour un code parce qu'un jour férié a été ajouté où ôté. Mais en dehors de ça, tu peux créer un code gérant des calendriers calculés sans trop de problème, et valables chaque année sans retouche.
D'autre part, le client est toujours plus heureux quand il n'a rien à faire... ;-) On lui demande une fois un calendrier, et on le code. Point.
Ensuite, concernant une table...je bosse sur de grosses bases de données, et de grosses applications web. De vrais applications je veux dire, pas simplement des "sites web". Et je sais que quand on peut éviter de charger une base, autant le faire.
Mes logs, par exemple, sont loggés dans des fichiers XML, pas en base.
Idem pour mes stats, elles sont consolidées dans des fichiers.
Mes fichiers de configuration sont généralement aussi dans des fichiers XML.
Bref, tout ce que je peux sortir à moindre coût, je le sors.
J'aimerai bien, de mon côté, que tu m'expliques pourquoi tu n'aimes pas une table pour si peu.
Car là où je développes, on a eu exactement la même problèmatique pour définir la première date ouvré à J+1 de mandatement, et l'on a choisi de laisser le client saisir, tous les ans, les dates de jours fériés. Car entre la métropole et les DOM TOM il existent pas mal de différence (et comme je l'ai dit, il existe aussi des particularités régionales).
Comme plus de 75% de codes sur le net en général. On ne peut pas non plus tout virer. ET beaucoup de codes n'ont pas d'intérêts en eux-mêmes, mais en ont de par les commentaires qu'ils ont suscités. Et de bons commentaires, ça aident les auteurs, et ceux qui les lisent.
Et on ne peut pas tout supprimer non plus.
Le passage d'un calendrier comme paramètre est une bonne idée. Mais je suis contre une saisie régulière (même une fois tous les 10 ans) des dates. D'abord, c'est trop léger pour en faire une table; ensuite, il y aura toujours du code à ajouter (Pâques et autres jours pénibles ;-) ).
Au passage, il manque aussi la prise en compte du changement d'heure dans ton code...il va se révéler faux très rapidement.
Bon...infomagique, je vais te demander d'améliorer fissa ce code, ou je le supprime, car en l'état il ne présente aucun intérêt majeur.
Sauf que le jour de Pâques ne peut pas être stocké, vu qu'il est variable. Ainsi que quelques autres jours fériés d'ailleurs.
Pour Pâques, il faut faire appel à un algorithme assez compliqué...pour le calculer.
comme le dit MALALAM il faudrait que tu puisses mettre le samedi sous formes de paramètre pour être prise en compte ou non.
De plus pour les jours fériés c'est une mauvaise idée de les mettre en dur dans ton fichier php.
Utilise plutôt une table SQL (Exemple de structure de table : id,timestamp,objet) qui contiendrait les jours fériés. Comme ça on peut l'interfacer avec un calendrier et de plus ton code sera facilement exportable pour l'alsace par exemple (qui a le 26 décembre de férié qui les autres département non pas).
je ne vois pas en quoi ton code est fiable.
Il manque un tas de jours fériés, et effectivement tu ne prends pas en compte les week-ends (samedi n'est pas forcément un jour ouvré).
Le cas du samedi, en paramétre, ainsi qu'un systéme de zonne en paramétre, alsase ...
- Messages postés
-
10840
- Date d'inscription
- lundi 24 février 2003
- Statut
- Modérateur
- Dernière intervention
- 2 mars 2010
23Le supprimer sans coup férir et sans commenter mes raisons, ça, ça aurait été un manque de courtoisie.
Mais ce n'est pas ce que j'ai fait.
Si tu veux viré vire, je ne suis pas au piéces pour amélioré ce code, d'autant plus qu'il fait parti d'un projet plus grand.
rester calme et courtois tout au long de vos échanges ?
- Messages postés
-
10840
- Date d'inscription
- lundi 24 février 2003
- Statut
- Modérateur
- Dernière intervention
- 2 mars 2010
23Merci de tes remarques constructives.
Je suis développeur Java(J2EE) à la base et j'ai découvert le php il y a plusieurs années. J'apprend au fur et à mesure... :-)
Autre remarque, le développeur n'a pas réagit à notre argumentation...
- Messages postés
-
10840
- Date d'inscription
- lundi 24 février 2003
- Statut
- Modérateur
- Dernière intervention
- 2 mars 2010
23Mais si j'avais à le faire, ça dépend...je t'ai dit, les différents calendriers que je gère sont passés en paramètre sous forme de configurations. J'applique telle config pour tel type de calendrier. Et basta, je ressors les jours ouvrés (ou plus exactement, un nombre de jours ouvrés à partir d'une date donnée, et selon un delta X).
Et ces configs sont créées en amont. Et plus jamais retouchées puisque des jours non ouvrés sont parfaitement calculables pour un type de calendrier donné (avec ses spécificités donc) à la volée.
Sur ta dernière remarque : oui, évidemment. Mais le site n'est pas fait QUE pour les gros bonnets.
Les logs sont dans des fichiers texte. Dans ton cas, comment géré le cas de l'alsace(Lorraine ?) qui a le 26 décembre de férié et pas les autres ?.
Mis à part un paramètre à positionner en dur (donc une retouche manuel) je ne vois pas comment faire.
Mais je partage bien évidemment ton avis sur le fait de devoir décharger un maximum le serveur de données des "petites" requêtes.
Mais je pense que les "gros" bonnets du développement ne viennent pas prendre un bout de code ici ... sans qu'il y est eu des notes et des commentaires le critiquant positivement
- Messages postés
-
10840
- Date d'inscription
- lundi 24 février 2003
- Statut
- Modérateur
- Dernière intervention
- 2 mars 2010
23Déjà, ça peut se coder très simplement. Et il est toujours préférable d'avoir un code automatisé quand on le peut, plutôt que de laisser la main humaine s'en méler : c'est sujet à erreurs. Et une erreur de saisie dans un calendrier, quand on bosse par exemple dans la logistique, cela risque de s'avérer dramatique. Quitte à modifier un jour un code parce qu'un jour férié a été ajouté où ôté. Mais en dehors de ça, tu peux créer un code gérant des calendriers calculés sans trop de problème, et valables chaque année sans retouche.
D'autre part, le client est toujours plus heureux quand il n'a rien à faire... ;-) On lui demande une fois un calendrier, et on le code. Point.
Ensuite, concernant une table...je bosse sur de grosses bases de données, et de grosses applications web. De vrais applications je veux dire, pas simplement des "sites web". Et je sais que quand on peut éviter de charger une base, autant le faire.
Mes logs, par exemple, sont loggés dans des fichiers XML, pas en base.
Idem pour mes stats, elles sont consolidées dans des fichiers.
Mes fichiers de configuration sont généralement aussi dans des fichiers XML.
Bref, tout ce que je peux sortir à moindre coût, je le sors.
J'aimerai bien, de mon côté, que tu m'expliques pourquoi tu n'aimes pas une table pour si peu.
Car là où je développes, on a eu exactement la même problèmatique pour définir la première date ouvré à J+1 de mandatement, et l'on a choisi de laisser le client saisir, tous les ans, les dates de jours fériés. Car entre la métropole et les DOM TOM il existent pas mal de différence (et comme je l'ai dit, il existe aussi des particularités régionales).
- Messages postés
-
10840
- Date d'inscription
- lundi 24 février 2003
- Statut
- Modérateur
- Dernière intervention
- 2 mars 2010
23Et on ne peut pas tout supprimer non plus.
- Messages postés
-
10840
- Date d'inscription
- lundi 24 février 2003
- Statut
- Modérateur
- Dernière intervention
- 2 mars 2010
23Au passage, il manque aussi la prise en compte du changement d'heure dans ton code...il va se révéler faux très rapidement.
Bon...infomagique, je vais te demander d'améliorer fissa ce code, ou je le supprime, car en l'état il ne présente aucun intérêt majeur.
Une saisie de 10 occurence à l'année maximum ca devrait être jouable ;-)
Pour ce qui est des week-end, c'est facilement codable par contre
- Messages postés
-
10840
- Date d'inscription
- lundi 24 février 2003
- Statut
- Modérateur
- Dernière intervention
- 2 mars 2010
23Pour Pâques, il faut faire appel à un algorithme assez compliqué...pour le calculer.
comme le dit MALALAM il faudrait que tu puisses mettre le samedi sous formes de paramètre pour être prise en compte ou non.
De plus pour les jours fériés c'est une mauvaise idée de les mettre en dur dans ton fichier php.
Utilise plutôt une table SQL (Exemple de structure de table : id,timestamp,objet) qui contiendrait les jours fériés. Comme ça on peut l'interfacer avec un calendrier et de plus ton code sera facilement exportable pour l'alsace par exemple (qui a le 26 décembre de férié qui les autres département non pas).
Implémente ceci et ce sera parfait.
Cyril
- Messages postés
-
10840
- Date d'inscription
- lundi 24 février 2003
- Statut
- Modérateur
- Dernière intervention
- 2 mars 2010
23je ne vois pas en quoi ton code est fiable.
Il manque un tas de jours fériés, et effectivement tu ne prends pas en compte les week-ends (samedi n'est pas forcément un jour ouvré).