Sitecore Content Albero Architettura

Question

Diciamo che esiste una componente di presentazione in un progetto che rende una lista non ordinata Abbiamo un paio di opzioni di fornitura di dati da qualsiasi ListRenderer in una pagina (chiamato ListRenderer, forse.):

1. Avere un campo TreeList (o TreeListEx) sull'elemento di contenuto e leggere ListRenderer da esso.
2. Fornire un DataSource (o un altro parametro) al ListRenderer tramite i dettagli della presentazione.

Io di solito evito il numero 1 nei miei progetti perché lega i sottolivelli ai modelli, il che diventa piuttosto disordinato. Se segui questo percorso, alla fine avrai campi per supportare ogni potenziale sottolivello nel tuo progetto.

Quindi le mie soluzioni tendono all'opzione n. 2, che elimina questo problema. Tuttavia, viene fornito con una propria borsa di domande. Dove posso inserire questi vari "elenchi" per un determinato ListRenderer da usare? Per massimizzare il riutilizzo e la condivisione, di solito creo una directory di componenti vicino alla radice del sito che contiene tutti questi tipi di cose, se prevedo che gli elenchi saranno condivisi. Questo sembra meno accessibile e difficile da usare per l'autore dei contenuti, che improvvisamente non hanno idea di dove sia la fonte per il loro ListRenderer a meno che non sappiano come aprire i dettagli della presentazione (che è leggermente avanzato per il mio utente medio).

Se ritengo che le Liste non saranno condivise e sono molto specifiche per la pagina, le inserirò direttamente sotto l'elemento in questione. Questo ha la tendenza a confondere la struttura dei contenuti, tuttavia, e qualsiasi sublayout di navigazione generato dinamicamente deve quindi verificare se un elemento è una pagina effettiva prima di generare il collegamento ad esso. Più lavoro su Sitecore, meno utilizzo questo approccio, ma mi sembra più facile per l'autore dei contenuti. L'accesso alle informazioni è molto più semplice quando si utilizza questo approccio.

Esiste un modo accettato dal settore per affrontare questo problema? Succede sempre nei progetti, e nella mia testa faccio fatica a bilanciare preoccupazioni tecniche e paternità dei contenuti in situazioni come queste.

Answer 1

Come ha commentato Mark, non esiste un vero standard di settore.

Mi sento come se fosse qualcosa che ha bisogno di miglioramenti. Soprattutto quando si utilizza l'opzione DataSource, le cose diventano meno trasparenti per gli editori e man mano che la dimensione del sito cresce, aumenta anche la complessità.

Tutto quello che posso dire è come lo farei, che probabilmente è molto simile a come lo stai facendo.

1) Per le pagine di panoramica come notizie, eventi e articoli faq, inserirò gli elementi sotto l'elemento di riepilogo e utilizzerò il modulo di origine condivisa di NewsMover per creare automaticamente una gerarchia.

2) Creerò un sito globale che contiene elementi condivisi su siti o pagine. Gli elementi DataSource per i componenti verranno inseriti qui.

3) Per i componenti che sono presenti sui valori standard, vorrei aggiungere un campo elenco al modello (ad esempio, quando si visualizza le voci relative a una pagina di contenuto)

Il più delle volte si tratta di una scelta logica e a volte è solo una questione di gusti.

Vorrei aggiungere che ho scritto un blog post su come disporre automaticamente gli elementi dell'origine dati creati per i componenti impostati su valori standard. Questo potrebbe aiutarti se stai usando quelli.

Edit: "Di solito evitare di # 1 nei miei progetti perché si lega Sublayouts ai modelli, che ottiene piuttosto confusa Se si va su questa strada, alla fine dovrete campi per sostenere ogni potenziale sublayout nel vostro. progetto."

Oggi ho blogged su un metodo per nascondere i campi e le sezioni nell'editor di contenuti se non c'è alcun sottosistema impostato sull'elemento che richiede quei campi, il che aiuta a prevenire il pasticcio di avere molti campi inutilizzati sul tuo elementi.

Answer 2

Ottima domanda. Ho usato tutte le tecniche che hai menzionato, a seconda del pubblico e delle specifiche del progetto. Il problema è che, come con tutte le cose di Sitecore, sono tutti modi validi per raggiungere lo stesso obiettivo e farai fatica a trovare una risposta che funzioni in ogni situazione.

Quasi sempre utilizzo anche il n. 2, ma è possibile che alcuni programmi di riqualificazione degli autori dei contenuti siano necessari e assicurati di aggiungere restrizioni a ciò che l'autore dei contenuti può selezionare come target. Ho (all'interno dello stesso progetto) strutturato gli elementi vicino alla radice (in una cartella di contenuto condivisa) e sotto l'oggetto in questione, a seconda di ciò che sentivo fornirebbe il miglior contesto.

Inoltre, se esistessero altre pagine figlio sotto l'elemento e le voci dell'elenco, quindi inserirò gli elementi dell'elenco in una cartella separata (con un'icona comune "elenco voci") e riordinarlo in essere il primo elemento per la separazione e la chiarezza.

Se si desidera utilizzare qualsiasi tipo di personalizzazione e DMS allora si avrà bisogno la possibilità di passare l'origine dati in ogni caso in modo da non dovrebbe posizioni codice rigido.

È potrebbe anche (se non lo hai già) desidera considerare l'utilizzo di:

Convert Data Source Paths to IDs Using the Sitecore ASP.NET CMS
- Utile se avete bisogno di ristrutturare il suo sito web in un secondo momento

Queryable Datasource Locations
- utile per le situazioni più sedi in cui è necessario fare cloni, o impostazione come valore predefinito origine dati a valori standard quando le liste sono direttamente sotto l'articolo ma ti dà la possibilità di cambiarlo.

Preferisco utilizzare personalmente le origini dati querable, trovo la sintassi xpath più logica.