labels, inputs dedans, dehors
by Kozlika
Bon. Je ne sais plus si la discussion avait lieu là ou sur la liste "team"
donc je viens ici (qui peut le plus peut le moins).
Certains se demandaient s'il fallait garder ou non l'input dans le label
pour les checkbox et les boutons radio et souhaitaient ne pas le faire par
souci d'harmonisation avec le code des autres éléments de formulaire.
Comme je ne me souvenais plus des tenants et des aboutissants de leur
présence dans l'admin de DC j'ai répondu que les deux étant corrects je
n'avais pas de religion là-dessus.
Mais en fait si. C'est environ un milliard (et demi) de fois plus chiant de
styler les checkbox et radio quand l'input est en dehors du label.
Vali vala,
Anne
11 years, 4 months
[Twig] Quelques réflexions klingon
by Denis Jean-Christian
Ce message s’adresse surtout à Bruno qui a travaillé sur les classe
dcForm de la branche Twig, j'ai des petits soucis avec.
1) Dans la validation de formulaire je veux lire la valeur d'un champs
mais cela ne fonctionne pas comme pour son écriture.
Pour écrire la valeur d'un champs on fait :
dcForm->user_id = 'plop';
car on passe par :
dcForm->__set('user_id','plop');
Mais pour lire sa valeur si je fais :
echo dcForm->user_id;
ça ne marche pas, car ça me renvoie l'objet complet avec :
dcForm->__get('user_id');
J'ai donc rajouté à la classe dcField la fonction :
public function __toString() { return $this->value; }
qui renvoie la valeur du champs de la classe dcField ce qui donne :
echo dcForm->user_id = echo dcForm->__get('user_id') = echo
dcField->__toString()
Le problème se pose alors pour le test d'existence de sa valeur avec
empty(), en effet :
if (!empty(dcForm->user_id)) {...}
Ce test va uniquement chercher l'existence de l'objet dcField dans
dcForm et pas du tout sa valeur dans dcField il faut alors faire le test
de la manière suivante :
if (dcForm->user_id != ""){...}
Et avec ce test si l'objet n'existe pas dcForm renverra de toute façon
null ce qui garde le résultat de test exacte. En soit c'est pas grave et
je lai déjà vu dans pleins de code mais si on ne le sait pas ça
peut-être déroutant.
2) Avec l'ajout de dcField->__toString() je peux enfin lire facilement
sa valeur pour toutes les fonctions de validation de formulaire mais
pour poursuivre le formulaire je suis obligé d'écrire un truc assez
bizarre :
$form->user_id = $form->user_id;
Etrange non?! En fait ici je passe ce qui provient de ma validation de
formulaire vers mon futur champs de formulaire ! Il faudrait voir si on
ne devrait pas remplir les valeur de champs d'après les information du
_POST ? Ou si je me plante quelque part!
3) Dernière petite question, j'ai souvent quelques variables à passer
aux templates, pour l'instant je le fait avec $_ctx->ma_var = 'plop';
mais faudra quand même qu'on vois ce qu'on partage et ce qu'on ne
partage pas vers les templates ? Perso j'en ai aucune idée :-)
PS: J'ai presque fini mon test de passage de auth.php vers Twig, et je
trouve le code php vachement plus lisible à la fin et pourtant ce n'est
qu'un brouillon, ça promet de belle chose.
Voila, c'était mon quart d'heure klingon,
JC
11 years, 4 months
Trac Dotclear 2 - Tickets
by Franck Paul
Bonsoir les gens,
J'ai modifié légèrement la config. du trac de Dotclear 2 pour qu'on puisse
suivre, via un fil RSS les modifications apportées aux tickets, avec entre
autres les fils de commentaires.
Le flux RSS est ici :
http://dev.dotclear.org/2.0/timeline?changeset=on&milestone=on&ticket=on&...
Ça m'arrangerait que ceux qui sont intéressés par tout ou partie des
tickets encore ouverts là-bas le suive, voire répondent ou contribuent aux
discussions ouvertes dans les commentaires.
Merci
Franck
11 years, 4 months
[Twig] Modifs du jour (b67f949a98f8)
by Denis Jean-Christian
Quelques explications rapides sur mes modifications de ce jour sur la
branche Twig.
1) Chargement de l’environnement Twig directement dans le core.
C'est le fichier de config de Twig donc pas de souci ici je pense.
2) Création d'un context admin $_ctx (original comme nom) dans le
prepend de l'admin.
J'ai gardé dcAdminContext que j'ai simplifié puisqu'il ne contient plus
de javascripts. Et j'ai commencé à ajouter un ou deux truc dessus, à
voir... Par contre, le blog courant n'est pas lisible à la construction
de context, j'ai pas trop regardé pourquoi, vu que je l'ajoute plus tard.
3) Copie des js, images, styles vers inc/admin/default-templates et
création d'un template regroupant tous les javascripts dans des macros Twig.
Je ne sais pas trop si je dois laisser ou non les paramètres aux
fonctions puisque les variables sont globals dans Twig. (ex: jsPageTabs)
PS: on effacera les anciens dossiers plus tard, ils servent encore...
4) Création d'un "serveur de fichier" pour les thème (à la manière de
load_plugins_file)
Mais il y a encore du travail la dessus... Par exemple je perd les
chemin relatif sur les CSS, ou encore, je ne sais pas trop si il faut
une regles de structure des dossiers pour les plugins, etc... Peut-être
que ce n'est tout simplement pas la bonne façon de faire.
5) Modification des templates en fonction de tout ça.
Désolé pour ce gros changement en un seul commit mais tous ces points
étaient imbriqués les uns dans les autres...
J'en ai surement loupé quelques subtilités et oublié des trucs mais ça
donne déjà une idée du schmilblick.
PS: Si il y a moyen de faire des copies (ou déplacements) de fichiers
plus proprement sous hg, je suis preneur.
Cordialement,
JC[breaker
11 years, 4 months
[Twig] javascript
by Denis Jean-Christian
Je continue ma découverte de Twig, c'est pas mal!
Question:
Aujourd'hui tous les javascript sont groupés dans le class de context
admin (jsCommon() ...) mais avec le passage aux templates il serait
mieux et plus logique de les sortir de la class php et les mettre dans
les templates Twig, non?
J'ai testé en creant un fichier js_hepers.htm.twig (enfin peu importe
son nom) dans lequel j'ai créé des {% macro %} contenant chacune
l'equivalent de l'ancienne method de context, ça donnerait un truc comme
ça reproduit pour toutes les methodes :
# fichier helpers.html
{% macro load_IE7() %}
<!--[if lt IE 8]>
<script type="text/javascript"
src="{{theme_url}}js/ie7/IE8.js"></script>
<link rel="stylesheet" type="text/css"
href="{{theme_url}}style/iesucks.css" />
<![endif]-->
{% endmacro %}
# fichier post.html
{% import "js_helpers.html.twig" as js %}
...
{{ js.load_IE7 }}
{{ js.confirm_close(['plop','plaf']) }}
...
Ça le fait ?
PS: Ah oui j'ai aussi fait un serveur de fichier de thème (à la manière
de load_plugin_file.php ) je mettrais tout ça sur le hg un peu plus tard
dans la semaine...
Cordialement,
JC
11 years, 4 months
Twig, suite
by Dsls
Hello,
Je continue mon petit bout de chemin sur la branche twig, dans la
mesure de mon temps libre.
Je viens d'ajouter quelques contrôles sur les forms, l'ajout de
notifications et de messages d'erreur. J'espère obtenir prochainement
un PoC sur la page admin/post.php.
Grosse nouveauté quand même, la gestion des champs submit, avec une
méthode qui me semble assez élégante, le passage de callbacks
(j'aurais pu faire par héritage de classes, mais ça fait plus de code
à faire dans les pages d'admin).
BTW, j'ai vu que jquery-ui avait été mis à jour récemment, cela inclut
aussi les tabs ? Je migrerais biens vers les tabs jquery-ui tant qu'à
faire.
--
Bruno
11 years, 4 months
