• Accueil / Salesforce / Blog Bob Buzzard:…
, Blog Bob Buzzard: Documentation à partir de la source de métadonnées avec un plug-in Salesforce CLI<span class="wtr-time-wrap after-title"><span class="wtr-time-number">4</span> minutes de lecture</span>

Blog Bob Buzzard: Documentation à partir de la source de métadonnées avec un plug-in Salesforce CLI4 minutes de lecture


, Blog Bob Buzzard: Documentation à partir de la source de métadonnées avec un plug-in Salesforce CLI<span class="wtr-time-wrap after-title"><span class="wtr-time-number">4</span> minutes de lecture</span>

introduction

Dans la partie 1 de cette série, j’ai expliqué comment générer un plugin et cloner le
exemple de commande.
Dans la partie 2, j’ai couvert la recherche et le chargement du package.json manifest et mon fichier de configuration personnalisé.
Dans la partie 3, j’ai expliqué comment charger et traiter les fichiers de métadonnées au format source.

Dans
Partie 4, j’ai montré comment enrichir des champs en extrayant des informations stockées en dehors de
le fichier de définition de champ.

Dans l’épisode passionnant de cette semaine, je vais tout rassembler et générer le
Sortie HTML. Cela s’est fait à travers plusieurs itérations:

  • Quand j’ai eu l’idée pour la première fois, j’ai fait ce que je fais habituellement, à savoir
    coder en dur du HTML très basique dans le code source, car à ce stade, je suis
    rarement sûr que les choses vont fonctionner.

  • Avant ma première présentation du plug-in, j’ai décidé de déplacer le HTML
    vers des fichiers qui ont été facilement modifiés, mais toujours sous forme de fragments. Cela fait
    montrer le code plus facilement, mais cela signifiait que je devais écrire un peu de
    code passe-partout, mais c’était tout ce pour quoi j’avais vraiment le temps.

  • Une fois que j’ai fait la première série de discussions, j’ai eu le temps de revoir et de bouger
    à un modèle de cadre, qui allait toujours être le bon
    Solution. C’était la mise à jour majeure du plug-in auquel j’ai fait référence dans le
    Dernier commentaire.

Cadre de modèle

J’utilisais EJS dans YASP
(Yet Another Side Project) et a aimé la facilité d’intégration. EJS
est synonyme de modèles JavaScript faciles et il est bien nommé. Vous intégrez la plaine
l’ancien JavaScript dans le balisage HTML et appeler une fonction en passant le modèle et
les données qui doivent être traitées par le JavaScript. Si tu as écrit
Pages Visualforce ou modèles d’e-mails dans le passé, ce modèle est très
familier (bien que vous deviez configurer toutes les données dont vous avez besoin avant
en le passant à la fonction générateur – il ne comprendra pas ce qui est nécessaire
basé sur ce que vous avez utilisé comme le fera Visualforce!).

Un extrait de ma page HTML qui répertorie les groupes d’objets:

    
        
        Click to View
    

et tant que je passe la fonction qui génère le HTML un objet
avec une propriété de contenu, qui correspond à la structure attendue, je suis en or.

Pour utiliser EJS dans mon plug-in, j’installe le module nœud,:

npm install --save ejs

(Notez que j’utilise le –enregistrer option, comme
sinon cela ne sera pas identifié comme une dépendance et ne sera donc pas ajouté à
le plug-in. Exactement ce qui s’est passé lorsque j’ai créé la version initiale et
installé sur ma machine Windows!)

J’ajoute la ligne suivante à mon fichier Typescript pour importer la fonction qui
rend le HTML à partir du modèle:

import { renderFile } from 'ejs';

et je peux alors appeler renderFile (modèle, données) à
générer de manière asynchrone le HTML.

Préparer les données

Au fur et à mesure que les plug-ins Salesforce CLI sont écrits
Manuscrit par
par défaut, il est simple de suivre la structure de vos objets
car vous pouvez les taper fortement. En continuant avec l’exemple de mes groupes, le
les données pour ceux-ci sont stockées dans un objet avec la structure suivante:

interface ObjectsContent {
    counter: number;
    groups: Array;
    footer?: object;
}

Plutôt que de le transmettre directement, je le stocke comme le contenu d’un
objet qui inclut des informations standard, comme la version du plug-in et
la date à laquelle les pages ont été générées:

let data={
             content: content,
             footer: 
             {
                 generatedDate : this.generatedDate,
                 version : this.config.version
             }
         };  

Rendu du HTML

Une fois que j’ai les données dans le format dont j’ai besoin, j’exécute la fonction de rendu en passant le nom de fichier du modèle –
notez que comme c’est asynchrone, je dois retourner une promesse à mon appel
fonction:

return new Promise((resolve, reject) => {
    renderFile(templateFile, data, (err, html) => {
        if (err) {
            reject(err);
        }
        else {
            resolve(html);
        }
    })
})  

et ma fonction d’appel boucle à travers les groupes et obtient le HTML rendu lorsque la promesse se résout, qu’elle écrit dans le répertoire du rapport:

this.generator.generateHTML(join('objects', 'objects.ejs'), this.content)
.then(html => {
    writeFileSync(this.indexFile, html);    
});

Métadonnées Moar

Articles Similaires





Source de l’article traduit automatiquement en Français

Besoin d'aide ?
Voulez-vous utiliser Pardot à sa capacité maximale et avoir
+ DE LEADS QUALIFIÉS

Notre analyse de votre Pardot offerte dès aujourd'hui
Merci, vous pouvez compléter notre questionnaire
Nous allons revenir vers vous rapidement !

Fermer