Allowing fields of a linked Component to be editable has been introduced in SiteEdit 2009 SP2. The SiteEdit front-end works based on the SiteEdit command language that is embedded into the HTML it gets back from the staging server.
So let's say you have a single Component in there:
<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>
Those Start SiteEdit
comments in there are commands that your HTML gives to SiteEdit and you can see how they mark the Component Presentation and the title field.
If you render fields of a linked Component, you need to also have a corresponding Component Presentation command like this:
<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>
The there are now two Start SiteEdit Component Presentation
commands, one for the outer Component and one for the linked Component. One important thing to note here is that the IsQueryBased property of the nested Component Presentation must be set to true. This tells the SiteEdit front-end that the Component Presentation is indeed not supposed to be present in the Page XML it retrieves from Tridion.
To the SiteEdit front-end it doesn't matter how the commands are put into the HTML.
Most common is for people to call RenderComponentPresentation
and RenderComponentField
, which marks the corresponding parts. But unfortunately the RenderComponentField
function can only be used to render fields from the so-called "context Component", which it looks up like this:
Item component = _package.GetByType(ContentType.Component);
This means that in a single DWT all calls to RenderComponentField
will work on the same context Component. So you can never call RenderComponentField
in a single DWT to render fields from two different Components.
You have two options to solve this:
- Call
RenderComponentPresentation
for the linked Component
- Render the
Start SiteEdit Component Presentation
and Start SiteEdit Component Field
commands yourself in the DWT
Option 1 is the cleanest separation you can get: since you are rendering fields from another Component, you are essentially rendering another Component Presentation. If you split out the layout for the linked fields into a separate DWT and build a CT around that, you can render it like this in your main DWT:
@@RenderComponentPresentation(Component.Fields.Name, "tcm:1-2-32")@@
Walter explained this best in his article on Tridion templating:
Since the scope of this Dreamweaver template is limited to displaying the current component fields, an extra step is necessary by using the RenderComponentPresentation function. We need to pass the TCM URI of the multimedia component to this function, together with the TCM URI of another Dreamweaver template.
Although it does lead to more CTs and DWTs, those DWTs will be a lot simpler since you can now use RenderComponentField
in them as usual.
Option 2 really just means that you're outputting the HTML comments with the SiteEdit commands in your DWT. Since the command language is documented as part of the API (see link above) there is little chance that it will change in future versions of SiteEdit 2009.
Sorry for the long story, you happened to trigger a tricky use-case here. I hope it makes sense.