Bug: existing DCR lose content, when field added in DCT to container with no location

We noticed the following bug on TeamSite 6.5 sp2 + patch 1767 on Solaris 9

Support has confirmed this also applies to TS 6.7.1 SP1. I've noticed a post on the forum where this applies also to tabs.

GIVEN
- a TeamSite form (DCT) of

dcr-type="xml"

(in templating.cfg)
- with a container in a DCT, where location attribute is missing or blank:

. (both produce the same XML schema)
- the container has a 1+ items in it
- and you have created some DCR for this DCT v1

THEN
- if you ADD a field to this container, in the DCT (v2)
- and you open an pre-existing DCR, built under the DCT v1
- then all the fields in that container will be blank. In other words, it will not show the pre-existing content in the pre-existing items.

WORKAROUNDS
- the bug does not occurs with dcr-type="iwov" (but there are many good reasons to want xml type)
- the bug does not occur if there is an named location

. But that changes your XML structure and might not conform to a predetermined XML DTD. Note, that the location is an optional attribute as per the datacapture6.0.dtd
- update all pre-existing DCR, add a blank field for new items in the container. (but that's extra work)

SIMPLIFIED EXAMPLE

DCT version 1:
[HTML]

<br />

[/HTML]

DCR for DCT version 1:
[HTML]

Test
[/HTML]

DCT version 2 (adds a new item in the container):
[HTML]

[/HTML]

Will post a bug number when available

Find more posts tagged with

Comments

Adam Stoller

I think the bug is in the DTD - and that location should really be required for containers (as it is for root_container, as pathid is for items) - and that if it is used as such, you won't run into this problem.

Of course, given that I provide the same value for name and location for all my containers and the same value for name and pathid for all my items - it would be nice if neither location nor pathid were required and that they'd "do the right thing" if omitted -- but I always provide those attributes to my DCTs....

Frederik

I think the bug is in the DTD - and that location should really be required for containers

well, I disagree. I want to have the flexibility of creating a container (as a visual element that helps guide end-user's attention), without being forced to see that container in my resulting XML as an element, which is just what

location=""

offers. And it works fine too, as long as you don't add a new item in such a container. So I would say that this is a feature with a bug, rather than a documentation (DTD) bug.

Anyway, the bug number is TS-5704. ETA for fix unknown.

gzevin

I think the bug is in the DTD - and that location should really be required for containers (as it is for root_container, as pathid is for items) - and that if it is used as such, you won't run into this problem.

Of course, given that I provide the same value for name and location for all my containers and the same value for name and pathid for all my items - it would be nice if neither location nor pathid were required and that they'd "do the right thing" if omitted -- but I always provide those attributes to my DCTs....

yes, this is what I do as well. Just duplicate the name and location.

Thanks goodness that at least this bug has passed me this time Smiley Happy