Recuperar valores de un componente vinculado en Dreamweaver TBB y hacerlo SiteEditable

Question

Estoy trabajando en Dreamweaver TBB en SDL Tridion 2011 SP1.

No estoy al tanto de manejar enlaces de componentes en Dreamweaver TBB.

Considere que mi nombre de componente es "A" que tiene un enlace a otro componente "B".

Componente Una fuente es el siguiente:

<Content xmlns="Some UUID"> 
    <Name xlink:type="simple" xlink:href="tcm:184-1897" 
      xmlns:xlink="http://www.w3.org/1999/xlink" xlink:title="B"></Name> 
</Content> 

fuente

El componente B es:

<Content xmlns="Some other UUID"> 
    <first>first field</first> 
    <second>second field</second> 
</Content> 

Quiero escribir una DWT TBB que se puede acceder a los campos en el componente relacionado B del componente A

Quiero usar el método de representación RenderComponentField.

Necesito agregarle extensiones, podré aplicar SiteEdit en él.

Por favor, comparta sus opiniones al respecto.

Gracias.

Answer 1

Hay dos cuestiones separadas en este tema:

1. cómo acceder a los campos de un componente vinculado en DWT?
2. ¿Cómo hacer que los campos de un componente vinculado editable en SiteEdit 2009?

Esta es la respuesta a la pregunta 1. Voy a ofrecer una respuesta por separado para la pregunta 2.

En modo predeterminado de Tridion de expresiones en las plantillas DWT sólo tiene acceso a los campos de componentes que son en el paquete.Entonces, si desea acceder a los campos del Componente B, tendrá que escribir un C# TBB que inserte ese Componente en el Paquete.

Un ejemplo de C# fragmento:

var componentA = (Component) engine.GetObject(package.GetValue("Component.ID")); 
var fieldsA = new ItemFields(componentA.Content, componentA.Schema); 
var linkField = (ComponentLinkField) fieldsA["Name"]; 
var componentB = linkField.Value; 
var itemB = package.CreateTridionItem(ContentType.Component, componentB); 
package.PushItem("ComponentB", itemB); 

Si pones esto en un C# fragmento TBB y colocarlo en el TC antes de la DWT, se puede hacer esto en su DWT:

@@ComponentB.Fields.first@@ 

Alternativamente, puede utilizar Nuno de Dreamweaver Get eXtension (DGX) acceder a dichos campos sin escribir una TBB:

@@Get("Fields.Name.first")@@"/> 

El único inconveniente de usar el DGX es que deberá instalarlo en cada servidor Tridion. Después de eso, un montón de funcionalidad extendida está disponible en sus DWT.

Answer 2

No se pueden leer los campos desde B utilizando las plantillas estándar de Dreamweaver. Tendrá que escribir un C# TBB para extraer el componente vinculado y colocarlo en el paquete como tipo Componente. Luego puede usar la sintaxis DWT para leer los campos de ese componente. Por ejemplo: @@ linkedComponent.Fields.first @@

Siteedit es problemático en este caso y las diferentes versiones usan diferentes sintaxis y capacidades. Me temo que con la última versión no puede editar dichos campos ...

Answer 3

Si está utilizando SiteEdit 2009 es posible, solo un poco más difícil de lo que sería con los campos de componentes principales. SiteEdit funciona al envolver los campos de contenido con el marcado JSON. No hay ninguna razón por la que no pueda detectar si el objetivo de la publicación es la estadificación y escriba este JSON por su cuenta.

Alternativamente Will Price ha desarrollado algunos bloques de construcción de plantillas para ayudar con SiteEdit que están disponibles here.

Estos están acompañados por una guía here, específicamente la sección en embedded components será de utilidad para usted.

Answer 4

Permitir que los campos de un componente vinculado sean editables se ha introducido en SiteEdit 2009 SP2. El front-end de SiteEdit funciona en base al SiteEdit command language que está integrado en el HTML que obtiene del servidor de transferencia.

Digamos que usted tiene un solo componente de allí:

<div class="cp"> 
    <!-- Start SiteEdit Component Presentation: {"ID" : "cp_1", 
     "ComponentID" : "tcm:12-549", "ComponentTemplateID" : "tcm:12-568-32", 
     "ComponentVersion" : 5, "IsQueryBased" : false } --> 
    <label>Title: </label> 
    <span> 
     <!-- Start SiteEdit Component Field: {"ID": "cf_1", 
      "XPath": "tcm:Content/custom:Content/custom:Title", 
      "IsMultiValued":false} --> 
     Tips for getting insurance when you have a pre-existing condition 
    </span> 
