Pour la table des jours fériés, j'ai fait la même chose (avec un petit
bouton sur le formulaire de màj pour insérer les jours standards
d'une année).
Je vais peut-être aussi utiliser plus de triggers, ça peut éviter de
couteuses jointures (pléonasme ... :-) car dans le genre exception
à la con, j'ai par exemple: si le personne a une certaine fonction
(ET à la date voulue, car ça bouge...) et si elle bosse entre 23h00
et 07h00 alors son compte d'heure sera un forfait de 3h00 et non
pas 08h00 ! (c'est un forfait pour des éducateurs de nuit).
Et je ne veux *pas* avoir de code spécifique au calcul dans l'appli,
tout doit venir de la bdd, pour éventuellement faire des extractions
directes via odbc sans se taper de champs "calculés" par le client
(qu'il soit logiciel ou humain :-).
Cette gestion de planning est ma première appli php. Autant j'aurais
pu torcher ça en 2 semaines avec un Delphi sous Windows, j'ai
estimé le tout à environ 2 mois de taf. Comme ça, une migration des
postes clients sous un *nix est envisageable !
Mon gros taf actuellement est d'écrire un browser générique de
table (liste/tri/filtre/ajout/supp/modif/impression). Ne connaissant
pas les limites du php (parce que les fonctionnalités c'est facile, il
suffit de lire les docs !), je perds beaucoup de temps à valider
toutes mes routines de bas-niveau (perfs entre autres...). Mine de
rien, ça fait déja + de 2000 lignes de code (oui, je sais, il y a des
libs php qui existent, mais je crois que je vais plus vite que de
trouver comment elles marchent, et puis ça forme !).
Pour faciliter les pointages, je pense bidouiller qq chose avec des
clefs usb: on fout une clef spécialement formatée et pouf, on a
pointé (avec un petit message vocal). Mais ça ne règle pas le
problème d'un pointage oublié (si on oublie de pointer le départ
de midi, le pointage d'arrivée à 14h00 sera pris comme le départ
oublié)... A moins de générer un départ automatique si la période
est "louche"...
[^] # Re: Je ne sais pas si c'est la bonne méthode, mais....
Posté par zx81 . En réponse au message champs "durée" et postgres. Évalué à 2.
Pour la table des jours fériés, j'ai fait la même chose (avec un petit
bouton sur le formulaire de màj pour insérer les jours standards
d'une année).
Je vais peut-être aussi utiliser plus de triggers, ça peut éviter de
couteuses jointures (pléonasme ... :-) car dans le genre exception
à la con, j'ai par exemple: si le personne a une certaine fonction
(ET à la date voulue, car ça bouge...) et si elle bosse entre 23h00
et 07h00 alors son compte d'heure sera un forfait de 3h00 et non
pas 08h00 ! (c'est un forfait pour des éducateurs de nuit).
Et je ne veux *pas* avoir de code spécifique au calcul dans l'appli,
tout doit venir de la bdd, pour éventuellement faire des extractions
directes via odbc sans se taper de champs "calculés" par le client
(qu'il soit logiciel ou humain :-).
Cette gestion de planning est ma première appli php. Autant j'aurais
pu torcher ça en 2 semaines avec un Delphi sous Windows, j'ai
estimé le tout à environ 2 mois de taf. Comme ça, une migration des
postes clients sous un *nix est envisageable !
Mon gros taf actuellement est d'écrire un browser générique de
table (liste/tri/filtre/ajout/supp/modif/impression). Ne connaissant
pas les limites du php (parce que les fonctionnalités c'est facile, il
suffit de lire les docs !), je perds beaucoup de temps à valider
toutes mes routines de bas-niveau (perfs entre autres...). Mine de
rien, ça fait déja + de 2000 lignes de code (oui, je sais, il y a des
libs php qui existent, mais je crois que je vais plus vite que de
trouver comment elles marchent, et puis ça forme !).
Pour faciliter les pointages, je pense bidouiller qq chose avec des
clefs usb: on fout une clef spécialement formatée et pouf, on a
pointé (avec un petit message vocal). Mais ça ne règle pas le
problème d'un pointage oublié (si on oublie de pointer le départ
de midi, le pointage d'arrivée à 14h00 sera pris comme le départ
oublié)... A moins de générer un départ automatique si la période
est "louche"...