🇩🇪 Deutsch 🇺🇸 English 🇪🇸 Español 🇫🇷 Français 🇮🇹 Italiano 🇳🇱 Nederlands 🇵🇹 Português
🇩🇪 Deutsch 🇺🇸 English 🇪🇸 Español 🇫🇷 Français 🇮🇹 Italiano 🇳🇱 Nederlands 🇵🇹 Português

Documentation developpeur Page

Documentation developpeur Page

Les Pages sont l'unite d'assemblage de plus haut niveau dans FaceFlow.

Pour les utilisateurs techniques, une Page n'est pas un fichier de template. C'est un enregistrement runtime structure qui relie un layout, des sections ordonnees, des actifs partages et des systemes metier optionnels en une experience publiable.

Responsabilite centrale

La couche Page est responsable de :

  • selectionner la coquille de layout
  • stocker une composition de sections ordonnee
  • relier les valeurs de champs editees aux contrats de Components reutilisables
  • coordonner les systemes embarques comme les Forms, Reviews et Lists
  • prendre en charge des flux d'edition, d'aperçu et de publication gouvernes

Les Pages doivent orchestrer. Elles ne doivent pas devenir l'endroit ou la logique de layout, les decisions de schema de component et les regles metier ponctuelles s'effondrent ensemble.

Modele de Page

Une Page typique combine :

  • un layout
  • une liste ordonnee d'instances de Components
  • des sections reutilisables optionnelles au scope page
  • des experiences Form ou Review embarquees en option
  • un comportement dynamique de list en option

Conceptuellement :

{
  "layout": "default-site",
  "components": [
    {
      "component": "hero-banner",
      "scope": "page",
      "fields": {
        "heading": "Build faster with FaceFlow",
        "subheading": "Reusable sections for scalable websites"
      }
    },
    {
      "component": "testimonial-strip",
      "scope": "layout"
    }
  ]
}

L'implementation exacte de stockage reste interne. Ce qui compte pour les utilisateurs techniques, c'est le contrat : les Pages assemblent des objets reutilisables au lieu de posseder directement du code de template brut.

Chemin de rendu

Au runtime, le rendu d'une Page suit en general ce flux :

  1. resoudre la Page demandee
  2. charger le Layout assigne
  3. resoudre les sections partagees au scope site, layout et page
  4. rendre les Components ordonnes avec leurs valeurs de champs
  5. rendre les systemes dynamiques embarques comme les Lists, Forms ou Reviews
  6. retourner la sortie finale assemblee

Une structure simplifiee ressemble a ceci :

<body>
  {header}
  {siteComponents}
  <main>
    {content}
  </main>
  {footer}
</body>

La Page orchestre {content}. Le Layout possede la coquille autour.

Exemple d'assemblage

Un assemblage de Page plus explicite peut se raisonner ainsi :

{
  "layout": "service-site-shell",
  "components": [
    {
      "component": "hero-banner",
      "scope": "page",
      "fields": {
        "heading": "Enterprise Security",
        "summary": "Structured trust content for SaaS websites",
        "ctaUrl": "/contact/"
      }
    },
    {
      "component": "lead-form",
      "scope": "page",
      "fields": {
        "contactForm": "contact-sales"
      }
    }
  ]
}

Cet exemple est utile car il montre que la Page possede la composition et les valeurs d'instance, tandis que les contrats de Layout et de Component restent separes.

Relation avec Layouts et Components

Gardez ces frontieres strictes :

  • Layout definit la coquille de page
  • Component definit un contrat de section reutilisable
  • Page assemble une sequence de components dans une experience finale

Si une Page commence a porter de la logique structurelle de coquille, le Layout est trop faible.

Si une Page commence a dupliquer des regles de section qui devraient appartenir a un Component, la reutilisation est en train de se degrader.

Exemple courant de composition de Page

layout default-site
  -> component hero-banner
  -> component feature-grid
  -> component lead-form
  -> component faq-accordion

Cette composition doit rester comprehensible sans lire de code personnalise. Si ce n'est pas le cas, l'architecture est en general en train de deriver.

Contenu dynamique et interactif

Les Pages incluent souvent plus que des sections statiques. Cas frequents :

  • un Component de capture de leads qui embarque un Form
  • une section de confiance qui embarque un modele de Review
  • une archive de ressources pilotee par une List
  • des Variables conscientes de la page reutilisees dans plusieurs sections

Exemple :

<section class="section-contact">
  <div data-form-embed="enterprise-demo-request"></div>
</section>

<section class="section-proof">
  <div data-review-embed="customer-success-reviews"></div>
</section>

C'est pourquoi la revue de conception d'une Page doit considerer le chemin runtime complet, pas seulement la composition visuelle.

Frontieres d'integration

En revue technique, gardez ces frontieres stables :

  • la Page choisit quels systemes reutilisables participent a l'experience
  • le Component definit comment une section reutilisable se rend
  • les modeles Form et Review possedent le comportement de soumission
  • les definitions de List possedent le comportement d'archive dynamique

Si une Page commence a porter trop de details d'implementation, le modele objet est en train de deriver.

Types de Pages et strategie de changement

Toutes les Pages ne doivent pas etre traitees de la meme maniere.

  • les pages de campagne optimisent la vitesse et la variation controlee
  • les pages de service evergreen optimisent la reutilisation et la maintenance long terme
  • les pages pilotees par list optimisent la croissance de contenu dynamique
  • les pages de confiance ou de conversion coordonnent souvent plusieurs systemes ensemble

Les equipes techniques doivent choisir les bons actifs autour de chaque type au lieu de forcer chaque Page dans le meme pattern.

Versioning, localisation et portabilite

Les Pages sont souvent l'unite que les equipes :

  • localisent entre les langues
  • restaurent apres un changement non voulu
  • deplacent entre environnements
  • revoient avant publication

Traitez la Page comme un actif operationnel, pas seulement comme une cible de sortie visuelle.

References de fonctionnalites associees :

Checklist de revue technique

  • la Page utilise-t-elle le bon Layout pour sa famille de pages ?
  • les Components sont-ils ordonnes et scopes intentionnellement ?
  • les Forms, Reviews ou Lists sont-ils embarques via des contrats reutilisables plutot que via du markup code en dur ?
  • la Page s'appuie-t-elle sur des Variables ou des sections partagees la ou la reutilisation est attendue ?
  • un futur editeur comprendrait-il la structure de la Page sans devoir deviner des exceptions ?

Anti-patterns

Evitez :

  • du markup de coquille specifique a une page qui devrait appartenir au Layout
  • du markup de section libre repete sur de nombreuses Pages
  • de la logique metier cachee dans un contenu propre a une page
  • de melanger des objectifs sans rapport dans une seule Page parce qu'elle est deja en ligne
  • de forcer une archive dynamique dans une composition de Page maintenue manuellement

Exemple de pattern de construction

Pour une page de service typique :

Layout: service-site-shell
Page:
  - hero-banner
  - benefits-grid
  - customer-logos
  - review-strip
  - demo-request-form

Ce pattern reste maintenable parce que chaque sujet a une place claire.