Leverage the Datum Value of one component in another on the same Page

I have 2 componnets on a page.Both need to have the same DCR to be browsed by the User .
However this is turning out to be an authoring overhead for the user.

Requirement is to dynamically get the value/path of the DCR browsed in the first component to be used for second component as well

I am looking out for options to do the same.

Please suggest any pointers

Find more posts tagged with

Comments

Rick Poulin

Quite simply, this can't be done. If you expand on the scenario you're trying to build, there might be another approach.

e.g. Typically, if you know which DCR you'll want at precontroller time (based on the page name or a query string param or something like that), then you can grab it and make it available to all components on the page. But you can't pass datum values from one component to another, mainly because you can't guarantee the order in which they get executed.

narendhiran

Thanks rpoulin

The DCR Datum value is completely on the user's discretion .
User can browse any DCR in the first component.

We wanted to understand if we can get a handle on this user selected DCR path for the second component on the same page.

Also ,if the user saves the page after browsing DCR in first component,then DCR path is available as ext attribute for the page.
Then LSCS queries could be utilized to retrieve the DCR path value and leverage it for the second component.

your thoughts?

Rick Poulin

Also ,if the user saves the page after browsing DCR in first component,then DCR path is available as ext attribute for the page.
Then LSCS queries could be utilized to retrieve the DCR path value and leverage it for the second component.

If I read this right, you're saying SitePub will automatically create a dependency on the selected DCR in component1, so you want to push that information to LSCS and have component2 read that value to know the DCR that was selected?

Yes, this could work but the edge cases worry me. What happens if component1 isn't on the page? What happens if you have a second instance of component2 -- should it also load the same DCR? What happens if you have two instances of component1, or any other component that also requires a DCR -- how will component2 know which DCR dependency to use?

Maybe you can control the edge cases by "guaranteeing" that you'll always have exactly those two components on a page together (e.g. via the use of a Template perhaps), or maybe the edge cases are limited by your actual business scenario.. in any case, this implementation strategy is easily 'breakable' so make sure to properly document it, lest another developer come along 6mo from now and attempt to make it do something it can't.

narendhiran

Yes, the two components are tied to a template and that template will always be used for the page we have the requirement for.

One of the ways we could think of is getting the DCR path value in first component external and setting it in page scope.Then retrieving it in the external of the second component.

Also we can save the dcr path in another lookup kind of a DCR with name value pairs- page-id/page-name against the DCR path and leverage this information in the second component.

However this might not work in Teamsite Edit.As the order of execution of components is random .

Any suggestions /pointers?

Garth McMillan

We wanted to do something similar, though ended up approaching it a little differently. In our case we had a single DCR which had the main page content as well as potentially some featured content. Our page template is a traditional 3 column with main content in the middle column and featured content in the right.

Originally we had 2 components, one in each area, that both linked to the same DCR - but this was a pain. We looked at a number of options but hit most of the snags that have already been mentioned in this thread (though we don't use LSCS).

We opted to just use a single main content component on the page, and have that component also process the featured content and put the result in a custom page scope object. We added the page scope placeholder to our page template (fixed-layout.page.xsl) and our main content component dumps whatever we want into it. If there's no content added to it, it doesn't get shown.

This works well, except for the edit window - because page scopes don't work in that context - and according to support there's no plan to do so in the short term. We've just put a placeholder notice in that location saying to preview the page to see the automatically injected content.

Rick Poulin

One of the ways we could think of is getting the DCR path value in first component external and setting it in page scope.Then retrieving it in the external of the second component.

Also we can save the dcr path in another lookup kind of a DCR with name value pairs- page-id/page-name against the DCR path and leverage this information in the second component.

This approach doesn't work (in a reproducible way) on the runtime either because there's no way to guarantee the order in which components get executed. Also, the page scope doesn't pass stuff between components, you'd have to use a request attribute for that.

interDev

If I read this right, you're saying SitePub will automatically create a dependency on the selected DCR in component1, so you want to push that information to LSCS and have component2 read that value to know the DCR that was selected?

Yes, this could work but the edge cases worry me. What happens if component1 isn't on the page? What happens if you have a second instance of component2 -- should it also load the same DCR? What happens if you have two instances of component1, or any other component that also requires a DCR -- how will component2 know which DCR dependency to use?

Maybe you can control the edge cases by "guaranteeing" that you'll always have exactly those two components on a page together (e.g. via the use of a Template perhaps), or maybe the edge cases are limited by your actual business scenario.. in any case, this implementation strategy is easily 'breakable' so make sure to properly document it, lest another developer come along 6mo from now and attempt to make it do something it can't.

Completely agree with Rick on this.

One addition will be: You can avoid using LSCS in this case. You can directly read the DCR content from LSDS server itself once you know the path of that DCR through dependency.