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

Documentazione per sviluppatori delle Pagine

Documentazione per sviluppatori delle Pagine

Le Pagine sono l'unità di assemblaggio di livello superiore in FaceFlow.

Per utenti tecnici, una Pagina non è un file di template. È un record runtime strutturato che associa un layout, sezioni ordinate, asset condivisi e sistemi di business opzionali in un'unica esperienza pubblicabile.

Responsabilità principali

Lo strato Pagina è responsabile di:

  • selezionare la shell del layout
  • memorizzare la composizione ordinata delle sezioni
  • associare i valori dei campi creati ai contratti riutilizzabili dei componenti
  • coordinare sistemi incorporati come Moduli, Recensioni e Liste
  • supportare flussi governati di modifica, anteprima e pubblicazione

Le Pagine dovrebbero orchestrare. Non dovrebbero diventare il luogo in cui la logica di layout, le decisioni sullo schema dei componenti e regole di business specifiche si fondono tutte insieme.

Modello della Pagina

Una Pagina tipica combina:

  • un layout
  • una lista ordinata di istanze di componenti
  • sezioni riutilizzabili opzionali a livello di pagina
  • esperienze opzionali incorporate di Modulo o Recensione
  • comportamento opzionale dinamico di lista

Concettualmente:

{
  "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'implementazione di memorizzazione esatta è interna. Ciò che conta per gli utenti tecnici è il contratto: le Pagine assemblano oggetti riutilizzabili invece di possedere direttamente codice template grezzo.

Percorso di rendering

A runtime, il rendering della Pagina tipicamente segue questo flusso:

  1. risolvere la Pagina richiesta
  2. caricare il Layout assegnato
  3. risolvere le sezioni condivise a livello di sito, layout e pagina
  4. renderizzare i Componenti ordinati con i loro valori di campo
  5. renderizzare sistemi dinamici incorporati come Liste, Moduli o Recensioni
  6. restituire l'output finale assemblato

Una struttura semplificata appare così:

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

La Pagina possiede l'orchestrazione di {content}. Il Layout possiede la shell intorno ad essa.

Esempio di assemblaggio

Un assemblaggio Pagina più esplicito può essere pensato così:

{
  "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"
      }
    }
  ]
}

Questo esempio è utile perché mostra la Pagina che possiede la composizione e i valori dell'istanza, mentre i contratti di Layout e Componente rimangono separati.

Relazione con Layout e Componenti

Mantenere questi confini rigorosi:

  • Layout definisce la shell della pagina
  • Componente definisce un contratto di sezione riutilizzabile
  • Pagina assembla una sequenza di componenti in un'esperienza finale

Se una Pagina inizia a portare logica strutturale della shell, il Layout è troppo debole.

Se una Pagina inizia a duplicare regole di sezione che dovrebbero appartenere a un Componente, il riuso si sta degradando.

Esempio comune di composizione di Pagina

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

Quella composizione dovrebbe rimanere comprensibile senza leggere codice personalizzato. Se non lo è, l'architettura solitamente sta deragliando.

Contenuto dinamico e interattivo

Le Pagine spesso includono più di sezioni statiche. I casi comuni includono:

  • un Componente di acquisizione lead che incorpora un Modulo
  • una sezione di fiducia che incorpora un modello di Recensione
  • un archivio di risorse guidato da una Lista
  • Variabili a livello di pagina riutilizzate in più sezioni

Esempio:

<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>

Ecco perché la revisione del design della Pagina dovrebbe considerare l'intero percorso a runtime, non solo la composizione visiva.

Confini di integrazione

Nella revisione tecnica, mantenere stabili questi confini:

  • la Pagina sceglie quali sistemi riutilizzabili partecipano all'esperienza
  • il Componente definisce come una sezione riutilizzabile viene renderizzata
  • i modelli di Modulo e Recensione possiedono il comportamento di invio
  • le definizioni di Lista possiedono il comportamento dinamico di archivio

Se una Pagina inizia a portare troppi dettagli di implementazione, il modello di oggetto sta deragliando.

Tipi di Pagina e strategia di modifica

Non tutte le Pagine dovrebbero essere trattate allo stesso modo.

  • le pagine di campagna ottimizzano per velocità e variazione controllata
  • le pagine di servizio evergreen ottimizzano per riuso e manutenzione a lungo termine
  • le pagine guidate da liste ottimizzano per la crescita dinamica dei contenuti
  • le pagine di fiducia o conversione spesso coordinano più sistemi insieme

I team tecnici dovrebbero scegliere gli asset circostanti giusti per ogni tipo invece di forzare ogni Pagina nello stesso schema.

Versionamento, localizzazione e portabilità

Le Pagine sono spesso l'unità che i team:

  • localizzano in più lingue
  • ripristinano dopo una modifica indesiderata
  • spostano tra ambienti
  • controllano prima della pubblicazione

Trattare la Pagina come un asset operativo, non solo come un target di output visivo.

Riferimenti a funzionalità correlate:

Lista di controllo per la revisione tecnica

  • la Pagina usa il Layout corretto per la sua famiglia di pagine?
  • i Componenti sono ordinati e scansionati intenzionalmente?
  • Moduli, Recensioni o Liste sono incorporati tramite contratti riutilizzabili piuttosto che markup hard-coded?
  • la Pagina si affida a Variabili o sezioni condivise dove è previsto il riuso?
  • un futuro editor capirebbe la struttura della Pagina senza dover reverse-engineerare eccezioni?

Modelli da evitare

Evitare questi modelli:

  • markup della shell specifico della pagina che dovrebbe appartenere al Layout
  • markup di sezione libero ripetuto su molte Pagine
  • logica di business nascosta in contenuti esclusivi della pagina
  • mescolare obiettivi non correlati in un'unica Pagina solo perché è già live
  • forzare un archivio dinamico in una composizione di Pagina mantenuta manualmente

Esempio di schema di costruzione

Per una tipica pagina di landing per servizi:

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

Quel modello rimane manutenibile perché ogni preoccupazione ha una casa chiara.

Correlati