ToursAnnonces.fr

08h35
J'ai trouvé datetimeSlot comme nom pour le "module" d'affichage des horaires par rapport à un date time.

On devrait pouvoir choisir le style d'affichage : avec jquery datepick ou sans (vieux select), même si dans la pratique on n'utilisera que le mode jquery.
Ce module donc ne s'afficherait que si le datetime est en mode user évidemment.
La conversion des données du datetime en date+heure est évidemment prise automatiquement en compte, c'est là l'intérêt principal,
et par défaut le module affiche la date d'ajourd'hui, date pouvant être modifiée simplement.

Codons le en dur pour avoir l'aspect visuel final.

choses de la vie

sport

22h18
Une des qualités que devrait aoir un bon développeur c'est l'endurance :
encaisser,
rester lucide, savoir se rendre compte que l'on s'est empêtré, avoir le courage de prendre le temps de prendre du recul.

C'est ce qui s'est passé aujourd'hui, voulant résoudre 2 problèmes d'un coup, j'ai fait des erreurs de conception qu'il faut que je
corrige, pour cela, je dois revenir en arrière et refaire des tests, mieux définir mon objectif.

Finalement on y arrive, mais là, …
chui en train de me taper un débuggage de regex, alors que la deadline que je m'étais fixée est déjà passée,
toujours sur les dates, pas fini, reste l'automaticupload et les onglets, 

j'ai juste envie de me faire masser, mais non, débuggage de regex, allons courage…
j'vais pas m'plaindre non plus.

22h25 : ouf, en fait c'était juste que preg_match ne retourne pas true comme je croyais…

kool, un beau code, tout nickel et bien conçu qui gère les formats de date mysql
dans un formulaire.
Passons maintenant au splittage d'un date time en date + time.

Maintenant que j'ai un peu d'expérience en objet, je SAIS (enfin je crois) qu'il faut commencer par me faire le synopsis sur papier et estimer
les chances de réussite.
Et évidemment ces chances doivent être supérieures à 97% sans quoi, CA NE FONCTIONNERA PAS, tôt ou tard.

Bon essayons non c'est trop lent j'allais dire de raisonner en direct live la sur l'écran,
mais je suis bien plus rapide sur papier avec juste le cerveau.

Bon, logiquement,
la requête de garde est affectée,
la création d'un champ dédié
la conversion (ajout du champ horaire au date) APRES conversion de la date pour mysql


go;


Celui qui réfléchit récolte les fruits d'une conception simple.

23h18 : ok, il me semble que j'ai couvert les différentes méthodes à mettre en oeuvre, reste à les instruire à stos.

La pour cette fois,
je vais poser mes idées ici :


pour les champs dates, on a 2 options, ou bien ce sont des champs modifiables pas les utilisateurs,
ou bien ces champs ne sont pas modifiables pour les utilisateurs.

Les cas actuellement traités par stos sont les cas non modifiables, et donc ils devraient être invisibles aux yeux des utilisateurs.
Mais nous ferons cela après.


Les nouveaux cas dont l'intégration est succintement définis ci-dessous couvre les cas de champs date modifiables par un utilisateur.


Lorsque un formhandler contient au moins un champ date (ou datetime qui sera modifiable par l'utilisateur),
alors il convient de définir le format par défaut pour ce formulaire, nous assumons ici que l'utilisateur ne change pas de format d'un champ à l'autre.
Les 2 formats pour l'instant disponibles sont fr et mysql : dd-mm-yyyy et yyyy-mm-dd.

$fh->setDateFormat(DEFAULT_DATETIMESDATEFORMAT);


Nous pouvons décider d'activer ou pas le datetimesplit, 
si nous l'activons, alors un autre champ sera créé : les horaires : qui comporte 3 select.

/*******************************************************************************/
// MISCELLANEOUS PLUGINS
/*******************************************************************************/
$useDatetimeSplit_date_creation=true;


La requête de garde est affectée par l'utilisation de cette activation 

if (true === $useDatetimeSplit_date_creation) {
    $stmt .= "TIME(date_creation) as datetimesplit_date_creation,
";
}


Dans tous les cas de formulaires dont les dates sont modifiables par un utilisateur, le format choisi au début s'applique également sur la requête de garde :

date_format(date_creation,
        '". $fh->getDateFormatVariant(Kif_FormHandler::DATETIMESDATEOUTPUT_MYSQL) ."') as date_creation,
        

En cas d'utilisation du plugin jdatePick sur le champ date, nous devons également appliquer ce format
ainsi qu'une règle de validation de ce format.

$oElement->addJDatePick();
$oElement->aJdatePickOptions=array(
    'dateFormat' => $fh->getDateFormatVariant(Kif_FormHandler::DATETIMESDATEOUTPUT_JQUERYDATEPICK)
);
$oElement->addValidationRule('dateHasFormat', array('dateFormat' => $fh->dateFormat));


De plus, l'activation ou non du split affichera ou non les horaires :
if (true===$useDatetimeSplit_date_creation) {
    $oElementDTS_date_creation = new Kif_Form_SelectDatetimeSplit('Horaires', 'datetimesplit_date_creation');
    //$oElementDTS_date_creation->setHHObject($hh_Object);
    //$oElementDTS_date_creation->addJtip('/webservice/jtip/ajax.htm','Coucou', 375);
    $fh->addElement('datetimesplit_date_creation', $oElementDTS_date_creation);
}
        
        

Enfin au niveau de la validation des données,
chaque champ date défini doit être reconverti au format sql,
et si le split est activé, alors on ajoute le champ horaire à cette chaîne

        $date_creation = $fh->convertAnyDateToMysqlDateFormat($date_creation);
        if (true===$useDatetimeSplit_date_creation) {
            $date_creation .= ' ' . $oElementDTS_date_creation->getTimeSlotFromPost();
        }
        
        
        
Voilà, en gros.
Action…



00h27 : le premier jet est fini, en phase de débuggage…
00h42 ok à priori ce la fonctionne,

j'arrête là pour ce soir, je vais regarder un film …