Situation:

• Using a <checkboxes> element with the required attribute
• Submitting the form without ticking any item of the <checkboxes>

Error:

• No javascript error telling that the element is required

Working:

• server-side check is working and we have the error message telling that we must tick and item

Quand je valide certaines données a la main et que j'assigne 2 erreurs

$form->setErrorOn('url_site', 'mauvaise url');
$form->setErrorOn('url_site', 'site down');

seul la dernière erreur s'affiche.

Plutôt que d'avoir un plugin de template qui gère tout ce qui est image, on devrait avoir une classe faisant tous les traitements qui serait appelée par le plugin.

Cela permettrait par exemple de créer le cache des photos à leur upload. Utile si on charge une page contenant 100 photos de 5mo chacune. (PHP renverra un out of memory bien avant ça..)

Implémenter un système de stockage dynamiques de préférences/paramètres d'applis et de modules. voir http://developer.jelix.org/wiki/fr/drafts/preferences

it can be cool if pagelinks have a default css link like

ul.pagelinks {
    list-style-type: none;
}
ul.pagelinks li {
    float: left;
    padding: 0 3px;
}

or something like that.

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

It could be very powerfull if we could only redefine 1 string for locale en_US, and let Jelix do some kind of merging whith the locale en_EN.

Same idea for overloaded locales in the "overload" directory of modules. Would be very nice to be able to overload just 1 string and not the full file.

Mix both cases and you have this : en_US (overloaded) > en_US (original) > en_EN (overloaded) > en_EN (original).

If everything fails, we have an exception like today.

Is this a good enhancement ?

I have 2 methods for doing this :

1. trying to get the locale recursively and returning it when found.

2. at compilation/caching time, some kind of merging is done and all files (for every locale, original or overloaded) have the full set of strings inside.

Method 2 should be more efficient in production use, because compilation/caching should only be done once, but this compilation/caching process will be more heavy. It also seems simplier to code.

Which method should I choose (please don't answer "both and we'll see" ;) )

Sometimes, on a web site, sessions are not required, or only when a module would like to store something in it. So, for some visitors, sessions are created even if it is not used. This is a perf issue : it creates a file or a record which is not useful.

We could have jSession::get($varname) and jSession::set($varname, $value) to read or save session variables. So we use them instead of using directly $_SESSION, and there isn't a session_start systematically.

session_start is called only when calling jSession::set. When we call jSession::get, it should detect if there is a cookie of session. If yes, it execute session_start and return the value from $_SESSION, else it just returns null or "". (of course session_start is called only one time during the execution of an action).

A propos des zones et quoi qu'il en soit dans le détail que je ne connais pas encore.

Pour moi, quoi qu'il en soit, les choses question cache se résument en deux mots:

• un client émet une requête GET
• du contenu correspondant à cette requête est renvoyé avec un code OK, ou un NOT MODIFIED sans contenu, ce contenu étant déterminé par un certain nombre de paramètres "contenu administrateur" et "temporels".

Un système de cache côté client n'a donc qu'une question à se poser: le cache client mérite-t-il d'être rafraichi?

Côté serveur, il y a deux approches à mon avis:

• soit, dès lors que l'on modifie "quelque chose" qui change le contenu renvoyé par une (des) requêtes GET particulière, il faut effacer le(s) cache(s) correspondant(s).
• soit, on stocke dans la version cache l'ensemble des paramètres qui déterminent le contenu, plutôt qu'un hash du contenu généré.

Je n'ai rien contre les hashs, mais bon... A mon sens, il n'y a pas que la performance à prendre en compte (quand bien même il me parait certain que vérifier quelques paramètres est plus rapide que générer le contenu correspondant), mais la cohérence du bazar: ça n'a aucun sens de re-générer mille fois le même contenu...

- dMp

jelix devrait fournir des outils pour installer, desinstaller un module. Voir fr/drafts/gestion_modules

Ce ticket correspond à une première étape : il s'agirait simplement de lire le contenu d'un répertoire install d'un module déjà copié dans l'application, et d'executer les scripts sql et autres pour activer le module. (et l'inverse pour le desinstaller/désactiver)

There is a bug in the parser code for the forums that put back to left the first line of a preformated code (obtained by indenting text). Perhaps some "trimleft" all write space instead of justing deleting the first linefeed?

e.g the following expected lines:

   line1
   line2
   line3

appear as if there were typed as:

line1
   line2
   line3

Ce plugin permet d'ajouter un tpl dans un autre, sans passer par le contrôleur. le template ajouter hérite des variables de sont contenant.

exemple :

<p>
   Vous pouvez me joindre a cette adresse
   {note 'main~adresse'}
</p>

<p>
   Vous pouvez me joindre a cette adresse
   20, rue de la folie
   45963 furieuse les bains
   France
   06xxxxxx22
</p>