developer.jelix.org is not used any more and exists only for history. Post new tickets on the Github account.
developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.

Opened 13 years ago

Closed 11 years ago

Last modified 11 years ago

#196 closed task (fixed)

jforms: ajout d'un datepicker pour la saisie des dates/times

Reported by: laurentj Owned by: Julien
Priority: high Milestone: jelix 1.1
Component: jelix:forms Version: 1.0 beta2
Severity: normal Keywords:
Cc: Blocked By:
Blocking: Documentation needed: no
Hosting Provider: Php version:

Description

Ajouter un script DHTML pour afficher un datepicker sur les input type="date/datetime/time"

Attachments (8)

196-jForms-datePickers.diff (40.0 KB) - added by Julien 11 years ago.
form.form.xml (1.1 KB) - added by Julien 11 years ago.
sample jForm
196-jForms-datePickers.2.diff (46.9 KB) - added by Julien 11 years ago.
updated patch with RelaxNG schema and missing locale files for english
jforms-date-time.jpg (31.1 KB) - added by Julien 11 years ago.
196-jForms-datePickers-final.diff (59.3 KB) - added by Julien 11 years ago.
final patch
form.form.2.xml (884 bytes) - added by Julien 11 years ago.
sample form for latest patch
calendar.gif (1.0 KB) - added by Julien 11 years ago.
image calendrier car pas possible d'intégrer au diff
196-jForms-datePickers-final.2.diff (59.2 KB) - added by Julien 11 years ago.
little mistake in previous patch fixed

Download all attachments as: .zip

Change History (48)

comment:1 Changed 13 years ago by laurentj

  • Milestone changed from Jelix 1.0beta3 to Jelix 1.0
  • Priority changed from normal to low

comment:2 Changed 13 years ago by laurentj

  • Blocking 35 removed

comment:3 Changed 13 years ago by laurentj

  • Milestone changed from Jelix 1.0 to Jelix 1.1

comment:4 Changed 13 years ago by laurentj

  • Priority changed from low to high

comment:5 Changed 12 years ago by webseb

  • Documentation needed unset

Bonjour,

Je ne sais pas si il est prevu d'intégrer un datepicker jQuery, mais pour info jQuery à un datepicker officiel : UI datepicker

Doc : http://marcgrabanski.com/code/ui-datepicker/

Infos : http://plugins.jquery.com/project/uidatepicker

comment:6 Changed 12 years ago by laurentj

le plugin date_input a déjà été intégré dans la distribution Jelix. Mais il reste encore à faire la "connection" avec jforms.

comment:7 Changed 12 years ago by Julien

  • Owner set to Julien
  • Status changed from new to assigned

Je vais en avoir besoin pour un projet semaine prochaine, donc je prends...

comment:8 Changed 12 years ago by Julien

hello,

j'ai pas eu trop le temps en fait jusqu'à maintenant, mais avant que je commence, question : vaudrait pas mieux utiliser le composant officiel de jQuery-UI ?

Merci

comment:9 Changed 12 years ago by laurentj

Je ne sais pas. J'imagine que vouloir utiliser ce composant officiel, signifie charger plus de fichier js que le date_input, non ?

comment:10 Changed 12 years ago by Julien

Il faut effectivement charger le UI core (8Ko non compressé, 5 en minified et 3,5 en packed) en plus.

mais comme le ui.core est utilisé à la base de plein d'autres trucs, c'est peut-être un "investissement rentable".