</div> 

Esos Start SiteEdit comentarios en los que hay comandos que su HTML da a SiteEdit y se puede ver la forma en que marcan la Presentación de componentes y el campo de título.

Si represente los campos de un componente relacionado, es necesario tener también un correspondiente comando Presentación de componentes así:

<div class="cp"> 
    <!-- Start SiteEdit Component Presentation: {"ID" : "cp_1", 
     "ComponentID": "tcm:12-54", "ComponentTemplateID": "tcm:12-56-32", 
     "ComponentVersion" : 5, "IsQueryBased" : false } --> 
    <label>Title: </label> 
    <span> 
     <!-- Start SiteEdit Component Field: {"ID": "cf_1", 
      "XPath": "tcm:Content/custom:Content/custom:Title", 
      "IsMultiValued":false} --> 
     Tips for getting insurance when you have a pre-existing condition 
    </span> 
    <br /> 
    <div class="cp"> 
     <!-- Start SiteEdit Component Presentation: {"ID" : "cp_2", 
      "ComponentID": "tcm:12-85", "ComponentTemplateID": "tcm:12-60-32", 
      "ComponentVersion" : 2, "IsQueryBased" : true } --> 
     <label>Byline: </label> 
     <span> 
      <!-- Start SiteEdit Component Field: {"ID": "cf_2", 
       "XPath": "tcm:Metadata/custom:Metadata/custom:ByLine", 
       "IsMultiValued":false} --> 
      "It's a huge problem, because ..." says one expert. 
     </span> 
     <br /> 
     <label>Copyright: </label> 
     <span> 
      <!-- Start SiteEdit Component Field: {"ID": "cf_3", 
       "XPath": "tcm:Metadata/custom:Metadata/custom:Copyright", 
       "IsMultiValued":false} --> 
      Getty Images 
     </span> 
    </div> 
</div> 

El ahora hay dos Start SiteEdit Component Presentation comandos, uno para el componente externo y otro para el Componente vinculado. Una cosa importante a tener en cuenta aquí es que la propiedad IsQueryBased de la Presentación de componente anidada debe establecerse en verdadero. Esto le dice al front-end de SiteEdit que no se supone que la Presentación de componente esté presente en el XML de página que recupera de Tridion.

Al front-end de SiteEdit no le importa cómo se colocan los comandos en el HTML.

Lo más habitual es que las personas llamen al RenderComponentPresentation y RenderComponentField, que marca las partes correspondientes. Pero, por desgracia la función RenderComponentField sólo se puede utilizar para hacer campos de la llamada "Componente contexto", que se ve así:

Item component = _package.GetByType(ContentType.Component); 

Esto significa que en un solo DWT todas las llamadas a RenderComponentField trabajarán en el mismo contexto Componente. Por lo tanto, nunca puede llamar al RenderComponentField en un solo DWT para representar campos de dos componentes diferentes.

tiene dos opciones para resolver este:

1. llamada RenderComponentPresentation para el componente ligado
2. Prestar al Start SiteEdit Component Presentation y Start SiteEdit Component Field ordena a sí mismo en el DWT

La opción 1 es el más limpio de separación se puede obtener: dado que está renderizando campos de otro Componente, esencialmente está renderizando otra Presentación de Componente. Si se divide a cabo el diseño de los campos vinculados a una DWT separada y construir un CT alrededor de eso, puede hacerla como este en su DWT principal:

@@RenderComponentPresentation(Component.Fields.Name, "tcm:1-2-32")@@ 

Walter explicó mejor en su article on Tridion templating:

Dado que el alcance de esta plantilla Dreamweaver está limitado a mostrar los campos de componentes actuales, es necesario un paso adicional utilizando la función RenderComponentPresentation. Necesitamos pasar el URI TCM del componente multimedia a esta función, junto con el URI TCM de otra plantilla Dreamweaver.

A pesar de que puede acceder a más TC y la ETAP, esos ETAP será mucho más simple ya que ahora puede utilizar RenderComponentField en ellos como de costumbre.

La opción 2 realmente solo significa que está produciendo los comentarios HTML con los comandos SiteEdit en su DWT. Dado que el command language está documentado como parte de la API (ver enlace arriba) hay pocas posibilidades de que cambie en futuras versiones de SiteEdit 2009.

Disculpe la larga historia, usted desencadenó un caso de uso complicado aquí . Espero que tenga sentido.