tridion - ¿Reglas para el uso del campo de texto enriquecido?
(2)
Buena pregunta por cierto, aunque no tan fácil de contestar. Creo que @Ram tiene razón en que no hay mejores prácticas escritas por ahí, supongo que la mayoría se transmite a través de la capacitación de modelado de contenido ( consulte las pistas de capacitación disponibles ), pero debo admitir que la respuesta a su pregunta es No se discute con mucho detalle allí.
Por experiencia, he visto que los campos de texto enriquecido son una de las opciones más abusadas en SDL Tridion. Lo que llamaría abuso típico es, por ejemplo, un esquema de artículo con un solo campo de texto enriquecido, diseñado para que los editores ingresen HTML directamente en la página. Si bien claramente no es el camino a seguir para la mayoría de las personas (espero; o), depende en gran medida de los requisitos de los clientes hasta dónde debe ir y qué debe permitir en el uso del campo de texto enriquecido.
La primera discusión que siempre surge es si debería permitir el formato del contenido por parte de los editores. Siempre me siento tentado a decir que el contenido y el diseño deben estar separados, pero directamente entra en conflicto con cosas como tablas, texto enfatizado, listas y enlaces. Así que ahí es donde entran los campos de texto enriquecido.
Estoy a favor de restringir el uso de los campos de texto enriquecido siempre que sea posible, así que use el XSLT disponible para eliminar las etiquetas no deseadas y los atributos (de estilo). Una de las primeras cosas a considerar es el uso de imágenes en un campo de texto enriquecido, y la segunda en la lista será el script y las etiquetas de formulario. Si no desea permitirlos en la salida de texto enriquecido, ajuste el XSLT para eliminarlos. Pero al final (desafortunadamente) todo se reduce a los requisitos del cliente. Aunque usted tiene un papel en aconsejarles sobre qué hace y qué no tiene sentido, por supuesto.
¿Alguien puede indicarme algunas reglas a seguir al usar los campos de texto enriquecido en los componentes de Tridion? Me doy cuenta de que puede ingresar un marcado directamente en la pestaña Fuente, pero si ingresa un html incompleto, entonces Tridion lo completa por usted de la siguiente manera:
<!--Enter this-->
<td>test</td>
<!--And it becomes this-->
<table>
<tr>
<td>test</td>
</tr>
</table>
Si ingresa un marcado no válido, aparece una ventana emergente de Resultados de Validación que le informa que su sintaxis no es válida:
<!--Generates Validation Results popup -->
<badtag>
Parece que no hay problema con agregar atributos como id y class al html RTF, siempre que el HTML sea válido, pero ¿cuál es la experiencia de todos los demás? ¿Alguien puede indicarme algunas mejores prácticas adicionales para lo que debería y no debería intentar hacer en un campo RTF de componentes?
Gran pregunta Las mejores prácticas dependen de cliente a cliente, al menos en base a mi experiencia con Tridion.
He visto a algunos clientes que se sienten muy cómodos y hacen más en campos RTF (casi construyendo todo como formularios de captura de datos - jeeez ..), y he visto a algunos clientes que no se sienten muy cómodos con el editor (por ejemplo, copiar y pegar desde word doc etc ..).
No he visto un documento de mejores prácticas y no creo que se adapte a todos, ya que esto depende de la organización o la capacidad y el confort de la agencia.
Como regla general, la queja de XHTML es una necesidad y eso es lo que hace Tridion RTF editor (algo bueno). Esa es la razón por la que notó la limpieza del formato html válido / no válido.
El siguiente enlace de Alvin toca algunos de los temas, pero puede que no sea exactamente lo que está buscando.
http://www.tridiondeveloper.com/rich-text-format-area-css-classes-vs-custom-xml-nodes
Si encuentras uno, por favor comparte con nosotros. Estoy buscando uno también. :)