2013-01-18 13 views
16

Qualcuno può indicarmi alcune regole da seguire quando si utilizzano i campi Rich Text su Tridion Components? Ho notato che è possibile inserire marcare direttamente sulla scheda Origine, ma se si entra html incompleta poi tridion completa per voi, come segue:Regole per l'utilizzo del campo Rich Text?

<!--Enter this--> 
<td>test</td> 


<!--And it becomes this--> 
<table> 
<tr> 
<td>test</td> 
</tr> 
</table> 

Se si immette codice non valido, quindi si ottiene una convalida Risultati popup dicendo che la sintassi non è valida:

<!--Generates Validation Results popup --> 
<badtag> 

sembra che non v'è alcun problema con l'aggiunta di attributi come id e class al codice HTML RTF, a patto che il codice HTML è valido, ma ciò che è di tutti gli altri esperienza? Qualcuno può indicarmi alcune best practice aggiuntive per ciò che dovrei e non dovrei provare a fare & do in un campo Component RTF?

risposta

11

Grande domanda. Le migliori pratiche dipendono dal cliente al cliente, almeno in base alla mia esperienza con Tridion.

Ho visto alcuni clienti che stanno molto bene e fanno di più nei campi RTF (quasi costruendo tutto come moduli di acquisizione dati - jeeez ..), e hanno visto alcuni clienti che non si sentono a proprio agio con l'editor (ad es. incolla da word doc ecc.).

Non ho visto un documento di buone pratiche e non credo che si possa fare tutto ciò in quanto dipende dalle capacità e dal comfort dell'organizzazione o dell'agenzia.

Come regola empirica, XHTML denuncia è un must e questo è l'editor di Tridion RTF (cosa buona). Questo è il motivo per cui hai notato la pulizia del formato html valido/non valido.

Questo link di Alvin tocca alcuni degli argomenti, ma potrebbe non essere esattamente quello che stai cercando.

http://www.tridiondeveloper.com/rich-text-format-area-css-classes-vs-custom-xml-nodes

Se si trova uno, si prega di condividere con noi. Ne sto cercando anche uno. :)

+0

grazie per i commenti. –

1

Buona domanda, anche se non è facile rispondere. Credo che @Ram abbia ragione nel dire che non ci sono best practice scritte, suppongo che la maggior parte di esse sia passata attraverso la formazione sulla modellazione del contenuto (see the available training tracks) ma devo ammettere che la risposta alla tua domanda non è discussa in dettaglio lì.

Per esperienza ho visto che i campi Rich Text sono una delle opzioni più abusate in SDL Tridion. Le cose che definirei abusi tipici sono ad esempio uno schema di articolo con un singolo campo Rich Text, progettato per consentire agli editor di inserire HTML direttamente nella pagina. Benché questo non sia chiaramente il modo migliore per andare avanti per la maggior parte delle persone (spero; o), dipende molto dalle esigenze dei clienti quanto si dovrebbe andare lontano e cosa si dovrebbe consentire nell'utilizzo del campo Rich Text.

La prima discussione che emerge sempre è se si dovrebbe consentire la formattazione del contenuto da parte degli editori. Sono sempre tentato di dire che il contenuto e il layout dovrebbero essere separati, ma si entra direttamente in conflitto con cose come tabelle, testo sottolineato, elenchi e collegamenti. Ecco dove entrano in gioco i campi Rich Text.

Sono favorevole a limitare l'utilizzo dei campi Rich text il più possibile sempre, quindi utilizzare XSLT disponibile per rimuovere tag e attributi (di stile) indesiderati. Una delle prime cose da considerare è l'uso di immagini in un campo Rich Text, e il secondo sull'elenco sarà script e tag modulo. Se non si desidera consentire loro nell'output Rich Text, regolare l'XSLT per rimuoverli.Ma alla fine (sfortunatamente) dipende principalmente dalle esigenze del cliente. Sebbene tu abbia un ruolo nel consigliarli su cosa fa e cosa non ha senso, naturalmente.

+0

grazie per i commenti. –

Problemi correlati