Quand de bonnes idées sont proposées et que Laurent dit, à demi mot, qu'un patch est le bienvenue, si vous ne vous sentez pas de le faire vous même, il ne faut surtout pas hésiter à déposer vos demandes (features requests) soit sur GitHub avec "une issue" soit sur Developer.jelix.org.

Ainsi les idées ne restent pas dans "les cartons" (aka sur "le forum") et dès qu'on a du temps on s'y colle.

Nota : évitez de ne mettre QUE le lien du forum dans le ticket/issue pour votre demande. Reformuler plutôt la demande comme votre premier "post" et mettez y (si vous y tenez) le lien du forum en fin de ticket si le thread est long.

En ce moment, je suis particulièrement occupé sur d'autres projets (clients), et qui ne sont, malheureusement pour Jelix, pas en rapport avec le framework.

Suite à un bon mois et demi "d'absence", je ne peux faire que le constat suivant : quasi aucune contribution. Du coup, le projet ne semble pas avancer. D'ailleurs, depuis cet été, depuis l'extérieur, il ne semble pas avancer même si ce n'est pas vrai. La mise en place d'un nouveau serveur, d'un nouveau design pour le site, des améliorations dans le forum et d'autres tâches "qui ne se voient pas", ont occupé la majeure partie du temps que je pouvais consacrer au projet ces derniers mois.

Même si le nombre de téléchargement a doublé en un mois (conséquence probable de la mise en ligne du nouveau design \o/ ), cette faible activité autour du projet commence à devenir décourageante (pour moi en tout cas).

J'ai donc besoin de votre aide.

La bonne nouvelle est que rien n'est perdu, il y a de l'espoir . En effet, vous êtes là ! *tout le monde peut contribuer*, à quelque niveau que ce soit !

Que ce soit 20min ou 2h par semaine, contribuer peut signifier :

• bien entendu, proposer des patchs, du code
• faire des retours sur l'utilisation du framework, poster des tickets
• aider à répondre dans les forums
• proposer des idées d'évolutions
• améliorer la documentation, les tutoriaux etc (rappel, la majeure partie du site est un wiki !)
• contribuer au développement du site, tant au niveau code qu'au niveau design, marketing...
• aider à la mise en place d'outils supplémentaires qui pourraient nous aider à avancer plus vite, à faciliter la vie des utilisateurs et contributeurs (par exemple : un dépôt pear, un jenkins pour l'intégration continue, un nouveau bug tracker etc)
• proposer des news à mettre en ligne
• faire de "l'évangélisme", du marketing...
• organiser des rencontres d'utilisateurs (autour d'une bière par exemple )
• améliorer l'organisation du projet, faire des retours sur l'organisation du projet

à ce propos, il y a certainement des choses (en dehors du manque de temps), qui peuvent rebuter un utilisateur à contribuer. Faites moi part de toutes ces choses que vous n'aimez pas dans le fonctionnement du projet, dans les outils mis en place, dans le site, etc, voir même peut être aussi dans notre manière d'agir. Dites-moi ce qui vous empêche de contribuer. Soyez franc. Qu'est ce qui serait motivant pour vous pour contribuer, vous qui utilisez le framework. Ou encore avez vous des idées pour attirer les contributeurs ?

J'attends vos réponses avec impatience Le projet a besoin de vous ! Devenez acteur du projet ! (ne serait-ce qu'en répondant à ce post )

Merci d'avance,

Laurent

Dorénavant, je vais privilégier la mailing list pour annoncer les avancements du projet, demander votre avis sur certaines choses, discuter des nouvelles fonctionnalités etc..

Abonnez-vous !

Je voulais vous parler d’un sujet qui me tient à cœur concernant les évolutions de Jelix, en particulier la modularisation de jForms. Pensez-vous qu’il serait utile de continuer à modulariser ce composant pour le rendre plus souple et facile à intégrer dans différents projets ? Ou au contraire, cela risquerait-il de compliquer inutilement le framework et sa maintenance ?

J’aimerais beaucoup avoir vos retours d’expérience et vos idées à ce sujet. Peut-être que certains d’entre vous ont déjà testé des approches différentes ou ont des suggestions pour améliorer jForms.