Pour le composant en lui-même, le fichier est un peu plus lourd (environ 15ko de diff), mais il semble aussi y avoir bcp plus de fonctionnalités (séléction de plages au sein du même calendrier, restrictions sur les choix possibles : pas de choix d'année, juste sélection dans un mois donné, etc, ...) et de possibilités de personnalisation.

Je pense que ça peut valoir le coup d'utiliser un truc un peu + lourd pour avoir toutes les possibilités, et comme dit, le UI Core est la base pour d'autres composants qu'on voudra peut-être intégrer un jour.

comment:11 Changed 12 years ago by laurentj

j'hesite quand même. Surtout avec le system de builder que l'on a maintenant dans jelix. Si on veut des formulaires avec des trucs "hype" dans tout les sens, rien n'empêche de faire un builder "htmljquery", utilisant ui et cie. Tu va me dire qu'on utilise aussi jquery dans le builder html, mais c'est juste pour le datepicker (bientôt) et l'éditeur html... faut voir...

ou alors le builder html par défaut, c'est avec tout les trucs. Mais il serait interressant d'avoir un builder "light" pour ceux qui ne veulent pas des pages lourdes.

comment:12 Changed 12 years ago by Julien

yup bien compris

de mon point de vue, utiliser jqueryUI (que je ne connais pas, j'ai juste vu que c'était le truc officiel pour les composants d'interface) est peut-être plus pérenne, dans le sens où c'est lié étroitement à jQuery, donc les mises à jour sont a priori synchro, etc...

Charger le coeur UICore ne servira pour l'instant que pour le datepicker c'est vrai, mais comme il est à la base de plein d'autres effets qu'on pourrait vouloir intégrer à divers endroits (je pense à des trucs rigolos comme ici ou pour un mediamanager dans jCMS ;)

Bien sûr le développeur pourrait lui-même rajouter ce dont il a besoin, voir utiliser une autre lib. Mais si déjà on se dit qu'on intègre jquery à la base, autant utiliser les composants de jqueryUI pour les trucs intégrés dans Jelix afin d'avoir un ensemble homogène.

Sans doute que ça facilitera les mises à jour aussi.

comment:13 Changed 12 years ago by bastnic

Julien, je suis parfaitement d'accord avec le principe.

Là pour deux projets j'envisage de passer à http://extjs.com/products/gxt/ . Faut que je teste.

comment:14 Changed 12 years ago by AdrienC

Bonjour, je propose mon hack du builder html de jforms pour utiliser le datepicker deja present (jquery/date_input) :

jelix/plugins/jforms/html/html.jformsbuilder.php : dans public function outputMetaContent($t), rajouter :

        $resp->addJSLink($www.'jquery/jquery.js');
        $resp->addJSLink($www.'jquery/date_input/jquery.date_input.min.js');
        $resp->addJSLink($www.'jquery/date_input/jquery.date_input.format.js');
        $resp->addJSLink($www.'jquery/date_input/jquery.date_input.'.$GLOBALS['gJConfig']->locale.'.js');
        $resp->addCSSLink($www.'jquery/date_input/date_input.css');
        $resp->addJSCode('$($.date_input.initialize);');

dans public function outputControl($ctrl), rajouter :

        $class.= ($ctrl->datatype instanceof jDatatypeDate?' date_input':'');

jquery.date_input.format.js : rajouter ce fichier dans jquery/date_picker

jQuery.extend(DateInput.DEFAULT_OPTS, {
  stringToDate: function(string) {
    var matches;
    if (matches = string.match(/^(\d{4,4})-(\d{2,2})-(\d{2,2})$/)) {
      return new Date(matches[1], matches[2] - 1, matches[3]);
    } else {
      return null;
    };
  },

  dateToString: function(date) {
    var month = (date.getMonth() + 1).toString();
    var dom = date.getDate().toString();
    if (month.length == 1) month = "0" + month;
    if (dom.length == 1) dom = "0" + dom;
    return date.getFullYear() + "-" + month + "-" + dom;
  }
});

(C'est les fonctions de demonstration de formattage des dates dispo ici : http://jonathanleighton.com/projects/date-input)

Il y a surement une facon plus propre de faire ... Et ce datepicker est un peu just, il convient pour choisir une date proche de l'actuelle, mais pour choisir une date de naissance, il faudrait cliquer beaucoup trop de fois pour choisir l'annee ... celui de jquery ui serait une bonne alternative je pense ..

comment:15 Changed 12 years ago by AdrienC

.. et le hack pour utiliser jquery ui datepicker :

telecharger jquery ui avec le core et le datepicker ici : http://ui.jquery.com/download_builder/

le dezipper dans jquery/ui_datepicker

y placer egalement http://jquery-ui.googlecode.com/svn/trunk/themes/default/ui.datepicker.css et http://ui.jquery.com/repository/demos_templates/images/calendar.gif

dans jelix/plugins/jforms/html/html.jformsbuilder.php dans public function outputMetaContent($t), rajouter :

        $resp->addJSLink($www.'jquery/jquery.js');
        $resp->addJSLink($www.'jquery/ui_datepicker/jquery-ui-personalized-1.6b.min.js');
        $shortLocale = substr($GLOBALS['gJConfig']->locale, 0, 2);
        $resp->addJSLink($www.'jquery/ui_datepicker/i18n/ui.datepicker-'.$shortLocale.'.js');
        $resp->addJSCode('$(document).ready(function(){
                $(".datepicker").datepicker({
                        dateFormat: "yy-mm-dd",
                        showOn: "both",
                        buttonImage: "'.$www.'jquery/ui_datepicker/calendar.gif",
                        buttonImageOnly: true
                });
        });');
        $resp->addCSSLink($www.'jquery/ui_datepicker/ui.datepicker.css');

et dans public function outputControl($ctrl), rajouter :

        $class.= ($ctrl->datatype instanceof jDatatypeDate?' datepicker':'');

comment:16 Changed 12 years ago by laurentj

  • Milestone changed from Jelix 1.1 beta 1 to Jelix 1.1 beta 2

comment:17 Changed 11 years ago by Julien

hello

jquery UI or not ?

peut-être jQuery UI pour le builder HTML

et le plugin date_input pour le builder light ?

Comme ça tout le monde peut être content.

Mais bon, je préférerai largement utiliser jQuery UI dans les 2 cas, ça fera moins à maintenir, et comme dit, les .js c'est dans le cache en général.

Ou alors le builder light ne supporte pas de datepicker ?

Bref, je vais déjà faire le builder standard avec jQuery UI.

comment:18 Changed 11 years ago by bastnic

Comment gérer la version de jQuery UI utiliser ? On va sûrement mettre core + datepicker. Et si on veut le remplacer par un package plus complet SANS avoir à le mettre dans jelix-www appelé par vhost ?

Un option de config ?

comment:19 Changed 11 years ago by Julien

Tu parles sans doute par rapport au DL personnalisé en un seul fichier.

Je pense plutôt charger le "dev bundle" de la version stable.

Dans l'archive, il y a un dossier "minified" avec l'ensemble des scripts js que l'on mettrait dans jelix-www ; chaque script peut alors être chargé individuellement.

Ainsi, pour le datepicker, on utiliserai juste UI core (4.6Ko) et datepicker (41.2Ko).

Pareil, le gars qui veut un jqueryUI plus récent, il remplace juste les fichiers (bien sûr la compatibilité n'est plus assurée, mais c'est son choix)... Si c'est juste pour 1 site, alors il mets le dossier www/jelix en dur et non en lien symbolique / Alias. C'est d'ailleurs vrai aussi pour jQuery et wymeditor.

Bref, je vois le truc comme ça : à chaque nouvelle version de Jelix, on mets à jour si nécessaire jQuery / jQueryUI (ces 2 là sont tjrs couplés de toute façon). Le gars qui veut une autre version est "hors release".

comment:20 Changed 11 years ago by bibo

Je verrais bien des options de config pour charger le datepicker que l'on veut. Dans l'esprit de l'editeur WYSIWYG. Cela permet de controler exactement les fichiers à envoyer dans la réponse.

[datepickers] default.name = datepicker default.file[] = jquery/jquery.js default.file[] = jquery/datepicker/ui.datepicker.js default.file[] = jquery/datepicker/ui.datepicker-fr.js default.skin = jquery/datepicker/ui.datepicker.css default.config = "{showOn: 'both', minDate: '-60y', maxDate: '-10y', yearRange: '-60:0', firstDay: 1, defaultDate:'-10y'}"

comment:21 Changed 11 years ago by Julien

ça me plaît bien ;)

je vais partir sur cette idée de conf

comment:22 Changed 11 years ago by laurentj

  • Milestone changed from Jelix 1.1 beta 2 to jelix 1.1

Milestone Jelix 1.1 beta 2 deleted

comment:23 Changed 11 years ago by laurentj

Je viens d'ajouter jquery ui 1.6rc2 et mettre à jour date_input.

Julien, tu en es où ?

comment:24 Changed 11 years ago by Julien

eh ben, là c'est synchro !

je suis justement en train de bosser dessus depuis 10mins ;)

