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; } } }

XML Mapping error

bturns

TS 6.5 SP2
Solaris 2.8

Hi There,

I'm running into an issue where an already saved DCR is missing data when being opened for an edit.

I've created a datacapture using a custom dtd. I would like to have a container in my datacapture that does not map to an xml field when saved. The container is there simply for presentation. When the DCR save everything looks good. The extra container is ignored.

However, when I open up the dcr I'm unable to see the fields that were previously saved. The extra container is getting in the way. Has anyone tried this before?

Find more posts tagged with

Comments

Adam Stoller

TS 6.5 SP2
Solaris 2.8

Hi There,

I'm running into an issue where an already saved DCR is missing data when being opened for an edit.

I've created a datacapture using a custom dtd. I would like to have a container in my datacapture that does not map to an xml field when saved. The container is there simply for presentation. When the DCR save everything looks good. The extra container is ignored.

However, when I open up the dcr I'm unable to see the fields that were previously saved. The extra container is getting in the way. Has anyone tried this before?

My guess is that you cannot have a container without it having a location - and that's what's causing the problems. You *might* be able to specify the same location as the root-container, but my guess is that will end up causing a nested level instead of using the already existing level -- but it's worth a try.

Sales.rptdesign

bturns

My guess is that you cannot have a container without it having a location - and that's what's causing the problems. You *might* be able to specify the same location as the root-container, but my guess is that will end up causing a nested level instead of using the already existing level -- but it's worth a try.

Thanks Ghoti. I tried that and just as you suspected it created a nested level. I guess I'll just remove it if there aren't any more suggestions. Just curious, would you consider this a bug. It seems like the whole point of having the "location" item is for a reason such as this. Otherwise why not use "name"?

Thanks,

BT

Adam Stoller

Thanks Ghoti. I tried that and just as you suspected it created a nested level. I guess I'll just remove it if there aren't any more suggestions. Just curious, would you consider this a bug. It seems like the whole point of having the "location" item is for a reason such as this. Otherwise why not use "name"?

Thanks,

BT

I don't think I'd consider it a bug, more likely an aspect of the design / implementation and something you could file a feature request for. Do not confuse the fact that 'name' and 'location' are almost always the same as a reason for the implementation to use the one instead of the other. They're probably the same for 95% to 99% of the DCTs created with datacapture6.0.dtd - but there's still the 1%-to-5% in which they may be different (although, honestly, I cannot think of a good example or reason for this, so - perhaps one could argue it as a bug / flaw in the design...)

Regardless, to do what you want, you'd need a FR for being able to specify a magic string to the location attribute or an additional attribute which, if set, would treat that structural element as if it didn't exist at all when reading / writing data from / to the DCR - but would still recognize it when rendering the DCT form. (I think you'd need a real good use-case for this to gain any kind of momentum though)