2013-05-29 10 views
5

Diciamo che ho un layout di pagina classico.Editor della pagina Sitecore e flusso di lavoro - come?

  • Un colpo di testa, con il logo (uno sublayout)
  • Una navigazione superiore nell'intestazione della pagina (un'altra sublayout)
  • A pagina 3 colonne sublayout con:
    • A sinistra navigazione sublayout caricato nel segnaposto della colonna sinistra
    • Segnaposto in colonna centrale cui diversi elementi di contenuto (presentazione, contenitore schede, blocco di HTML, etc.) possono essere caricati
    • Una posizione nella colonna di destra dove diversi elementi di contenuto barra laterale (condivise tra più pagine) possono essere caricate
  • a piè di pagina sublayout, possibilmente con una navigazione footer sublayout così (come ad esempio Contatti, Aiuto, T & C, etc.)

Ora diciamo che tutto questo può essere modificato nel editor di pagine, e aggiungiamo il fatto che voglio tutto per passare attraverso il flusso di lavoro.

Quando l'editor accede a una pagina specifica (ad esempio la pagina "Chi siamo"), quando farà clic su EDIT, che cosa si aspetta che Sitecore faccia esattamente? Tutti gli articoli che appaiono su quella pagina passano allo stato DRAFT? Oppure succederebbe solo quando, ad esempio, l'editore modifica effettivamente alcuni contenuti in alcuni "elementi di contenuto" visualizzati nella pagina?

E cosa succede quando la pagina viene presentata per l'approvazione? Tutte le voci secondarie che sono state modificate ANCHE entrano nello stato "Inviato per approvazione" e appaiono nella casella di lavoro Approvatore/Editore?

Se nulla di tutto questo accade fuori dalla scatola, come è possibile implementare tutto questo? Qualcuno ha già affrontato questo problema e risolto con successo? Sembra che abbia un problema comune, ma non riesco a trovare alcuna guida su come tutti questi legami tra loro.

Grazie, FG

risposta

3

ho appena fatto un test rapido di questo. Queste sono le mie conclusioni:

Quando l'utente fa clic su modifica in modalità editor di pagina, non succede nulla in quel punto agli stati del flusso di lavoro. Tutto ciò che fa è consentire all'utente di modificare il contenuto.

C'è un chunk "Modifica" nell'editor di pagina che consente all'utente di bloccare e sbloccare - questo sembra influenzare solo l'elemento corrente in fase di modifica, non tutti gli elementi correlati utilizzati per il rendering del contenuto alla pagina.

Lo stesso accade se l'utente fa clic sul pulsante Salva.Solo la voce corrente è bloccato e messo in stato di progetto del flusso di lavoro.

Tuttavia, se l'utente modifica parte del contenuto correlato (logo, nav, footer ecc.), Quando l'utente fa clic sul pulsante di salvataggio, sia l'elemento corrente che gli articoli che sono stati modificati vengono bloccati e inseriti lo stato iniziale del flusso di lavoro (purché i valori standard dei modelli abbiano una configurazione iniziale del flusso di lavoro ovviamente)

Questi test sono stati effettuati sulla versione iniziale di Sitecore 7.0, ma non penso che il comportamento sia cambiato da 6.5 o 6.6.

+0

Molto interessante ... lei sta dicendo che Sitecore è effettivamente in grado di fare la cosa giusta, che è quello di mettere in stato PROGETTO (o qualsiasi altra cosa è lo stato del flusso di lavoro iniziale) solo gli elementi che sono stati effettivamente modificati. Non avrei mai pensato che questo potrebbe essere il caso out-of-the-box. Presumo che questo potrebbe potenzialmente creare problemi di concorrenza quando si dispone di alcuni elementi che sono condivisi tra più pagine (cerchiamo di promuovere la condivisione di blocchi di contenuto per quanto possibile). Grazie per passare attraverso lo sforzo di prove! –

Problemi correlati