à mon avis encore un patch ce soir, sinon demain

comment:25 Changed 11 years ago by Julien

désolé pour le temps que ça prend, mais c'est pas si simple avec la multiple config et les différents formats de date (localisation)

je vais mettre le datepicker sur les champs de type date et localedate, par contre c'est plus hasardeux pour les (locale)datetime.

Pour le reste, je me demande s'il ne faudrait pas ajouter des balises spécifiques à jForms, du type :

  • <date>, avec donc 3 champs de saisie/liste déroulantes, en fonction d'un attribut "type", avec en plus un attribut "local" true/false, la possibilité d'indiquer une année/mois min/max, etc...
  • <datetime>, idem ci-dessus, avec en plus heures, minutes, et sur attribut optionnel secondes

ce serait en tout cas plus puissant que l'actuel <input>, et le code pourrait être plus facile aussi au final (pas de test sur l'attribut type pour savoir si c'est une date, une date locale, etc...)

Bref, je mets déjà le datepicker de base là où je peux et je reviens poster ici

comment:26 Changed 11 years ago by Julien

  • review set to review?

Bon, tout n'est pas parfait, mais voici un premier jet

Changed 11 years ago by Julien

Changed 11 years ago by Julien

sample jForm

comment:27 Changed 11 years ago by Julien

