ToursAnnonces.fr

08h37 :
pour juste 20 minutes, je préfère zapper la session de sysadmin,
faudra me coucher plus tôt ce soir.


Un truc à corriger tout de suite : 

sur ma liste, hier en voulant mettre en ligne pour présenter ma démo, je me suis rendu compte que mon code 
n'acceptait pas les caractères %,
en fait je n'ai pas tester les injections sql, donc pour l'instant, mon code doit être vulnérable, effectivement 
le système GET n'a pas les mêmes contraintes que le système POST,
voyons comment protéger cela tout de suite.

Même le caractère + ne passe pas.
Et le problème avec le post session c'est que l'erreur reste.
Même si je n'aime pas trop faire cela, le plus adapté ici sera de faire un trycatch et de détruire la variable de session concernant le
champ de recherche du listhandler fautif.

Briefage Komin> avec mon pote…

10h07 : résolution du problème : en fait rien avoir avec les injections sql, le code était bien sécurisé, mais c'était une erreur
sur le limit de la requête sql, il faisait un limit -20,20, bref…



Nous en sommes maintenant au système de management des erreurs, très intéressant.

Chaque champ du formulaire pourra être associé à une ou plusieurs règle(s) de validation.
Une règle de validation est associé à un champ de formulaire avec un tag comme identifiant.
Cela permet de faire une vérification pour un tag donné.
On peut donc récupérer ce tag et afficher un message pour ce tag, et cela permet également de faciliter le passage en multilangue.



13h pil poil  la validation vient d'être testée sur un champ avec succès
musique maestro!


15h20 : très bien!

Le système de validation est tout simple : 
Si l'utilisateur a posté le formulaire,
on demande au formhandler de faire une validation, avant d'aller plus loin.
La validation est le processus suivant :
pour chacun des éléments formfields du formulaire, on éxecute la méthode isValid qui retourne à chaque fois un booléen.
Si l'un de ces champs retourne false, alors la validation a échoué.

la méthode isValid d'un champ formfield est également très simple :
formfield regarde si des règles de vérification lui sont attachées.
Si c'est le cas, pour chacune d'entre elles, il va demander à l'objet de vérification associé au formulaire 
de faire une validation par rapport à la valeur courante du champ.
L'objet de Validation retourne à chaque fois un booléen, et si il retourne false, un message d'erreur est associé.
L'objet formfield mémorisera alors automatiquement l'erreur et la réaffichera dans le formulaire.
L'objet formfield retourne alors false.


Avant de passer tout de suite à l'automatisation,
j'aimerais quand même éprouver un peu plus mon système de liste, c'est à dire ajouter des actions
éditer, supprimer pour les tables, mais aussi ajouter une vue, par exemple en liste comme pour des annonces,
au lieu du basique (mais efficace) tableau html.



sport


20h02 : jeu avec ce schéma

kiftest.png


Le but est déjà de créer un système de liste avec des actions sur ce schéma.


distraction

00h32 le but est maintenant de créer un système type de formulaire, 
I mean de validation de formulaire,
qui puisse soutenir le update comme le insert.
Certainement un truc de base, mais également de se remettre en question et de reprendre ce vieux problème, vieux comme le web
et de trouver une solution qui soit , well, Ze solution….


Du moins en ce qui concerne mon aura.

En fait, je viens de me rendre compte que la solution est toute simple, mais depuis que j'ai commencé le web, je suis passé à côté,
car j'ai "mal" appris.


En fait la solution est aussi simple que :

si on arrive sur le form les mains vides, on désire un insert
si on arrive sur le form avec un GET id, alors on postule pour un update
Ce postulat pour un update est traité immédiatement : on effectue une requête qui permet de vérifier,
en fonction du contexte, si l'id fournie (on assume qu'il y a un champ id) est plausible, et qu'elle ne créera pas
de problèmes d'incohérence, ou autre.
Si l'id fournie semble mauvaise, on repart sur un insert
Sinon, l'id semble correcte, on demande l'update

A la fin de cette étape préliminaire, nous avons demandé soit un insert, soit un update

Lorsque le formulaire est posté, et que les données sont correctes,
on traite alors les données, conformément avec le voeu formulé précédemment : insert ou update.