Pour ceux qui souhaitent mieux comprendre les composants de Jelix et leurs possibilités, la documentation officielle est très bien faite et accessible ici : https://docs.jelix.org/fr/manuel

Merci d’avance pour vos contributions, cela pourrait vraiment aider à faire avancer le projet Jelix ensemble.

Premier message dans le forum j'ai le trac... ^^

J'ai créé avec la ligne de commande un contrôleur DaoCrud pour administrer la table "objets" dans le backend de mon application (master_admin). J'ai un paramètre supplémentaire "rubrique" que je passe dans mon url, qui me permet de n'afficher dans la liste que les objets appartenant à une certaine rubrique (j'ai mis un lien pour chaque rubrique dans le menu).

Je dois propager ce paramètre dans toutes les étapes de la navigation. Par exemple, quand on visualise un objet puis que l'on clique sur le lien "retour à la liste", on doit revenir à la liste filtrée sur la rubrique.

J'ai pu propager ce paramètre dans tous les cas sauf dans un cas : L'utilisateur crée ou édite un objet, fait une erreur dans le formulaire (par exemple il ne remplit pas un champs required), arrive finalement à compléter son formulaire et le valide. J'ai du rajouter et appeler une fonction dans le fichier jControlleurDaoCrud.class.php :

class jControllerDaoCrud extends jController {
    
     ...

    /**
     * save data of a form in a new record
     */
    function savecreate(){
        $form = $this->_getForm();
        $rep = $this->getResponse('redirect');
        if($form == null){
            $rep->action = $this->_getAction('index');
            return $rep;
        }
        $form->initFromRequest();

        if($form->check() && $this->_checkData($form, false)){
            $results = $form->prepareDaoFromControls($this->dao,null,$this->dbProfile);
            extract($results, EXTR_PREFIX_ALL, "form");//use a temp variable to avoid notices
            $this->_beforeSaveCreate($form, $form_daorec);
            $form_dao->insert($form_daorec);
            $id = $form_daorec->getPk();
            $rep->action = $this->_getAction('view');
            $rep->params['id'] = $id;
            $this->_afterCreate($form, $id, $rep);
            if ($this->uploadsDirectory !== false)
                $form->saveAllFiles($this->uploadsDirectory);
            jForms::destroy($this->form);
            return $rep;
        } else {
            $rep->action = $this->_getAction('create');



            // J'ai besoin d'un point d'entrée dans la fonciton ici
            // pour pouvoir modifier la réponse !
            $this->_afterCreateCheckFailed($form, $id, $rep);__



            return $rep;
        }
    }

    // le nouveau point d'entrée ...
    protected function _afterCreateCheckFailed($form, $id, $resp) {__
    }

    ...
}

(Et similairement pour l'update bien sûr)

Et maintenant je peux utiliser ce point d'entrée pour propager ma rubrique convenablement :

class objetsCrudCtrl extends jControllerDaoCrud {
    ...
    protected function _afterCreateCheckFailed($form, $id, $resp) {
    	$resp->params['rubrique'] = $this->param('rubrique');
    }
    ...
    protected function _afterUpdateCheckFailed($form, $id, $resp) {
    	$resp->params['rubrique'] = $this->param('rubrique');
    }
    ...
}

Je pense avoir eu la bonne démarche, votre avis ?

Si oui, je pense que ça mérite un patch.

merci !

Lionel :)