je dois encore vérifier l'histoire des limites de dates, des multiples configs, etc....

y a encore du boulot, mais je voudrais déjà faire valider ça.

NB : pour les <input> avec type="datetime", c'est pas possible de mettre un datepicker (en tout cas pas celui de jQuery UI) car le champs est automatiquement limité en longueur, par rapport au dateformat spécifié.

Il faudra aussi que je regarde pour les dates au format localisé.

comment:28 Changed 11 years ago by Julien

Hello,

j'ai aussi oublié les RelaxNG pour le moment, ainsi que la batterie de tests unitaires qui va avec ces nouveaux contrôles de form.

Par contre j'avais vérifié que les tests unitaires en place fonctionnaient sans prob, y a donc rien de cassé ;)

Changed 11 years ago by Julien

updated patch with RelaxNG schema and missing locale files for english

comment:29 follow-up: Changed 11 years ago by laurentj

  • review changed from review? to review-
+++ lib/jelix/plugins/jforms/html/html.jformsbuilder.php	(copie de travail)
@@ -82,6 +82,24 @@
                 }
             }
         }
+        $lang = jLocale::getCurrentLang();
+        foreach($this->_form->getDateControls() as $dateControl){

Il ne faut pas tenir compte de $this->_form, et intégrer le contenu de cette boucle dans le foreach précédent.

@@ -265,8 +283,149 @@
             $this->jsContent .="c.minLength = '$minl';\n";
 
         $this->commonJs($ctrl);
+
+        if($dt == 'Date')
+            $this->jsContent .= "jforms_datepicker_default(c,".$this->escJsStr(jLocale::get('jelix~jforms.datePicker.button.label')).",".$this->escJsStr($GLOBALS['gJConfig']->urlengine['basePath']).");\n";

Puisqu'il y a un widget <date>/<datetime> spécifique, je propose que le <input type="date"> reste comme il est. Pas de datepicker pour input type date. Saisie brute donc.

Pour le builder light : pas de datepicker ni pour <input type=date>, ni pour <date/datetime>. (sinon c'est plus light :-))

+    protected function outputDate($ctrl, $id, $class, $readonly, $hint){
+        $id = $this->_name.'_'.$ctrl->ref.'_';
+        $v = $this->_form->getData($ctrl->ref);
+        if($v==='')
+            $v = array('year'=>'','month'=>'','day'=>'');
+        else{
+            $v = explode('-',$v);
+            $v = array('year'=>$v[0],'month'=>$v[1],'day'=>$v[2]);
+        }

Peut etre utiliser une regexp, pour éviter d'avoir n'importe quoi ?

+        if($ctrl->displayAs == 'fields'){

Utiliser des constantes de classes numériques pour ce genre de valeurs. (constantes à définir dans jFormsControlDate)

+        echo $dayControl,$monthControl,$yearControl;

Ajouter un éspace entre chaque controle..

Vu qu'il y a du code très semblable entre outputDate et outputDateTime, voir si on peut pas factoriser du code dans une sous-méthode commune.

jFormsControlDatetime devrait hériter de jFormsControlDate

+        $source[]='$ctrl->datatype= new jDatatypeDate();';

Pas nécessaire, puisque défini par défaut dans la classe jFormsControlDate/time

+        if(isset($attributes['display'])){
+            $source[]='$ctrl->displayAs = \''.$attributes['display'].'\';';
+            unset($attributes['display']);
+        }
+        if(isset($attributes['minyear'])){
+            $source[]='$ctrl->minYear = \''.$attributes['minyear'].'\';';
+            unset($attributes['minyear']);
+        }
+        if(isset($attributes['maxyear'])){
+            $source[]='$ctrl->maxYear = \''.$attributes['maxyear'].'\';';
+            unset($attributes['maxyear']);
+        }
+        if(isset($attributes['monthlabels'])){
+            $source[]='$ctrl->monthLabels = \''.$attributes['monthlabels'].'\';';
+            unset($attributes['monthlabels']);
+        }

vérifier ici les valeurs. Assigner les constantes que tu auras defini pour display et monthLabel.

@@ -215,6 +216,7 @@
     public function check($value) {
         $this->dt = new jDateTime();
         if(!$this->dt->setFromString($value,$this->format)) return false;
+        if($this->dt->toString($this->format) !== $value) return false;

Je n'arrive pas vraiment à comprendre le pourquoi de cette ligne de code ?

D'un point de vue général, quelques questions que je me pose :

  • monthlabels et display, c'est plus de la présentation. Est ce que ce ne serait pas plutôt un truc à indiquer dans la config du datepicker ?
  • avoir un seul <datetime>, auquel on indiquerait si on veut la date et/ou l'heure et/ou les secondes ? on indiquerait le format quoi. Ça éviterait des doublons dans le code. Le format qu'on indiquerait devrait être compatible avec date_create/date_create_from_format etc, histoire de rester compatible avec l'existant et le futur de php (cf http://blog.pascal-martin.fr/post/php-5.3-nouveautes-manipulation-dates)

Voir aussi http://blog.pascal-martin.fr/post/php-5.3-intl-1-internationalisation-localisation

comment:30 in reply to: ↑ 29 Changed 11 years ago by Julien

Replying to laurentj:

Il ne faut pas tenir compte de $this->_form, et intégrer le contenu de cette boucle dans le foreach précédent.

j'avoue que la boucle du dessus pour moi est un peu obscure. Pas par rapport au wysiwyg, mais par rapport aux elts parcourus. Il peut y avoir plusieurs objets $v qui sont des jFormsBase ? outputMetaContent() n'est appelé qu'une fois même s'il y a plusieurs forms ? (à la lecture des plugins de template, par exemple formull, je vois que outputMetaContent() sera appelé pour chaque form, non ?)

bref, j'ai du louper un cas où il peut y avoir plusieurs instances de jFormsBase à prendre en compte dans 1 builder.

Puisqu'il y a un widget <date>/<datetime> spécifique, je propose que le <input type="date"> reste comme il est. Pas de datepicker pour input type date. Saisie brute donc.

oki

Pour le builder light : pas de datepicker ni pour <input type=date>, ni pour <date/datetime>. (sinon c'est plus light :-))

oki

Peut etre utiliser une regexp, pour éviter d'avoir n'importe quoi ?

pourquoi pas oui, là c'était vraiment le premier jet

Utiliser des constantes de classes numériques pour ce genre de valeurs. (constantes à définir dans jFormsControlDate)

ok très bien, mais voir plus bas si ce n'est pas des params de config au final

+        echo $dayControl,$monthControl,$yearControl;

Ajouter un éspace entre chaque controle..

je pense même qu'il faudrait un formattage plus évolué, pour par exemple pouvoir mettre le champ mois avant le jour en anglais, tout comme à l'affichage. Mais comme dit c'était un premier jet ;)

Vu qu'il y a du code très semblable entre outputDate et outputDateTime, voir si on peut pas factoriser du code dans une sous-méthode commune.

jFormsControlDatetime devrait hériter de jFormsControlDate

je suis d'accord là-dessus, sauf si l'on fait un contrôle commum

+        $source[]='$ctrl->datatype= new jDatatypeDate();';

Pas nécessaire, puisque défini par défaut dans la classe jFormsControlDate/time

pas faut, un peu rapide dans le copié/collé

vérifier ici les valeurs. Assigner les constantes que tu auras defini pour display et monthLabel.

ok pour les constantes, mais peut-être finalement vers de params de config.

pour année min/max, le mieux serait de faire date min/max, avec la même syntaxe que ce que permet le datepicker de jquery UI. Mais j'avais la flemme de modifier, je voulais déjà un premier retour. La validité des dates serait ainsi vérifiée. Par exemple :

<date mindate="2006-12-08" maxdate="+1y +7m +3d">
...
</date>
@@ -215,6 +216,7 @@
     public function check($value) {
         $this->dt = new jDateTime();
         if(!$this->dt->setFromString($value,$this->format)) return false;
+        if($this->dt->toString($this->format) !== $value) return false;

Je n'arrive pas vraiment à comprendre le pourquoi de cette ligne de code ?

euh, là je sais plus ;)

faudrait que je refasse le tour plus en profondeur. C'est possible aussi que ce soit une erreur ou un test bizarre que j'ai oublié d'enlever..

D'un point de vue général, quelques questions que je me pose :

  • monthlabels et display, c'est plus de la présentation. Est ce que ce ne serait pas plutôt un truc à indiquer dans la config du datepicker ?

ok pour moi, même si ca veut dire qu'il faut plusieurs configs pour gérer les différents cas. 2 paramètres = 4 configs pour gérer les combinaisons. Bon ceci dit, en général le dev souhaitera rester uniforme au cours de son programme, donc pas un soucis.

  • avoir un seul <datetime>, auquel on indiquerait si on veut la date et/ou l'heure et/ou les secondes ?

ça me va bien, ce sera peut-être plus simple effectivement.

Questions de ma part aussi :

  • y a-t-il encore lieu de gérer la saisie des dates localisées via le widget <datetime> ? Y-a-t-il un sens à récupérer un date dans une formulaire autrement que via le format Y-m-d( H:i:s) ?
    Il vaudrait peut-être mieux dire que dès qu'on a une <datetime>, le format est "figé".
  • est-ce que le <input type="date/datetime/localedate/localedatetime"> doit être maintenu (au niveau fonctionnel, pas par rapport à la compatibilité). Quel est l'intérêt ?

enfin, pour la config du datepicker, j'ai besoin d'inclure des fichiers localisés. C'est peut-être un peu crade ça non ? :

foreach($gJConfig->datepickers[$config.'.engine.file'] as $url) {
    $resp->addJSLink($bp.str_replace('$lang',$lang,$url));
}

pour ça, et pour d'autres problématiques, ne vaudrait-il pas mieux, dans la config du date picker, spécifier un nom de fonction php qui se chargerai d'initialiser le côté PHP du datepicker ? Tout comme on a le fichier avec l'initialisation du datepicker côté JS ? Bien entendu, les paramètres "display", "monthLabels", et autres éventuels resteraient dans le fichier ini. Mais l'utilisation d'une fonction permettrait d'avoir une initialisation plus simple, et peut-être plus facile à personnaliser.

Car avec le système actuel, les paramètres possibles pour 1e datepickers sont figés, pas possible de prendre en compte un paramètre qui s'appelle toto dans la config du datepicker. Si les paramètres sont parsés par une fonction php autonome, alors, c'est possible sans prob, et sans doute plus propre.

Je vais faire un essai dans ce sens, vous me direz ce que vous en pensez ;)

PS : ce serait le même raisonnement pour les éditeurs wysiwyg

comment:31 follow-up: Changed 11 years ago by laurentj

bref, j'ai du louper un cas où il peut y avoir plusieurs instances de jFormsBase à prendre en compte dans 1 builder.

Je t'avouerai que moi aussi, j'ai oublié la raison. Mais par sécurité, faisons comme c'est actuellement.

je pense même qu'il faudrait un formattage plus évolué, pour par exemple pouvoir mettre le champ mois avant le jour en anglais, tout comme à l'affichage. Mais comme dit c'était un premier jet ;)

effectivement, il faut gérer le cas... du format de date.

Mais d'ailleurs, si il y a ces champs de saisie, c'est qu'il n'y a pas de date picker ?

y a-t-il encore lieu de gérer la saisie des dates localisées via le widget <datetime> ? Y-a-t-il un sens à récupérer un date dans une formulaire autrement que via le format Y-m-d( H:i:s) ? Il vaudrait peut-être mieux dire que dès qu'on a une <datetime>, le format est "figé".

oui, puisque normalement, l'utilisateur ne saisie pas directement.

est-ce que le <input type="date/datetime/localedate/localedatetime"> doit être maintenu (au niveau fonctionnel, pas par rapport à la compatibilité). Quel est l'intérêt ?

oui, il doit être maintenu. interet : compatibilité avec l'existant, et peut être qu'il y en a qui préfère.

plus j'y reflechi, plus je pense que les paramètres d'affichage doivent être dans la config du datepicker, parce qu'après tout, les datepickers n'utilisent pas tous ces paramètres...

pour la langue et la fonction php, je ne sais pas trop.

comment:32 in reply to: ↑ 31 Changed 11 years ago by Julien

Replying to laurentj:

Je t'avouerai que moi aussi, j'ai oublié la raison. Mais par sécurité, faisons comme c'est actuellement.

cool, y a pas que moi à qui ça arrive ;)

Mais d'ailleurs, si il y a ces champs de saisie, c'est qu'il n'y a pas de date picker ?

sisi, il y a le datepicker en plus dans le builder html.

en fait, les champs/selectbox sont affichés dès qu'il y a le widget <date(time)>. Le datepicker jquery UI se greffe en plus dessus (car c'est souvent utile de pouvoir sélectionner "le dernier lundi de septembre" ou tout simplement d'avoir une représentation visuelle. Pour les exemples, voir fichier image joint.

est-ce que le <input type="date/datetime/localedate/localedatetime"> doit être maintenu (au niveau fonctionnel, pas par rapport à la compatibilité). Quel est l'intérêt ?

oui, il doit être maintenu. interet : compatibilité avec l'existant, et peut être qu'il y en a qui préfère.

oki, mais on est d'accord que c'est beaucoup pour la compatibilité

plus j'y reflechi, plus je pense que les paramètres d'affichage doivent être dans la config du datepicker, parce qu'après tout, les datepickers n'utilisent pas tous ces paramètres...

en fait, il faut distinguer 2 choses je pense :

  • la config du widget <datetime>, notamment la façon d'afficher les mois et d'utiliser des input ou select
  • la config du datepicker, qui elle ne s'active que dans le builder html (pour l'instant), dont l'application, j'en suis de plus en plus sûr, doit se faire par une fonction php autonome. Je vais coder un exemple pour que tu puisses mieux juger.

autre remarque : pour l'icône du datepicker, j'ai pris une icone de la collection Silk de FamFamFam?. On peut l'utiliser librement, mais il faut "déclarer le copyright sur le site web". Bref, j'ai pas su où rajouter ce copyright, dans quel fichier de Jelix. On peut :

  • décider de faire notre propre icône, et le problème est réglé
  • se dire que ces icônes pourraient être utiles pour d'autres modules jelix (acl, auth, media manager, etc...) et décider d'intégrer la lib, et dans ce cas, où on met le copyright du truc ?

Changed 11 years ago by Julien

comment:33 Changed 11 years ago by Julien

Yop,

juste pour dire que je suis en train de bosser sur le ticket

j'arrive à des choses intéressantes, notamment avec la gestion des limites de dates. Un truc très souple.

j'ai par contre gardé 2 widgets : <date> et <datetime> car c'est plus facile à gérer au final. J'ai par contre factorisé une partie du code pour être + léger.

Je poste le patch dès que c'est à nouveau utilisable ; je dois juste ajouter le datepicker de jQuery et c'est bon.

comment:34 Changed 11 years ago by Julien

c'est encore pour ce soir, sauf mauvaise surprise. Plus que le côté chargement et activation du datepicker jQueryUI à optimiser.

Changed 11 years ago by Julien

final patch

comment:35 Changed 11 years ago by Julien

  • review changed from review- to review?

voilà le patch final :) j'vais aller dormir moi.

Il manque les tests unitaires pour les nouvelles fonctionnalités, ainsi que les relaxNG mis à jour... mais bon, jetez déjà un oeil là-dessus...

Changed 11 years ago by Julien

sample form for latest patch

Changed 11 years ago by Julien

image calendrier car pas possible d'intégrer au diff

Changed 11 years ago by Julien

little mistake in previous patch fixed

comment:36 Changed 11 years ago by laurentj

  • review changed from review? to review+

ok.

comment:37 Changed 11 years ago by Julien

Yeah !

j'essayerai encore de mettre les tests unitaires et l'update des RelaxNG pour la 1.1 finale, mais bon, c'est déjà un gros morceau de validé là !

Merci !

comment:38 Changed 11 years ago by Julien

  • Resolution set to fixed
  • Status changed from assigned to closed

commit done in the trunk, r1187

comment:39 Changed 11 years ago by laurentj

  • Documentation needed set

comment:40 Changed 11 years ago by laurentj

  • Documentation needed unset
Note: See TracTickets for help on using tickets.