ToursAnnonces.fr

06h18 sysadmin

08h55 faisons directement la partie difficile tant que je suis en forme
Pour le formulaire, lorsque la requête sera complexe, cad avec des joins du genre 


select h.nom, h.prenom, v.nom as vnom from human h
inner join ville v on v.id=h.ville_id
where h.id = x


Déjà, hélas comme certains noms de table sont très longs, on ne va pas mettre les noms de tables complets
suivis des noms de champs, ce qui aurait été plus rapide à développer, mais tellement plus chiant à utiliser par la suite.

On va créer une fonction qui trouve les diminutifs "adéquats" pour les tables ainsi que les alias.
Si il n'y a aucune table jointe, on n'utilisera pas de diminutif,
si il y a au moins une table jointe, si une seule lettre suffit sans qu'il y ait conflit, alors on prend une seule lettre, sinon 2, puis 3, etc…
Le nom de l'alias sera diminutif_variable

Donc dans l'exemple précédent, la fonction doit trouver exactement ces diminutifs et alias :
select h.nom as h_nom, h.prenom as h_prenom, v.nom as v_nom
from human h
inner join ville v on v.id=h.ville_id
…


On va essayer avec un tableau $aTablesToAliases : array(
tablename => alias,
...
) 


Avant cela il nous faut un tableau $aJoinedTables, qui ne contient que les tables jointes, et pas la table de base donc.

Puis la fonction prepareTablesToAliasesArray();
qui setupera le tableau $aTablesToAliases à partir des propriétés tableName et aJoinedTables stockées plus tôt.


Go pour ça.

On fera même un helper : getJoinedTables, 
qui peut le plus peut le moins, cette fonction sera récursive, et trouvera donc les jointures des jointures…

Non, en fait il faut savoir ce que l'on veut plus précisément.
Pour les formulaires, on cherche juste à créer les champs correspondant à la table analysée.
Lorsque un champ fait référence à une autre table, seules les infos de l'autre table suffisent à l'identifier de manière
précise, pas besoin en plus d'aller chercher les infos liées à des niveaux de profondeur plus élevée.


Donc pour l'instant ma méthode s'appellera getOneLevelJoinedTables

En fait pas du tout mais pas le temps d'expliquer…

11h32 : la requête est faite, le formulaire gère maintenant les select sur un niveau.

12h08 : je me rends compte que mon esclave ne fera pas à ce stade la chose suivante : la gestion des
relations complexes.
Mais du moins, j'ai conscience de mon désir que l'objetrésolve également les relations du type has many,
enfin j'y connais rien en relations sql, mais disons que la table commerces a plusieurs blocs infos.

Idéalement, et j'ai vu que c'était possible grâce au contenu de la table information_schema, 
il faudrait que le formulaire et la liste contiennent les informations sur les bloc_info des commerces automatiquement,
mais finissons déjà les relations simples;

sport


20h43 : ok pour les interactions simples pour les listes, le code est brossé, un vrai plaisir pour le développeur.

divertissements


22h18 : il me reste, pour finir une base correcte à faire la gestion des dates, et la gestion des automatic upload et l'ajout d'onglets au niveau du design.


Bien sûr comme je suis toujours en retard je n'aurai pas fini ce soir.

Maintenant concentrons nous sur les date.

Il y a date, datetime
si ils ne sont pas nullables,
apparemment mysql insère par défaut pour date 0000-00-00
et pour datetime 0000-00-00 00:00:00
Bizarre, il me semblait qu'avec mon ancienne méthode le temps de création était automatiquement mis au time actuel.
Mais bon, faisons avec ce qu'on voit.

En fait, non, en lisant la doc mysql, le champ date par defaut doit retourner avec NOW() la date courante, et la valeur
0000-00-00 00:00:00

est ce qui retourné en cas de donnée invalide,
cela veut dire que mon framework fournit des données invalides à mysql.
Effectivement, pour sécuriser globalement les requêtes, tous les champs sont échappés avec le système de tags mysql
where id=:id

du coup le passage de NOW() dans mon tableau de tags n'est pas interprété correctement.
Je peux faire un if supplémentaire dans ma fonction de conversion, c'est peut être le meilleur compromis entre les 2 mondes.
Ca yest pour date, un peu tricky, mais bon cela fonctionne.

Faisons la même chose avec date et CURRENT_DATE  et instruisons mon esclave de générer le champs date et datetime avec les valeurs par défaut respectives.
Du moins j'ai un doute.
Pour la date, non bon qui peut le plus peut le moins, si je n'ai pas besoin de la date courante, je n'aurais qu'à mettre une chaîne vide manuellement.


En réfléchissant un peu, le comportement de date automatique n'est souhaitable que si on n'a pas l'intention que l'utilisateur puisse la modifier.
Lorsque l'utilisateur peut modifier la date, il ne faut pas utiliser le comportement automatique, cela n'empêche pas de renseigner une valeur par défaut.

Ne pouvant pas prévoir lequel de ces 2 cas sera utilisé juste avec le type de champ (date ou datetime),
je peux décider, comme dans mon framework précédent, que suivant la valeur qui est renseignée dans les commentaires mysql, 
stos génère un type plutôt que l'autre.
Pour me faciliter la tâche, il générera les 2 cas possibles l'un en-dessous de l'autre, avec le cas désactivé en commentaires dans le code,
ainsi je n'aurais plus qu'à commenter/décommenter pour avoir un comportement plutôt que l'autre.
Disons que si il n'y a aucun commentaire, le remplissage automatique est utilisé, et si la valeur user est renseignée,
alors le champ est un champ normal.
Ok,

Le grand intérêt pour les dates est d'intégrer le plugin de date jdate,
et pour faire un bon workaround, gérer les datetime avec ce plugin plus gestion automatique des horaires sous formes de listes déroulantes.

Très intéressant, mais déjà 23h44.
Nous allons commencer par l'intégration de jdate sur le champ date normal
Je pourrais aussi me coucher maintenant, mais non.

Ok pour l'intégration juste html, j'ai un peu peaufiner, j'ai également rajouté une image de jtip sympa : une ampoule.

Avant de me coucher j'aimerais bien coder la méthode globale d'intégration d'un plugin jquery par rapport au form.


Ok, pas mal…
Restera demain le plugin pour transformer un champ date time en jdate + horaire,
le plus dur, c'est à dire l'automatic upload,
et une couche design, 
puis une couche debug, et on devrait être pas trop mal;