6
votes

Enveloppez HTML contextuel autour d'une variable de brindille spécifique {{produit.name}}

Je veux envelopper automatiquement certains html, disons quand je l'appelle {{product.name}} dans mon modèle brindille.

Alors, quand dans un modèle de branche, j'utilise {{product.name}} , je veux que la sortie soit: Mon nom de produit . Je ne peux pas utiliser des filtres brindille ou des macros, car je vraiment besoin de la syntaxe de modèle pour être {{product.name}} , si l'utilisateur final (concepteur de modèle), n'a pas à se soucier à ce sujet.

La raison pour laquelle je en ai besoin parce que je suis la construction d'un Editting sur la page outil pour les modèles de brindille, donc je dois connaître les contextes de ces variables au sein de HTML.

J'ai essayé de remplacer le compilateur que le Twig_Environment usages, mais je ne peux pas sembler modifier la sortie du noeud variable brindille.

Comment puis-je faire?

EDIT

Je voulais dire que je dois cette option pour utiliser le {{product.name}} syntaxe, puisque d'autres concepteurs travailleront avec les modèles en dehors de Symfony 2. Je veux faire presque toutes brindille les variables modifiables dans le front-end, donc une solution avec des filtres ou des macros peuvent en effet le travail, mais il tue la facilité d'utilisation et la lisibilité de la plate-forme que je vous écris. Il n'y a pas d'API publique actuellement en brindille qui peut atteindre ce que je veux, c'est pourquoi je suis jongler avec le compilateur brindille. Je n'ai pas les connaissances requises des éléments internes Brindille pour y parvenir. Si quelqu'un pouvait me pointer dans une direction qui serait génial!

MISE À JOUR 2

Je l'ai trouvé un endroit où je peux obtenir ce que je veux. Chaque noeud GetAttr est compilé à $ this-> getAttribute (someContext $, "propriété") . Donc, si je peux changer la sous-classe de modèle de brindille compilé, je peux obtenir ce que je veux. Par défaut, tous les modèles de brindille vont de Twig_Template . Je veux étendre cette méthode .

Comment puis-je changer la sous-classe de tous les modèles de brindille compilé?

Mettre à Jour 3 Je l'ai trouvé un moyen d'utiliser ma propre classe de base pour tous les modèles de brindille compilé. Je peux simplement définir comme une option sur l'environnement brindille, voir ce lien . J'espère le faire fonctionner demain et je vais poster une réponse appropriée sur la façon dont je l'ai résolu tous ensemble. Je ne sais pas comment je vais gérer des échappements, puisque cela se produira après la balise $ this-> getAttribute () est appelé.


6 commentaires

Avez-vous essayé d'écrire une extension de brindille? Quel problème avez-vous?


Oui, je l'ai fait, mais là, je n'ai que le contexte de l'ensemble du fichier. Mais ce dont j'ai besoin, c'est le contexte qui est donné au nœud getattr et utilisez la propriété qu'il tente de s'en sortir pour la sortie FINALE TWIG. Lorsque j'étendie le compilateur, je peux utiliser la méthode sous-composile pour accéder à ces nœuds, mais je ne trouve pas de moyen de modifier la sortie de ceux-ci. Mes connaissances pour les internes de brindilles ne suffisent pas pour accomplir ce que je veux.


Pourquoi le bowvote? Si ma question n'est pas claire, veuillez le dire, alors je peux essayer de mieux l'expliquer.


probablement parce que ce n'est pas clair ce que vous avez essayé de faire


Salut Steffen, que pensez-vous de ma réponse?


@Matteo Merci d'avoir aidé, j'ai mis à jour ma question et j'ai également progressé avec mon problème! Je crains que je ne puisse pas utiliser les filtres pas des macros, de sorte que les solutions faciles ne conviendront pas.


3 Réponses :


0
votes

Je suggère d'écrire un filtre personnalisé. Vous pouvez trouver le doc ici sur la manière d'écrire et de configurer dans votre environnement

{{ myProduct|my_custom_product_filter}}


0 commentaires

2
votes

Je pense macros sont les meilleurs candidats à ces types d'emballages. Par exemple: p>

main.Twig kbd> p> xxx pré>

macros.twig kbd> p > xxx pré>

context kbd> p> xxx pré>

résultat kbd> p>

<span data-id="8" data-prop="name">My Georgeous Product</span>


1 commentaires

HI @alain semble macro sonne une meilleure approche au lieu d'un filtre de brindille. +1



2
votes

Je l'ai résolu en enveloppant le Imprimernode créé lors de l'analyse d'un Var_Start jeton (à l'intérieur de l'analyseur de brindille) avec mon propre editablePrinTnode . Dans ce nœud, je traverse l'expression compilée par le nœud d'impression et obtenir le chemin de propriété nécessaire et transmettez-le comme une dispute à une fonction d'emballage autour de la fonction d'évacuation des brindilles par défaut compilée par le imprimée .


1 commentaires

Soin de partager le code? Je cherche à résoudre un problème similaire et une illustration de votre solution serait vraiment utile.