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

FormAPI issue with elements created with '<inline>' script

rajit

Hi

Our DCT has an 'inline' subelement that invokes a script to read a config file and generate form field on the fly.

I want to control the visibility of these 'dynamic' form fields, but the 'IWDatacapture.getItem()' doesn't seem to get hold of these fields. It always returns null, while it works perfectly fine for other fields on the form.

Has anyone encountered this issue? Any suggested solutions will be greatly appreciated.

Regards,
Rajit
____________________
TS 672 on Windows 2k3

Find more posts tagged with

Comments

Faizi

Hi

Our DCT has an 'inline' subelement that invokes a script to read a config file and generate form field on the fly.

I want to control the visibility of these 'dynamic' form fields, but the 'IWDatacapture.getItem()' doesn't seem to get hold of these fields. It always returns null, while it works perfectly fine for other fields on the form.

Has anyone encountered this issue? Any suggested solutions will be greatly appreciated.

Regards,
Rajit
____________________
TS 672 on Windows 2k3

Hi,
Would you attach your DCT and JS file? This will help to find the problem.

Thanks,

rajit

Hi Faizi,

Thanks for your response. Here is some more information:

DCT:

[html]

Specifications Tab

[/html]

Output of the inline script by reading an external file:

[html]

Product Lines

Spec1

Specification Value 1

[/html]

FormAPI access:


var speccontainer = 
IWDatacapture.getItem("/prod_details/spec_tab/specifications_container");

The JS variable 'speccontainer' seen above, always ends up as 'null'. So basically the 'Item' object for an element created using an inline script is turning out to be null.

I hope this gives you an idea.

Thanks in advance for your inputs.
Rajit

PS: One more observation, I am able to register the 'onItemChange' event on another field that is also generated by the inline script. But when I try to get the 'Item' object for the same element using 'getItem()', I get null.

Adam Stoller

Hi Faizi,

Thanks for your response. Here is some more information:
[...]
The JS variable 'speccontainer' seen above, always ends up as 'null'. So basically the 'Item' object for an element created using an inline script is turning out to be null.

I hope this gives you an idea.

Thanks in advance for your inputs.
Rajit

PS: One more observation, I am able to register the 'onItemChange' event on another field that is also generated by the inline script. But when I try to get the 'Item' object for the same element using 'getItem()', I get null.

So - according to what you posted - your DCT looks essentially like this:

<container name='spec_tab'>
  <item name='prod_line'>...</item>
  <container name='specifications_container'>
    <container name="set0">
      <container name="spec_container0">
 <item name="specval1">...</item> 
      </container>
    </container>
  </container>
</container>

And the only FormAPI you provided here is:


var speccontainer = 
IWDatacapture.getItem("/prod_details/spec_tab/specifications_container");

Is it safe to assume you are working with an "iwov" style DCT?
Are you sure about the first element of that xpath (/prod_details) - it's not shown in your posted code?
You are not providing any context to the FormAPI snippet - Is this being called from within an

init()

function? How is the init() function being invoked, etc.

Frederik

wild guess. Is this in an onLoad? is the DCR opening with containers collapsed?

I seem to vaguely remember from long ago, that if replicants are collapsed on opening, then they aren't fully rendered and not fully added to the Item tree, and therefore you can't getItem() them... Could be sth similar.

rajit

Hi Ghoti and Frederik,

Thanks for your responses.

Yes, it is an 'iwov' style DCT.

xpath is correct, the whole structure was not shown for brevity. Only the affecting container is shown.

Here is the script section of the DCT:

[html]
<script>
function init()
{
IWEventRegistry.addItemHandler('/prod_details/spec_tab/prod_lines','onItemChange',showcontainer);

}

function showcontainer(item)
{
var speccontainer =
IWDatacapture.getItem("/prod_details/spec_tab/specifications_container");
}

IWEventRegistry.addFormHandler("onFormInit", init);

</script>
[/html]