voici un plugin tpl pour ajouter les metas twitter. (toutes gérées, cf: https://dev.twitter.com/docs/cards/validation/validator)

Script à placer dans /votre_app/plugins/tpl/html/

Le lien : Plugin tpl meta Jelix

à utiliser de cette façon : (remplacer le ":" par des "_")

{meta_twitter card 'summary'}

{meta_twitter image_src 'url de image'}

etc..

cas particulié pour la meta player:stream:content_type :

{meta_twitter player_stream_content__type 'content'}

Aussi, chaque meta peux accepter un tableau (je l'ai mis sur tous au cas ou)

{meta_twitter player_stream_content__type 'video/mp4', array( 'codecs' => 'avc1.42E01E1, mpa.40.2')}

Voila, je post bientôt le même pour les metas Facebook & Open Graph

Je suis en train de développer un plugin pour jDb qui permet d'utiliser les queries asynchrones sur PostgreSQL. Il implémente les 3 fonctions PHP pg_send_query, pg_connection_busy et pg_get_result.

En ouvrant plusieurs connexions, cela vous permet de lancer plusieurs requêtes parallèlement sur PostgreSQL et donc d'utiliser tous les CPU de votre serveur de base de données pour accélérer le temps de traitement.

Quel est le meilleur moyen pour en faire profiter la communauté Jelix ?

Yannick.

Je suis en train de tester avec un projet perso les nouvelles possibilités de jelix concernant les formulaires. Avec la future version 1.5, il est possible de créer des plugins d'affichage des contrôles jForms (par exemple créer un plugin autocomplete, ou mapSelector, ou autre ...).

Ca c'est pour le point d'étape, maintenant la suite.

Les prochaines actions évidentes sont pour moi de :

• permettre aux plugins d'embarquer leurs fichiers CSS et JS
• permettre aux plugins de fournir leur propre check JS (modulariser le fichier jQuery_jForms pour être clair)
• permettre au plugin de définir sont propre jDatatype (je pense par exemple à un jDatatypeGPS, ou jDatatypeSIRET)

Ma question en filigranne c'est où arrêter la modularisation de jForms ? Les avantages de la modularisation sont :

• simplifier énormément l'ajout de nouveau contrôle de saisie
• simplifier le passage à HTML5 (en comblant les lacunes avec Modernizr)
• simplifier le core de jelix

Les inconveniants de la modularisation sont :

• plus de risque de collision JS/CSS
• temps de chargement plus long (plus de fichiers JS et CSS différents à charger sur le client)

Des avis ?

<method name="getResByRightByGroup" type="select">
            <parameter name="group" />
            <parameter name="subject" />
            <conditions >
                <eq property="id_aclsbj" expr="$subject" />
                <eq property="id_aclgrp" expr="$group" />
                <neq property="id_aclres" value="-" />
            </conditions>
        </method>

Exemple d'utilisation: J'affiche une liste des utilisateurs mais tout le monde n'a pas le droit de voir tout les types d'utilisateur... Dans mes ressources je place le "literal_id" de mes types d'utilisateur (_student, _prof, _admin).
Au moment de lister j'ai juste à voir les ressources que l'utilisateur à le droit de lister (bien sur après avoir vérifié qu'il a le droit de lister de base)! Ça me permet d'ajouter dynamiquement les types d'utilisateurs au système plutôt que d'aller modifier à chaque fois mon code en dur...
Qu'en pensez vous?

On pourrait même ajouter une méthode dans jAcl2 du genre getResByRightByGroup... Ça éviterai de devoir ré-instancier une factory à chaque fois ($jacl2dbFactory = jDao::get('jacl2db~jacl2rights');$arRes = $jacl2dbFactory->getResByRightByGroup('admins','bdc.commission.choose');).

J'ai intégré (pour test et par besoin) la version 1.9 de jquery ui dans l'arborescence jelix. Après quelques adaptations, l'ensemble fonctionne bien... Par contre, je me pose la question de la source qui est utilisée pour la version native de Jelix, car je n'ai pas la même arborescence et certains fichiers n'ont pas le même nom (*.effects.*.js par exemple).

Je voudrais connaître la version téléchargée par Philippe Villiers afin d'être un minimum en phase dans mes expérimentations.

Merci d'avance

Cordialement
Denis

Je tente de soumettre un patch pour http://jelix.org/forums/forum/6-jelix-contributions-et-evolutions/posts/10049-9145-utiliser-les-commentaires-mysql-pour-les-labels-jforms

J'ai fais un git clone, puis j'ai récupéré le fichier d'exemple de build.ini sur cette page : http://developer.jelix.org/wiki/fr/sources#G%C3%A9n%C3%A9reruneversiondetravail

Quand je lance buildjelix.php, j'obtiens bien les sources dans le répertoire tests mais j'ai aussi :

warning: unknown option name (ENABLE_PHP_FILTER) in the ini file
warning: unknown option name (ENABLE_PHP_JSON) in the ini file
warning: unknown option name (ENABLE_PHP_XMLRPC) in the ini file

Ensuite, quand j'essaye de générer testapp ça ne fonctionne pas (rien dans mon répertoire tests)

warning: unknown option name (APPNAME) in the ini file

Bref, pas facile quand c'est dur

Il me reste juste l'étape de test avec testapp pour proposer mon patch.

Merci

Je me disais qu'il pourrait être sympathique que la commande "createform" utilise les commentaires SQL pour les labels des champs.

Exemple : `dateenvoi` timestamp NULL DEFAULT NULL COMMENT 'Date envoi',

Ceci impliquerait un nouvel attribut "comment" dans les descriptions des champs dans les fichiers DAO et la modification des scripts createdao et createform

Sur une instance jelix 1.3, j'ai modifié un chouilla les fichiers suivants (commentaire YVES) :

./jelix-scripts/commands/createform.cmd.php

            // YVES                                                                                                                                                                                                      
            if(isset($property->comment) && $property->comment!='') {
                if ($this->getOption('-createlocales')) {
                    $locale_content .= 'form.'.$name.'='.$property->comment."\n";
                    $content.="\n\n<$tag ref=\"$name\"$attr>\n\t<label locale='".$locale_base.$name."' />\n</$tag>";
                } else {
                    $content.="\n\n<$tag ref=\"$name\"$attr>\n\t<label>".$property->comment."</label>\n</$tag>";
                }
            } else {
                if ($this->getOption('-createlocales')) {
                    $locale_content .= 'form.'.$name.'='. ucwords(str_replace('_',' ',$name))."\n";
                    $content.="\n\n<$tag ref=\"$name\"$attr>\n\t<label locale='".$locale_base.$name."' />\n</$tag>";
                } else {
                    $content.="\n\n<$tag ref=\"$name\"$attr>\n\t<label>".ucwords(str_replace('_',' ',$name))."</label>\n</$tag>";
                }
            }
            /*if ($this->getOption('-createlocales')) {
                $locale_content .= 'form.'.$name.'='. ucwords(str_replace('_',' ',$name))."\n";
                $content.="\n\n<$tag ref=\"$name\"$attr>\n\t<label locale='".$locale_base.$name."' />\n</$tag>";
            } else {
                $content.="\n\n<$tag ref=\"$name\"$attr>\n\t<label>".ucwords(str_replace('_',' ',$name))."</label>\n</$tag>";
            }*/
            // END YVES

./jelix/plugins/db/mysql/mysql.dbtools.php

        // YVES
        //$rs = $this->_conn->query ('SHOW FIELDS FROM `'.$tableName.'`');
        $rs = $this->_conn->query ('SHOW FULL FIELDS FROM `'.$tableName.'`');
        // END YVES

./jelix/dao/jDaoProperty.class.php

    // YVES
    public $comment = null;
    // END YVES

    /**
    * constructor.
    * @param array  $attributes  list of attributes of a simpleXmlElement
    * @param jDaoParser $parser the parser on the dao file
    * @param jDbTools $tools
    */
    function __construct ($aAttributes, $parser, $tools){
        // YVES => Ajout de "comment" dans le tableau
        $needed = array('name', 'fieldname', 'table', 'datatype', 'required',                                                                                                                                            
                        'minlength', 'maxlength', 'regexp', 'sequence', 'default','autoincrement','comment');

        $params = $parser->getAttr($aAttributes, $needed);

        if ($params['name']===null){
            throw new jDaoXmlException ($parser->selector, 'missing.attr', array('name', 'property'));
        }
        $this->name       = $params['name'];

        if(!preg_match('/^[a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*$/', $this->name)){
            throw new jDaoXmlException ($parser->selector, 'property.invalid.name', $this->name);
        }

        // YVES
        if(!empty($params['comment'])) {
            $this->comment  = $params['comment'];
        }
        // END YVES

Et ça fonctionne.

Qu'en pensez-vous ?

Je ne sais pas si mon titre est bien clair, mais en ce début de semaine j'ai enrichi un tout p'tit peu le framework sur jForms en codant ce qu'il faut pour que dans un fichier xml de formulaire, je puisse déclarer une balise time.

J'avais besoin d'avoir l'affichage seulement de listes déroulantes ou d'input pour renseigner les heures et les minutes sur un formulaire d'ajout d'événement (agenda). Datetime ne correspondait pas vraiment à mes besoins puisqu'il affiche date + heure, du coup j'ai mis en place une nouvelle balise pour le fichier de formulaire xml qui s'appel time et que l'on peu même agrémenter d'un attribut "interval" qui permet de définir l'interval entre les minutes que l'on souhaite avoir à l'affichage. Ex : 15 -> 00, 15, 30, 45 Ou 30 -> 00, 30

Par contre fonctionnalité que je n'ais pas mis en place, c'est un timepicker, par manque de réalité concrête d'utilité car finalement avec des listes déroulantes un timepicker me semble lourd pour un accès rapide à l'information. Cela reste mon point de vue bien évidemment.

Je me dit que cela pourrait être utile à d'autres, déjà d'une part, et que cela serait peut être dommage de devoir recoder cette fonctionnalité à chaque changement de version. C'est pourquoi je vous propose mon modeste travail, qui sera sans doute à corriger un chouille, sur le forum n'étant pas du tout familière des processus d'ajout de contribution.

Bonne journée !

Muirgen

Je vais sortir la 1.4 beta ce week end. Je fignole d'abord un patch pour avoir les paramètres automatique de lang dans les urls

Voici un petit moment que je travaille sur un plugin jquery pour Leaflet.js, un outil de manipulation de cartes à la google map. Aussi aujourd'hui je me suis amusé (un petit peu moins au bout de quelques heures ...) à intégrer ce plugin dans l'admin jelix, pour pouvoir créer des cartes avec quelques clics, dans le but d'intégrer ces cartes à des forum, pages de blog, wiki, profil d'utilisateurs, et j'en passe.

Voici une démo (login:demo; password:demo)

Pour le moment, c'est une version très minimale, seulement l'ajout de marqueurs est fonctionnel (lorsque l'on clique sur la map pendant l'édition), mais je compte bien m'attaquer au reste un peu plus tard ... il faut juste retenir que ce module est une version d'essai, qui n'attend que vos commentaires.

Donc si vous avez des avis, remarques ou autre, n'hésitez pas.

Guillaume

Du coup :

• soit j'ai raté un épisode et on peut forcer la valeur "nulle" d'une liste à n'importe quel valeur (je parle bien de la valeur, pas du libellé de l'option!!) :

<option value="cequonveut"> libellé option nulle </option>

• soit il faudrait modifier le "coeur" de jelix pour changer dans la méthode "outputMenulist" ligne 633 :

if ( $ctrl->emptyItemLabel!==null )
echo '<option value=""',($value===''?' selected="selected"':''),'>',htmlspecialchars($ctrl->emptyItemLabel),"</option>\n";

sachant que ce serait un retour en arrière sur cette modif : https://bitbucket.org/julieni/jelix-trunk-patches/src/128b1c3f30f5/jForms-menulist-should-have-empty-item-even-when-required.patch Sauf que ma modification permet de laisser le fonctionnement actuel tel quel pour ceux qui veulent un emptyItemLabel dans leur liste déroulante. Et pour ceux qui comme moi n'en veulent pas ben on l'indique en mettant "null" dans la propriété emptyItemLabel, tout simplement.

Mon morceau de code qui utiliserait la 2ème option :

$tab = array( "0" => "inconnu", "1" => "valeurA", "2" => "valeurB", );
$menulistctrl = new jFormsControlMenulist('monchamp');
$menulistctrl->emptyItemLabel=null; // Ici je précise que je veux pas d'option vide dans ma liste déroulante, car je gère déjà une ligne "inconnu" dans le tableau fourni
$menulistctrl->required = true;
$menulistctrl->datasource = new jFormsStaticDatasource();
$menulistctrl->datasource->data = $tab;
$form->addControl($menulistctrl);

Pour être encore plus clair, jelix génère ça :

<select name="monchamp" id="jforms_module_tble_monchamp" class="jforms-ctrl-menulist jforms-required" size="1">
<option value=""></option>
<option value="0">inconnu</option>
<option value="1">valeurA</option>
<option value="2">valeurB</option>
</select>

Alors que je voudrais avoir ça :

<select name="monchamp" id="jforms_module_tble_monchamp" class="jforms-ctrl-menulist jforms-required" size="1">
<option value="0">inconnu</option>
<option value="1">valeurA</option>
<option value="2">valeurB</option>
</select>

Avec quelques amis, nous nous sommes lancé dans la création d'une application web avec une composante forte "réseau social".

Nous souhaitons simplifier l'authentification/enregistrement en proposant un "import" et une "connexion" via Facebook/Twitter/G+ tout en autorisant l'utilisation de jCommunity (certaines personnes n'ont pas de compte social).

Nous pensons prendre jCommunity et y ajouter les "plugins sociaux" ainsi qu'une gestion d'invitation peut être.

A chaud, vous le sentez comment ?

FROM products AS p LEFT JOIN manufacturers AS man ON (p.id_manufacturer = man.id),  categories AS cat WHERE cat.id_cat = man.id_cat

Il suffirait d'ajouter une propriété comme "onforeigntable" aux balises <foreigntable> et <optionalforeigntable>.

Serait-t-il possible d'intégrer cette fonctionnalité à jDao pour la version 1.3 de Jelix ?

Merci d'avance !

J'ai dernierement cherché a voir les compétances des autres frameworks et à ma grande surprise, je me suis rendu compte qu'il on a beaucoup qui viennent d'arrivé.

Il sont puissant, rapide et jouissent d'une tres bonne structrue.

Entre nous on sait que Jelix se fait vieux. Il a besoin soit d'un lifting ou une mega-morphose ou bien meme que le jelix devient un Phenix. Comme Copix l'a été auparavant.

Pourquoi ne pas reprendre les meilleur composants des autres framework et prendre ca comme base?

Il y a beaucoup de technologie qui sont disponible maintenant.

Tel que

• facebook Big Pipe
• facebook HipHop (Ca peut aller dans la direction de jelix avec ca version GOLD)

En developement des modules entierement indépendant et on compile avec facebook HipHop on peut obtenir des performances du langage C en profitant de la simplicité de PHP en plus ca reste juste une option le frame work peut toujours rouler avec le 100% code php.

Il y a beaucoup de developpement et de bonne idée dans les autres framework.

Ce qu'on a pas besoin de réinventé:

• moteur de templates
• Router
• ORM
• Profiler
• MVC

on a simplement a extraire les meilleurs code des autres et l'intégrer chez nous.

Bon ca c'est mon idée, et c'est sur ca que je vais travailler. Dites moi ce que vous en pensez et si vous etes intéressé.

On va essayer de sortir des versions plus souvent. Cependant, au bout d'un moment, on va se retrouver avec énormément de version à maintenir, si on garde un support aussi long qu'avec les versions précédentes.

Pour rafraichir les souvenirs :

• le support de la 1.0 a duré 32 mois.
• le support de la 1.1 va se terminer le mois prochain, se qui correspondra à 36 mois (3 ans)

si on maintient à 36 mois pour les versions stables actuelles, le support de la version 1.2 se terminera en décembre 2013, et celui de la 1.3 en octobre 2014 (voir decembre 2014 pour faire "rond").

Pour la 1.2 et 1.3, sauf si vous pensez qu'on peut faire plus court, je propose de les maintenir à 36 mois. Cela reste donc des "LTS" (long term support).

Et pour les suivantes, je propose que le support soit ramené à 1 an, et que la dernière de chaque année soit une LTS (3 ans).

Si par exemple on arrive à sortir cette année une version 1.4, 1.5, 1.6 : 1.4 et 1.5 seront maintenues pendant 1 an. Et la 1.6, 3 ans.

D'après mes calculs, avec 3 nouvelles versions par an, cela fait au maximum 4 branches maximum à maintenir en même temps.

On essaierai donc de sortir des versions tout les 4 mois : avril, aout, decembre.

Cela vous conviendrait-il ?

Laurent

Je me demandais s'il était prévu, dans une prochaine évolution, la modification de l'API des DAOs, en vue d'une syntaxe plus "simple" et plus courante (utilisée généralement par les autres frameworks).

À savoir, par exemple, si on souhaite modifier un enregistrement issu d'une table foo :

$record = new Foo(id);
$record->myField = "toto";
$record->save();

Je trouve cette syntaxe beaucoup plus intuitive. On applique ici, directement sur l'objet record, les méthodes insert(), update(), delete() ou save();

Bien-sûr, la première ligne est à adapter, pour permettre l'emploi des sélecteurs propres à Jelix, ce qui deviendrait, par exemple :

$foo = DaoFactory::get(myJelixSelector);

ou, si vous comptiez utiliser les namespaces :

$foo = new my/name/space/Foo();

Pour retourner un ensemble d'enregistrement, on pourrait avoir :

$foo = new Foo();
$records = foo->findAll();

Ou, avec la nouvelle syntaxe qui sera proposée par PHP :

$records = new Foo()->findAll();

Merci pour votre réponse.

je pense que la version Standalone du moteur de template ne suit pas forcément les évolutions du moteur de template packagé dans Jelix, mais il y a un petit bug bien génant sur les balises {meta}.

Dans la doc de la version packagée et de la version standalone, il est dit qu'on peut récupérer un tableau de ces metas.

Hors, si c'est bien le cas pour la version packagée, ce n'est pas le cas pour la version standalone : il manque return $this->_meta; à la fonction meta de la classe jTpl du fichier jTpl.class.php.

Pour l'instant, on peut y accéder à travers $tpl->_meta[].

Je crois que ce sujet à déjà été parleé une fois, mais je retrouve plus le topic, juste le ticket => http://developer.jelix.org/ticket/1423

De pouvoir appliquer des filtres sur les champs jForms afin de préparer les données.

Je crois qu'il y a déjà "trim" qui est prévu, le système pourrait être amélioré en proposant d'autre filtre, en s'inspirant de Codeigniter http://codeigniter.com/user_guide/libraries/form_validation.html#preppingreference

Exemple: trim, strip_tags, et d'autre fonction à définir.

Je verrais une syntaxe de ce genre pour jForms:

<input ref="name" required="true" filter="trim|strip_tags"> // Ou rules="trim|..."
    <label>Name</label>
</input>

Ou alors une nouvelle syntaxe de ce genre avec un ordre:

<input ref="name" filter="trim|strip_tags|required|valid_email">

En prenant en compte l'odre des filtres, il y aurait plus de problème de ce genre: http://developer.jelix.org/ticket/1401

Et bien sur aussi la possibilité d'avoir nos propre filtre pour jForms.

Qu'en pensez-vous? jForms est vraiment pas mal, mais il pourrait être amélioré en ajoutant des petit détails qui manquent et qui prend vite du temps de gérer "à la min".

Merci à Laurent et aux contributeurs qui font de jelix un incontournable, robuste, efficace et simple framework php à prendre en main. Notamment de par sa conception et sa documentation et tout ce qui fait que Jelix est Jelix.

L'objet de mon post est de proposer l'amélioration de la classe de gestion du CRUD (lib/jelix/controllers/jControllerDaoCrud.class.php) :

Afin de permettre la propagation de paramètres d'url aux différentes actions. Notamment par exemple pour gérer l'ordre asc ou desc d'une colonne de la liste affichée dans le CRUD à l'ensemble des actions create, update etc... et de se retrouver au même endroit dans la liste (avec le bon classement sur la bonne colonne et la bonne page et pas revenir sur la bonne page avec perte de l'odre de tri et de la colonne impliquée dans le tri), d'où que l'on vienne depuis n'importe qu'elle action du CRUD (apres un create, un view, un update).

Il conviendrait de :

• changer la signature de :

protected function _preCreate($form)

en protected function _preCreate($form, $resp)

• changer la signature de :

protected function _preUpdate($form)

en protected function _preUpdate($form, $resp)

• dans la fonction precreate() changer l'ordre de :

...
$this->_preCreate($form);

$rep = $this->getResponse('redirect');

...

en (avec en plus l'ajout du parametre $rep à l'appel de _preCreate())

...
$rep = $this->getResponse('redirect');

$this->_preCreate($form, $rep);

...

• Modifier l'appel dans preupdate() de

$this->_preUpdate($form);

en $this->_preUpdate($form, $rep);

Pour les autres fonctions _index ou autre, on peut agir directement sur le $tpl (template) passé en paramètre de la fonction en recuperant dans un premier temps les paramètres d'url puis en assignant ces valeurs de paramètre d'url aux variables adhoc du template.

En espérant que ces propositions puisse être intégrées.

Cordialement e-media