nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Read DCR from using XSLT in component

cute_guy

I am using a DCR component in which the datum is mapped to a DCR, but this DCR has reference to another DCR in one of its fields.

How to read the contents of child DCR in XSLT @ Appearance XSL?

I tried the document('http://localhost/iw-cc/meta.../default/main/branch/WORKAREA/work/templatedata/cat1/dat2/dcr.xml') but it does not return the content of child DCR.

ENV : TS 6.7.2, LS 3.1

Find more posts tagged with

Comments

Rick Poulin

Try this:

<xsl:copy-of select="document('http://localhost/iw/cci/meta/no-injection/iw-mount/default/main/branch/WORKAREA/work/templatedata/cat1/dat2/dcr.xml')/." />

The key where I think you went wrong is that /iw-cc/ attempts to wrap the output with the visual preview toolbar. The no-injection path ensures that you get to the file directly.

vpatel

I am using a DCR component in which the datum is mapped to a DCR, but this DCR has reference to another DCR in one of its fields.

How to read the contents of child DCR in XSLT @ Appearance XSL?

I tried the document('http://localhost/iw-cc/meta.../default/main/branch/WORKAREA/work/templatedata/cat1/dat2/dcr.xml') but it does not return the content of child DCR.

ENV : TS 6.7.2, LS 3.1

Keep in mind, this URL to your DCR will not work in a LS Runtime environment. It is consists "iw-cc/meta........". Just something to consider if you plan on using LS Runtime.

Alternate approach might be to read / load that additional DCR(s) via External / Controller.

cute_guy

Try this:

[PHP]

[/PHP]
The key where I think you went wrong is that /iw-cc/ attempts to wrap the output with the visual preview toolbar. The no-injection path ensures that you get to the file directly.

I tried your suggestion of using ".../iw/cci/meta/no-injection/iw-mount/default/main/...", even then i don't get the dcr content

We are not planning to use LS runtime Smiley Wink

And no plans of using external component either.

Murugan_P

I tried your suggestion of using ".../iw/cci/meta/no-injection/iw-mount/default/main/...", even then i don't get the dcr content

We are not planning to use LS runtime
And no plans of using external component either.

I used to do this in my PTs.

Not sure whether this will work with component xsl. Anyways have a try.



[font=Courier New][xsl:variable name="dcrpath"] Y:/default/main/.../STAGING/templatedata/.../data/mydcr.xml [/xsl:variable]





[xsl:value-of select="document($dcrpath)/rootcontainer/field1" /]
[/font]

replace ' [ ' , ' ] ' with ' < ' and ' > ' respectively.

But as VPatel said, this will cause problem in runtime or target servers.

cute_guy

I used to do this in my PTs.

Not sure whether this will work with component xsl. Anyways have a try.
[font=Courier New][xsl:variable name="dcrpath"] Y:/default/main/.../STAGING/templatedata/.../data/mydcr.xml [/xsl:variable]





[xsl:value-of select="document($dcrpath)/rootcontainer/field1" /]
[/font]
replace ' [ ' , ' ] ' with ' < ' and ' > ' respectively.

But as VPatel said, this will cause problem in runtime or target servers.

For this to work I have to preview the component from Teamsite server itself , but I will be preview from one desktop/cllient browser & not on the actual server, in that case the desktop will not have Y: drive the dcr will not be there, so xml content cannot be fetched.

That's what happened when tried it before.

Adam Stoller

For this to work I have to preview the component from Teamsite server itself , but I will be preview from one desktop/cllient browser & not on the actual server, in that case the desktop will not have Y: drive the dcr will not be there, so xml content cannot be fetched.

That's what happened when tried it before.

Instead of using Y:/default - you could try using //IWSERVER/default - though I'm not sure that the overall idea is all that sound....

cute_guy

Instead of using Y:/default - you could try using //IWSERVER/default - though I'm not sure that the overall idea is all that sound....

Using //IWSERVER doesn't work either

Rick Poulin

In that case, just write a simple external class to load the DCR. Shouldn't be that complex to write, and it's probably the best way to go for future-proofing anyway.

miroperez

Depending on direct access to the file system is not a good idea. If we decide to change the way files are accessed or stored your code will break. You should write an external to do this in a generic way.

What are the objections to using an External? Seems like in the time you've invested in trying to work around you'd already be done if you used an external.

cute_guy

Depending on direct access to the file system is not a good idea. If we decide to change the way files are accessed or stored your code will break. You should write an external to do this in a generic way.

What are the objections to using an External? Seems like in the time you've invested in trying to work around you'd already be done if you used an external.

Problem is that we are not given the access to create and deploy java codes to that server, the client creates DCRs and deploy them to DB, contents are fetched by app server code to render the pages in portal.

We are trying to show the sitepublisher capabilities with the DCRs, in that course, we came across this block, where we needed help from experts on the Devnet forum.

miroperez

Do you even need an external? If you use a DCR Datum in your components the selected dcr's xml is available for processing in the xsl. Can you simply select the dcr in a datum then write the appropriate xsl in the component to display what you need? That dcr is user selectable on the component that's dropped on a page. Unless you need the dcr selected programmatically somehow, then you don't need the external.

Look at the examples in Component Guide site under */sites/Component Guide/Marketing/Content/FormsPublisher Content.page. It's the first component in the list.

I'm not sure what you mean by the dcrs are sent to a db on the appserver, but if they are, I don't see any way you would be able to get to them without some sort of external if that's were they are stored. The above technique will work for sitepub and livesite runtime.

Hope this helps.