In my initial attempts, the script-generated elements were in invisible state when the form loaded. On facing the issue, I also tried keeping the containers visible. Yet, the getItem() doesn't seem to reach the 'inline' script-generated elements.

Even the 'getChildren()' function run on the 'spec_tab' container (that encloses the inline statement) also gives only one child, which is the 'label'. It completely ignores the remaining containers(that are generated by the script) under the same parent.

Your thoughts and help on this issue is appreciated.

Thanks,
Rajit

ISCBorisB

Hi Ghoti and Frederik,

Thanks for your responses.

Yes, it is an 'iwov' style DCT.

xpath is correct, the whole structure was not shown for brevity. Only the affecting container is shown.

Here is the script section of the DCT:

In my initial attempts, the script-generated elements were in invisible state when the form loaded. On facing the issue, I also tried keeping the containers visible. Yet, the getItem() doesn't seem to reach the 'inline' script-generated elements.

Even the 'getChildren()' function run on the 'spec_tab' container (that encloses the inline statement) also gives only one child, which is the 'label'. It completely ignores the remaining containers(that are generated by the script) under the same parent.

Your thoughts and help on this issue is appreciated.

Thanks,
Rajit

Unless it's just a typo you may have singular/plural naming discrepancy
. . .
<item name='prod_line'>
. . .
IWEventRegistry.addItemHandler('/prod_details/spec_tab/prod_lines', 'onItemChange', showcontainer);

rajit

Hi ISCBorisB,

The typo was only in the post here, the actual code is consistent.

Anyways, the primary problem is with getting the 'specifications_container' item.

Thanks!
Rajit

ISCBorisB

Hi ISCBorisB,

The typo was only in the post here, the actual code is consistent.

Anyways, the primary problem is with getting the 'specifications_container' item.

Thanks!
Rajit

Forms Publisher renders 'inlines' before parsing the DCR. As far as FormAPI is concerned, there is no difference (and
absolutely no way to tell) which items were included in the original DCT Form and which were 'substituted'.

If I were you I would temporarily insert your inline output into DCT. Eg, just for testing remove inline. Put what it generates
right into DCT. Does it work now?

If it doesn't - you've eliminated one complexity factor and can concentrate on debugging by changing configuration, not code.
If it does - may be your inline renders something different than what you think it does. Log out inline's output right before it ends and
see if that's what you expect

rajit

Hi ISCBorisB

Thanks for the suggestion about testing with the inline input temporarily inserted into the DCT. It ruled out the possible problem of inline-generated elements being handled differently by FormAPI than normal elements.

I continued to face the issue after inserting the expected inline output. On closely examining the element hierarchy, I noticed that the 'spec_tab' was a replicable container (min=0, max=1).

Then I was able to address the children of spec_tab with the replicant index appended (../spec_tab[1]/...) in the IWDatacapture.getItem() function.

The strange thing however is :

IWEventRegistry.addItemHandler(): This function expects the path to be mentioned without the replicant index. For ex. the path '/prod_details/spec_tab[1]/prod_line' failed to work, and was generating JS errors

IWDatacapture.getItem(): This fucntion expects the path to be mentioned along with the correct replicant index, which was the reason why the getItem() was earlier returning null. After the path was changed to '/prod_details/spec_tab[1]/prod_line', things worked fine.

Not sure if this works this way for some reason, or its a bug.

Anyways, thanks everyone for the valuable help!

Regards,
Rajit

Firenze

While your inline call appears to be working, the datacapture6.0.dtd does not allow inline at the location you are using it. This would indicate to me that possibly other Forms Publisher features may not work correctly either.

ISCBorisB

While your inline call appears to be working, the datacapture6.0.dtd does not allow inline at the location you are using it. This would indicate to me that possibly other Forms Publisher features may not work correctly either.

DTD notwithstanding, you can use an inline Tag just about anywhere in the DCT. As long as the final *assembly* result is
a correct DCT you will be Ok. For example, this KB article illustrates inline usage to allocate shared DCT Fragment to
various DCTs. You can emit entire DCTs in this manner if that's what you want.