Dans le cadre de mon framework,
je peux rediriger un utilisateur sur la page que je désire après la validation d'un formulaire.
Cette page pourrait être soit la liste des items insérés avec ce formulaire,
ou encore une page de félicitations, et dans ce cas, une variable supplémentaire devrait être passée dans l'url
et récupérée de manière à empêcher le traitement du formulaire (pour éviter le problème du rafraichissement intempestif).


Le seul petit hic surviendrait alors si je gardais ma technique actuelle de chargement des photos.
Actuellement les photos se chargent directement dans les bons dossiers.
Au prix d'une conception de formulaire plus complexe.


Si je simplifie le formulaire, les photos doivent tout de même être gérées par les sessions, j'aime bien ce procédé.
Mais du coup, lorsque l'utilisateur arrive la première fois sur le formulaire, il n'a pas encore d'identifiant de formulaire,
et donc, à moins de ne pas se baser sur cet identifiant pour le choix du dossier dans lequel les photos doivent aller,
je ne peux pas placer les photos au moment de leur chargement sur le serveur au bon endroit.

Je peux par contre générer un hash qui resterait en session, et qui serait effacé après le traitement réussi du formulaire,
mais cela serait spécifique au chargement des images.

Imaginons :


j'arrive sur le form avec photo
comme c un form avec photo, il me génére un identifiant unique, au pire un hash, mais peut être un identifiant créé manuellement,
avec l'id de l 'utilisateur,
je charge une photo, cela génére un identifiant qui est également le nom du dossier temporaire dans lequel est stocké la photo.
A la fin de la manip, lorsque l'on connaît l'identifiant réél, les photos sont replacées dans les bons dossiers.
Bof, couteux ?

Et pourquoi ne pas laisser photo dans leur dossier et faire pointer les images sur ce dossier ?
Parce que ce n'est pas l'organisation prévue.


Une autre idée très dangereuse, mais peut être que si c'est bien fait …
Lorsque c'est un insert, on fait l'insert direct avec des valeurs vierges, et on garde l'id en session,
que l'on efface dès que cet insert est réussi .


?

Pour homogénéiser, on passerait même l'id en get en session, pour avoir au final l'id du formulaire en session.
J'ai jamais fait confiance aux sessions.


Je crois que la solution qui me convient le mieux est de garder la simplicité du formulaire naturel,
puis pour un upload dynamique,, on utilise le plugin (à créer) d'upload dynamique d'images qui :
génère un hash.
Un dossier /temp/$hash est crée, 
la transaction se fait l'utilisateur remplit son formulaire et lorsque le formulaire est validé,
les photos sont déplacées, puis le dossier temporaire effacé.

Le hic : si l'utilisateur ne valide pas son formulaire, le dossier est quand même créé.
Il pourra recommencer l'opération 10000 fois, créant 10000 dossiers sans jamais valider le formulaire.

Ce qui m'embête :
conflit potentiel entre 2 hash
ne pas pouvoir identifier l'utilisateur chiant qui fait ça

une solution, forcer le dossier à /temp/$id_utilisateur/$hash
problème, la solution ne s'applique qu'aux cas de figure dans lesquels l'utilisateur est le possesseur de l'item.
Mais généralement, c'est le cas, et si ce n'est pas le cas, 
peut être que l'on peut mettre l'id_utilisateur à 0,
on aurait donc un dossier /temp/0 qui servirait de base à tou les uploads n'appartenant pas à des utilisateurs.
En fait, ca a l'air de tenir le coup du moins pour les quelques formulaires que j'ai fait dans ma vie,
en général lorsque il y a ajout de photo, il y a utilisateur derrière.

La variable $id_utilisateur n'est pas pure en soi, c'est qqchose de très spécifique et c me fait beurk,
mais si ce n'est lié que dans le cadre de l'utilisation d'un plugin d'upload alors ça passe beaucoup mieux.

En fait j'aime pas parce que ça fait quand même la restriction que la photo DOIT appartenir à l'utilisateur.
Trouvons autre chose.



Bon je ne trouve pas.
La nuit porte conseil il paraît , vérifions cela.
















*******************************
Kif_Fetcher_Database
Kif_HtmlTable