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

6.1 FormAPI - broken?

Adam Stoller

TS/TST 6.1 (build 33333) - Solaris 8

I have an "old-style" DCT with the following piece in it:<item name='Article Section' label='Article Section'>
<description>...</description>
<replicant required='f' min='0' default='1' max='1000'>

<item name='Page Break Indicator'>
<description>...</description>
<radio required='t'>
<option value="1" label='Yes'/>
<option value="0" selected='t' label='No'/>
</radio>
</item>
</replicant>
</item>I also have some FormAPI code with the following section of code in it - and I've added the indicated alerts() for debugging purposes:function init() {
// ... omitted for brevity ...
radioItem = IWDatacapture.getItem("/Article Section[1]/Page Break Indicator");
alert("#=# radioItem = " + radioItem);
if (radioItem.getValue() == null) {
alert("#=# radioItem Value = " + radioItem.getValue());
radioItem.setValue(1);
alert("#=# [post] radioItem Value = " + radioItem.getValue());
}
// ... omitted for brevity ...
}
The first alert shows up fine#=# radioItem = [object Object]The second alert shows up fine#=# radioItem Value = nullThe third alert does not show up and consequently, I can tell, the rest of the FormAPI code is not executed.

This code worked in 5.5.2.
This code worked in 6.0L
This code does not seem to be working in 6.1 (build 33333).

Any ideas?
Is this something specific to my environment or a bug in the 6.1 release?

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Find more posts tagged with

Comments

Sri

Fish,

Do you get any javascript errors? A strange thing is that the radio button has an option selected by default. I wonder why getValue() returns null.?

Sri

Adam Stoller

I agree - it's strange - the form appears to load without any errors (no error indicator in the bottom-left-hand-corner of the IE window) and yes, it does seem strange that the value would be null when it should have a pre-selected value (but perhaps that's an ordering thing?)

I'm curious if anyone else with 6.1 can [not] replicate this odd behavior.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Adam Stoller

(rather lengthy post ...)
After working with Support on trying to diagnose this problem further, I believe I've figured out what's happening - and while it might be claimed to be user-error, the code does work on 5.5.2 SP2b, but does not work on 6.1 and thus it can still be considered a bug.

There are 3 parts to this problem, the DCT, the FormAPI code, and (as I figured out tonight) the DCR.

I have attempted to simplify the code a bit - it could probably be further simplified, but this appears to be sufficient to replication the problem. I have changed item names to be smaller but maintained the space-laden names (pre-dates my involvement with the DCTs).

The DCT looks something like this (feel free to adjust the location of the javascript source):

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE datacapture SYSTEM "datacapture5.0.dtd">
<data-capture-requirements type="content">
<ruleset name="article">
<script location="webserver" src="/iw-mount/default/main/WORKAREA/astoller/formapi/article.js"/>
<item name="A S" label="Article Section">
<replicant required="f" min="0" default="1" max="1000">
<item name="O L">
<select required="t">
<option label="1" selected"t"/>
<option label="2"/>
<option label="3"/>
</select>
</item>
<item name="URL A N">
<text required="f" size="50" maxlength="50"/>
</item>
<item name="S H">
<text required="f" size="55" maxlength="255"/>
</item>
<item name="P B I">
<radio required="t">
<option value="1" label="Yes"/>
<option value="0" label="No" selected="t"/>
</radio>
</item>
</replicant>
</item>
</ruleset>
</data-capture-requirements>

The FormAPI code can be simplified to something like this:

function init(){
var tmpI1 = IWDatacapture.getItem("/A S[1]/URL A N");
alert("BEFORE i1 = " + i1.getValue());
i1.setValue("TEST1");
alert("AFTER i1 = " + i1.getValue());

var i2 = IWDatacapture.getItem("/A S[1]/P B I");
alert("BEFORE i2 = " + i2.getValue());
i2.setValue(1);
alert("AFTER i2 = " + i2.getValue());

var i3 = IWDatacapture.getItem("/A S[1]/S H");
alert("BEFORE i3 = " + i3.getValue());
i3.setValue("TEST3");
alert("AFTER i3 = " + i3.getValue());
}
init();

The key part which I identified tonight is the shell of the DCR. Before I get to the actual code, let me explain a bit about the process involved here (which I believe is fairly common and not solely specific to our implementation).

DCRs are only to be created via a workflow. The workflow takes care of determining the category/type and name/location of the DCR, and also takes care of pre-populating some of the fields based on other input the user has provided (these fields are not included in these code examples as they are not relevant right now). Thus when the user gets to actually edit the DCR that they are creating, it already exists in a "shell" format.

Okay - now this is what the shell looked like on our 6.1 system:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE record SYSTEM "dcr4.5.dtd">
<record name="article_shell.xml" type="content">
<item name="A S">
<value>
<item name="O L">
<value>1</value>
</item>
<item name="URL A N"/>
<item name="S H"/>
<item name="P B I"/>
</value>
</item>
</record>

With a pre-existing DCR shell as above - the FormAPI code will break right after the i2.setValue(1);

Without a pre-existing DCR shell - it all worked! Thus I realized it had to be the pre-existing shell that was the source of the problems.

I looked on our 5.5.2 system, and it was actually different there.
Instead of: <item name="P B I"/>
It was: <item name="P B I"><value></value></item>

So I decided to work my way up to that:

1-BREAKS: <item name="P B I"/>
2-BREAKS: <item name="P B I"></item>
3-BREAKS: <item name="P B I"><value/></item>
4-BREAKS: <item name="P B I"><value></value></item>
5-WORKS: <item name="P B I"><value>0</value></item>

Although I had different code (1) on the 6.1 system, when I made it look like the 5.5.2 system (4) where it works on 5.5.2 it still did not work on 6.1. Only by changing it to (5) did it work.

So - it is still [presumably undocumented] behavior which has changed between 5.5.2 and 6.1 which may catch other developer's unaware and thus is still (IMO) a bug.

I'd even suggest that all 5 of the options above should work - and will be willing to hear a detailed explanation of why they should not.

At this point, I know how to fix my code - but I have asked that this officially registered as a bug with my case associated with and tracking it.

(As a note to one of the earlier queries - the fact that the DCT specified a default value for the field was overridden by the fact that the "shell" did not.)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

What do you mean, fix the code? What is wrong with it?

Adam Stoller

I mean I can fix the DCR shell to have an explicit default value (see '5' in the previous post) rather than just a place-holder (as in items '1' through '4' - which, by the way, the DCR shell started with '4' but had values prepopulated using TeamSite::XMLnode - and *that* module was responsible for changing the shell from looking like '4' to looking like '1')

If I make that change to my DCR shell - the javascript code will work as-is.

I still maintain it is a bug (Support is doing some further investigation) based on the fact that it worked in 5.5.2 *and* that it works for simple text fields, but breaks on a radio-button field. When I get a bug ID I'll post it for anyone else who's interested in registering interest in seeing it fixed.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com