Re: [Dotclear Dev] Tableau par référence ou par valeur
by Kévin Lepeltier
J'ai fait un plugin qui permet de modifier l'ordre des billets avec des
règles assez complexe (basé sur une table annexe). De mémoire je surchargé
les paramètre de tri directement dans le tempête compiler, par écrasement.
Je suis pas sur faut que je vérifie. Mais en tous cas j'ai réussi, alors tu
dois pouvoir le faire.
--
Kevin
Le 18 nov. 2011 19:38, "Kévin Lepeltier" <kevinlepeltier(a)gmail.com> a
écrit :
> J'ai fait un plugin qui permet de modifier l'ordre des billets avec des
> règles assez complexe (basé sur une table annexe).
> De mémoire je surchargé les paramètre de tri directement dans le tempête
> compiler, par écrasement.
> Je suis pas sur faut que je vérifie.
> Mais en tous cas j'ai réussi, alors tu dois pouvoir le faire.
>
> --
> Kevin
>
> Le 18 nov. 2011 15:49, "Franck Paul" <carnet.franck.paul(a)gmail.com> a
> écrit :
>
> Le 18 novembre 2011 15:47, Dsls <dsls(a)morefnu.org> a écrit :
> >> Sauf que dans le cas qui me préoccupe, la variable $params n'est qu'un
> >> simple array(). De plus je viens de m'apercevoir que j'ai au passage
> >> oublié de mettre à jour le $_ctx->post_params au retour de l'appel du
> >> behaviour, ce qui pourrait également provoquer des effets de bord.
> >
> > Note que rien n'empêche, juste avant de faire l'appel au behavior, de
> faire un :
> > $params = new ArrayObject($params);
>
> En effet, mais ça veut dire modif du core et que je remets illico mon
> ploug dans son placard jusqu'à la fois suivante. Donc à tout prendre
> je vais voir ce qui ressort de la discussion que tu as initiée sur la
> ML pour reprendre ensuite mon code.
> _______________________________________________
> Dev mailing list
> Dev(a)list.dotclear.org
> http://ml.dotclear.org/listinfo/dev
>
>
>
11 years, 11 months
Re: [Dotclear Dev] Merge filterforms/default - tri des colonnes
by tbouron@gmail.com
Tiens d'ailleurs question: le tri doit être persistant?
------Original Message------
From: Dsls
Sender: dev-bounces(a)list.dotclear.org
To: dev(a)list.dotclear.org
ReplyTo: dev(a)list.dotclear.org
Subject: [Dotclear Dev] Merge filterforms/default - tri des colonnes
Sent: Jul 4, 2011 09:44
Hello,
Je pense avoir une version stable des filtres de formulaire de liste.
Thomas, tu penses avoir un tri sur les colonnes sous peu ? J'envisage
de faire le merge avec la branche default sous peu.
--
Bruno
_______________________________________________
Dev mailing list
Dev(a)list.dotclear.org
http://ml.dotclear.org/listinfo/dev
12 years, 1 month
Nouveau commit / urlhandlers
by Dsls
Hello,
Suite à la discussion initiée par adjaya sur le forum
(http://forum.dotclear.org/viewtopic.php?id=45666), j'ai commité ce
matin un petit tuning sur la gestion des URL publiques d'un blog,
ainsi que les behaviors qui vont bien.
Ainsi, pour "afficher" une URL publique, un plugin utilisait en
général $core->blog->url.$core->url->getBase($type)."/".[id de l'item
qui suit].
Pour harmoniser le tout, les plugins pourront désormais utiliser
$core->url->getURLFor($type,[id de l'item]) , le second paramètre
étant facultatif.
Il est alors possible de surcharger le tout via le nouveau behavior
publicGetURLFor. Un plugin pourra ainsi changer à l'envi les URLs
qu'il souhaite.
Ce behavior a son pendant côté parsing de l'URL. Il est ainsi possible
de jouer sur l'enregistrement auprès de l'URLHandler en amont, et plus
seulement a posteriori.
Le behavior publicRegisterURL permet de modifier certains paramètres
des URLS enregistrées, avant leur enregistrement. Il prend comme
paramètre un tableau (par référence) contenant
$type,$url,$representation,$handler.
Ces derniers peuvent ainsi être modifiés avant l'appel à register
proprement dit.
Je regarderai ces prochains jours, et avant la prochaine release, si
certain micro-tunings de ce type sont encore réalisables à d'autres
endroits.
--
Bruno
12 years, 3 months
Distingo des classes "core" coté admin et public
by Dsls
Hello,
Gros sujet de réflexion sur les classes core de dotclear, et de leur
utilisation actuelle.
J'ai volontairement isolé certaines méthodes des classes dcBlog et
dcCore (voir en annexe).
Pour moi, les fonctions en question ne devraient pas être
disponibles/accessibles coté public du blog.
Il pourrait être intéressant d'avoir une instanciation différente
selon qu'on est coté
public ou coté admin du blog : coté public, on ouvre un sous-ensemble
de fonctionnalités
(des objets core et blog bridés en quelque sorte), et coté admin on
donne les objets complets.
Cela peut être mis en oeuvre de plusieurs façons. Exemple pour dcBlog :
* Un objet dcBlog épuré implémenté coté public, dont hérite un objet
dcBlogAdmin plus complet
* Un objet dcBlog complet coté admin, dont hérite un objet
dcBlogPublic qui surcharge les fonctions interdites
* Un objet dcBlog complet coté admin, et un objet "proxy" (au sens
design pattern du terme) utilisé en guise de
dcBlog coté public, le proxy contrôlant ce qui est appelable ou pas.
L'avantage du 3e cas est qu'on peut mettre les behaviors qu'on veut
avant et/ou après l'appel à des fonctions core et/ou blog.
Je conçois qu'aujourd'hui c'est assez abstrait et peut paraître
inutile, dans la mesure on on n'a pas vraiment besoin
de cette protection dans la gestion actuelle du moteur de template,
mais si on réfléchit un peu plus loin avec un nouveau moteur
de templates (twig pour ne citer que lui), offrir un objet dcBlog
"protégé" dans le contexte du template permettrait une grande
simplification de l'écriture de templates, et surtout une certaine
sécurisation à ce niveau.
A+,
Bruno
== Annexe ==
dcBlog :
public function __construct($core, $id)
public function addCategory($cur,$parent=0)
public function addComment($cur)
public function addPost($cur)
public function categories()
public function delCategory($id)
public function delComment($id)
public function delPost($id)
public function resetCategoriesOrder()
public function setCategoryParent($id,$parent)
public function setCategoryPosition($id,$sibling,$move)
public function
setPostContent($post_id,$format,$lang,&$excerpt,&$excerpt_xhtml,&$content,&$content_xhtml)
public function updComment($id,$cur)
public function updCommentStatus($id,$status)
public function updPost($id,$cur)
public function updPostCategory($id,$cat_id)
public function updPostSelected($id,$selected)
public function updPostStatus($id,$status)
dcCore :
public function __construct($driver, $host, $db, $user, $password,
$prefix, $persist)
public function addBlog($cur)
public function addFormater($name,$func)
public function addUser($cur)
public function checkNonce($secret)
public function countAllComments()
public function countBlogPosts($id,$type=null)
public function emptyTemplatesCache()
public function indexAllComments($start=null,$limit=null)
public function indexAllPosts($start=null,$limit=null)
public function initWikiComment()
public function initWikiPost()
public function initWikiSimpleComment()
public function setBlog($id)
public function setUserBlogPermissions($id, $blog_id, $perms,
$delete_first=true)
public function setUserDefaultBlog($id, $blog_id)
public function setUserPermissions($id,$perms)
public function setVersion($module,$version)
public function unsetBlog()
public function updBlog($id,$cur)
public function updUser($id,$cur)
public function userDefaults()
public function wikiPostLink($url,$content)
12 years, 4 months
Evolution des filtres customs dans les templates
by Dsls
Hello,
Autre sujet de réflexion : les filtres dans les templates, et leur
extensibilité.
Je parle de ces encode_html="1", et autres cut_string.
A l'heure actuelle, je les trouve assez mal conçus : il impossible
d'indiquer un ordre dans lequel les filtres sont appliqué, et il est
quasiment impossible d'ajouter des filtres customizés via un plugin
(via les behaviors public*ContentFilter).
Je propose de remplacer l'approche actuelle par un attribut unique "filters".
Par exemple, dans le post.html des templates par défaut, on a
actuellement dans le meta name="description":
{{tpl:EntryContent full="1" encode_html="1" remove_html="1" cut_string="180"}}
Cela deviendrait :
{{tpl:EntryContent filters="remove_html|encode_html|cut_string(180)"}}
=> On peut définir l'ordre des filtres, et on se rapproche de ce qu'on
trouve dans d'autres moteurs de templates niveau syntaxe...
--
Bruno
12 years, 4 months
Tableau par référence ou par valeur
by Franck Paul
'jour les gens,
J'ai un behaviour (dans class.dc.blog.php) qui ressemble à ceci :
$this->core->callBehavior('coreBlogBeforeGetPosts',$params);
Comment puis-je faire pour que la fonction appelée puisse modifier un
des éléments du tableau $params ?
Si je force le passage par référence avec un
$this->core->callBehavior('coreBlogBeforeGetPosts',&$params);
et/ou que j'indique que la fonction appelée attend une référence comme ceci
public static function coreBlogBeforeGetPosts(&$params)
ça gueule et me laisse perplexe.
Un avis éclairé sur le souci et éventuellement comment le régler ?
12 years, 4 months
Evolution de l'onglet "Maintenance", ticket #999 + question ouverte sur les configurations des plugins
by Dsls
Hello,
Quelques pistes concernant l'évolution de l'onglet Maintenance. Comme
indiqué dans le ticket 999, on a actuellement une section
"fourre-tout", pas forcément cohérente, et surtout pas extensible.
C'est pourtant un endroit judicieux que d'autres plugins pourraient
étendre...
On pourrait permettre aux plugins d'ajouter un onglet. Je suis assez
sceptique sur ce choix : on risque d'avoir plein d'onglets, ce qui
sera difficilement lisible par la suite. Je propose plutôt d'opter
pour une liste de liens en page d'accueil du plugin maintenance (façon
liste de billets), qui recense différentes sections de maintenance.
Question corolaire : on a aujourd'hui pas mal de plugins qui ajoutent
leur propre menu de configuration dans les items de gauche, ce ne
serait pas pertinent de mettre une section "option des plugins" à la
manière de maintenance, pour ne pas engorger le menu de gauche ?
--
Bruno
12 years, 4 months
Jquery & Cie
by Dsls
Re,
En regardant de plus près ce qu'on a aujourd'hui dans le core, et plus
précisément en essayant de réutiliser le jquery-autocomplete du plugin
tags, je me suis rendu compte que ce dernier était déprécié, voir ici
:http://bassistance.de/jquery-plugins/jquery-plugin-autocomplete/
Cela ouvre (ou plutôt, rouvre) la question de l'obsolescence des libs
autour de jquery, en particulier autocomplete et datepicker. Ces
dernières sont maintenant fournies avec jquery UI.
Je crois qu'on avait eu un consensus sur un passage complet à jquery
UI il ya quelques temps, une migration est donc à prévoir. Questions
corolaires :
* jquery ui vient avec des thèmes (http://jqueryui.com/themeroller/),
notamment pour le datepicker: en choisit-on un dans la liste fournie ?
crée-t-on un thème spécifique "dotclear4jqueryUI ? (La page citée
précédemment permet de customiser le thème)
* jquery UI permet de télécharger un "bundle" (ie. tous les js jquery
UI en un seul .min.js). On intègre les sources non minifiés dans le
hg, et on génère le .min.js au build ? A noter, on a déjà un jquery ui
bundlé et minifié dans la 2.3.1, qui permet le tri des favoris.
Restent d'autres parties à voir si on veut migrer ou pas : les tabs,
les boutons, ...
--
Bruno
12 years, 4 months
Branche formfilters, suite des hostilités
by Dsls
Hello,
J'ai commencé à pusher un bout de code (pas encore à 100% fonctionnel)
suite aux diverses remarques sur les fitres de formulaire.
Concernant les changements :
* La liste des billets affichés ne bouge plus tant qu'on n'a pas
"appliqué" les filtres
* Il est possible de réinitialiser les filtres aux filtres
actuellement appliqués à la liste des billets
* La mémorisation des filtres n'est pas encore fonctionnelle
* La sélection des colonnes est cassée, je vais regarder comment corriger ça
Pour résumer le fonctionnement des filtersets :
* L'application de filtres (méthode POST) engendre une redirection
vers post.php?filtres_définis (design pattern PRG)
* le filterset gère 2 listes de filtres (via clones), l'une pour
l'édition des filtres, l'autre pour les filtres appliqués à la liste
affichée
* Les filtres correspondant à liste affichés sont stockés dans un
champ hidden, afin de s'y retrouver à chaque changement de page
Il me semble intéressant de permettre de "voir" quelque part les
filtres correspondant à la liste affichée. Les mécanismes internes php
des classes filter permettent de le faire, je pensais à un tooltip qui
s'afficherait sur un hover (sur une étoile à coté du titre de la liste
de billets par exemple).
Z'en pensez quoi ?
--
Bruno
12 years, 4 months