Discussion :

[Yoyo@]

Salut,

Je précise que je travaille en environnement web (mod_perl), donc, le but pour moi n'est pas d'utiliser un module externe me permettant d'arriver à mes fins, mais qui consommerait beaucoup de mémoire, car diposant d'une multitue de fonctions inutiles pour moi.

Voilà mon problème:
Dans un formulaire HTML? j'ai un champ date. Je veux que l'utilisatur me retourne une date sous le format dd/mm/yyyy.
JE voudrais pouvoir vérifier la validité de cette date (déja le format, mais ça, je peux le faire facilement avec une regexp) mais aussi si possible la validité (ex: ne pas avoir un 30/02/2006 ou un 31/04/2006).

Le but est ensuite, si le format est valide, la stocker dans une table MySQL (donc, il me faudra sans doute faire une conversion par la suite pour l'insérer dans ma table)

Puis je faire ça manuellement, ou me conseillez vous quand même l'utilisation d'un module externe? Si c'est le cas, lequel me conseillez vous? (j'insiste sur le fait que je ne souhaite pas avoir à charger un module ayant une empreinte mémoire trop grosse)

Merci.

[2Eurocents]

Pas besoin d'expression rationnelle si tu fais appel au module Date::Simple.

En effet, celui ci gère aussi bien la validation (rejet des dates incorrectes) que le formattage (sortie au format "AAAA-MM-JJ" que l'on peut insérer sans soucis dans un champ DATE de MySQL).

Il est parfait pour les usages simples, sans conversion de TimeZone et autres temps GMT ou UTC.


Par contre, cela reste un module supplémentaire ... mais je ne suis pas sûr que son empreinte en mémoire soit SI importante ...

Sinon, toujours avec des modules, mais en prenant ceux du "core" Perl, il doit y avoir moyen de s'en sortir avec Date::Parse et Date::Format.


Sans module, il te faudra réinventer la roue

[Yoyo@]

Alors:

D'une part, il ne me semble pas que Date:arse et Date::Simple fasse partie du core de Perl (enfin, y a aucune trace de ces deux modules sur le site de Perl, et mon ppm ne m'indique pas que je les ai).

D'autre part, je pense que chacun de ces modules doit utiliser des regexp derrière les fagots.
Finalement, je me dis que ma problématique est suffisamment smple pour que je puisse le faire moi même: ça me coûtera moins cher en terme de mémoire (sur un serveur web, si tu as 50 interprêteurs, ça peut devenir très lourd...)

Je vais finalement m'en tirer en utilisant un truc du genre:

my ($day, $month, $year) = ($str =~ /^(\d\d)\/(\d\d)\/(\d\d\d\d)$/);

Par la suite, je vais tester que $day et $monthsont bien plus petits que 31/12 et plus grands que 0.

Enfin, il se trouve que MySQL accepte des dates du type 31/02/2006 (enfin, sous la forme "2006/02/31", que ça ne le dérange pas que le jour n'existe pas, donc, ça me va très bien comme ça (je n'utilise cette date qu'à titre de comparaison avec d'autres).

Cette expression régulière est vraiment simple, donc doit être rapide et utiliser peu de mémoire....

Tu en penses quoi?

Merci en tout cas.

[2Eurocents]

Tu as raison ... tous sont des modules CPAN ... J'ai tellement l'habitude de trouver Date::Parse et Date::Manip partout que je les ai cru dans le core.

D'autre part, je pense que chacun de ces modules doit utiliser des regexp derrière les fagots.
Finalement, je me dis que ma problématique est suffisamment smple pour que je puisse le faire moi même: ça me coûtera moins cher en terme de mémoire (sur un serveur web, si tu as 50 interprêteurs, ça peut devenir très lourd...)
...

Si je prends simplement la validation de date, je crois qu'il y a bien plus que de la simple vérification d'expression rationnelle (contrôle du 28/29 février, au hasard).

Je me dis aussi que, par expérience, la consistance de mes données est, a toujours été, et restera pour longtemps encore ma préoccupation principale. Ainsi, si par un usage de modules éprouvés je peux garantir que mes données sont entrées de manière correcte et consistante dans mon SGBD, alors je suis prêt à assumer le surcoût opérationnel qui peut en découler.

Je ne suis pas expert en mod_perl, mais 50 interpréteurs actifs en simultanés, ça peut être lourd, mais ça n'arrive que ponctuellement, non ? Et 1 Mo d'empreinte-mémoire supplémentaire par interpréteur, ça nous mène à 50 Mo, une valeur qui, pour être importante, n'en reste pas moins acceptable en régime transitoire, non ?

L'important, pour moi, n'est pas le traitement, mais l'information qu'il manipule et produit.

Maintenant, à toi de voir ce qui correspond le mieux à ton usage.

[Yoyo@]

Si je prends simplement la validation de date, je crois qu'il y a bien plus que de la simple vérification d'expression rationnelle (contrôle du 28/29 février, au hasard).

Oui, sachant que ma date est tout ce qu'il y a de plus fixe, du type "dd/mm/yyyy", je pourrais me contenter de tester la longueur de la chaîne, puis de faire 3 subrstrings. Je ne sais pas si ce serait plus rapide que les regexp?
Ici, je parle uniquement de contrôler le format d'entrée, et non pas de savoir si le 29/02 existe ou pas... (de toute façon, MySQL ne m'embêtera pas pour ça...)

Je me dis aussi que, par expérience, la consistance de mes données est, a toujours été, et restera pour longtemps encore ma préoccupation principale. Ainsi, si par un usage de modules éprouvés je peux garantir que mes données sont entrées de manière correcte et consistante dans mon SGBD, alors je suis prêt à assumer le surcoût opérationnel qui peut en découler.

Je suis 100% d'accord avec toi, mais ici, le test à effectuer est tellement simple que je n'ai aps trop à m'inquiéter, et il est facile d'avoir un contrôle fin de la chose...

Je ne suis pas expert en mod_perl, mais 50 interpréteurs actifs en simultanés, ça peut être lourd, mais ça n'arrive que ponctuellement, non ? Et 1 Mo d'empreinte-mémoire supplémentaire par interpréteur, ça nous mène à 50 Mo, une valeur qui, pour être importante, n'en reste pas moins acceptable en régime transitoire, non ?

Effectivement, vu sous cet angle là...
Mais ce qu'il faut savoir c'est qu'une fois qu'un interprêteur Perl est mis en mémoire, il y reste. Donc, si je dimensionne mon serveur pour 50 accès simultanés au maximum, la trace mémoire correspondra à ces 50 interprêteurs (ce n'est qu'un exemple). D'autre part, une fois qu'un module est chargé en mémoire, il y reste également, et ce, dans l'espace mémoire de chaque interprêteur... Donc, il peut très vite y avoir un effet de boulimie... C'est pour ça que je souhaite utiliser les modules avec parcimonie (disons que je ne vais aps m'en priver, mais si je peux éviter de charger un gros module contenant des dizaines de fonctions, avec une implémentation maison facile, alors il faut que j'aille dans ce sens...

En plus, sous Windows, il n'y a quasiment aucun partage de code: chaque interprpêteur dispose de sa propre version du code... (sous Linux, ça peut être différent, si tu utilise un système avec plusieurs processus)

Merci pour ta réponse en tout cas.

Et si tu as d'autres suggestions, elles sont les bienvenue.