Problem with dynamic tables, XML schemas, and JavaScript

[bmillhaus]

With the XML schema applied my JavaScript does not work correctly when a 2nd row is added to my dynamic table. Instead of a blank row being added the data from the 1st row is copied to the 2nd row and if you change the data in the 2nd row it changes the data in the 1st row also. It works fine if the XML schema data connection is deleted though.

Any idea what I can do to get this working with the schema applied the same way it works without the schema?

Thanks for your help,

Brian

[_Nith_]

Why don't you use data connection but without binding the those fields in the table?

See the modified PDF attached and give it a try to verify the functionality.

Nith

[Former Community Member]

I am not seeing that behaviour in your form. Can you tell me what steps you are taking to reproduce the problem as well what version of Acrobat/Reader are you using?

Paul

[bmillhaus]

If I open the form in Reader and enter data in the quantity and estimate unit price column it correctly calculates the amount for that row. But if I add another row instead of a blank row being produced the data from the previous row is reproduced. If I change that data it also changes the data for the previous row. The grand total field is correctly calculated though.

I am using Reader 9.1.3

[bmillhaus]

That seems to work but when the form is saved the only data saved is the first row's data so it really isn't a solution for me.

[Former Community Member]

OK I think I see the issues. There are 2 of them.

1. By clicking the + button to add rows to the form you are changing the state from when the form was 1st launched. This means that when the form opens again you must basically redo the things that you have done. There are two ways to do that. You can keep track of it yourself and right code to take care of it or you can have the product do it for you. In Designer under the File/Form Properties/Defaults tab there os a radio button selection that determines what you want to do. On your form it is set to manual meaning that you will take care of it. Change it to automatic and the changes will be stored and set for you when the form opens.

2. You created a datasource (import of a data structure. This means that you can only export data in this structure. I woudl delete that data source and ensure that all fields have a Binding of Normal. Note that the fields on the Master page are all set to none and will not be saved. Changing them to Normal will include them.

I have included my modifed sample for your parusal.

Paul

[Former Community Member]

Hi Paul,

Brian and I work together on this project.  Thanks for your help with Brian thus far.  I do have a broader question directly related to this.  Many of our forms will be rendered in Workspace and most will be pre-populated from an Enterprise database.  To make this easier, especially with the 'query to XML' service, we want our forms to have a 3 level xml structure.  To ease the pre-population and the data extraction, we decided to create xml schemas for all our forms and bind to xml schema. Some of our form developers have created forms where each field has been wrapped in a subform, so that the lines automatically appear on the form.  The extensive use of subforms has altered the default xml structure so much, that we decided that we really do have to use data connections.

My questions to you would be:

1) Should we wrap each form field in a subform in order to have lines automatically on the form?

2) Is there a best practice in terms of using data connections to sml schema in order to more easily pre-populate and extract data in the form?

Thanks!

[_Nith_]

I faced similar requirements. All of my form needs to be pre-populated with some information from an external DB (for e.g the Jobtitle, Passport number etc).

To achieve this I created a fragment (which contains all fields need to be pre-populated by the render).

A special feature of fragments is, the form developer cannot rename the fields inside the fragment.

In this case, the SOM remains same for all forms. And there is a consistency too.

From the render, I populated all necessary data to the fragment's fields. Later I'm making use of those fields.

Make sense?

Regards,

Nith

[PetPel]

Try this thread:

http://forums.adobe.com/thread/521743?tstart=0

I think it might help you.

[Former Community Member]

The data structure does not have to match the structure of the form (although it certainly makes it easier f it does). That is what the binding expressions are for. They will match up a field on the form to a node in the xml. If the structures are completely different then you are forced to bind each object one by one (this is called absolute binding). If there is some similarity you can bind a subform object to a parent node and the child nodes will automatically bind to the objects in the subform (this is called relative binding).

Make sense?

In your case it sounds like you wll have to do absolute binding.....but it is difficult to be definitive without seeing the form and schema together.

Paul

[_Nith_]

Nevermind

I still have a long way to go with this schema principals.

Thanks,

Nith

[bmillhaus]

Paul,

I attached the form with the embedded schema.

All by fields are bound to the schema and as was suggested in the thread PetPal referenced I bound Row1, Table1, and the page to None.

When I add a second row to the table the data from the first row is simply copied to the second row instead of the second row being blank. If I change the data in the second row the data in the first row is changed also.

As Eric said, we need this to work in a Workspace environment.

If I unbind the fields in the dynamic table everything works fine but the only data that seems to travel with the form in Workspace is the first row of data and the grandTotal data is changed to reflect that when it is rendered again in the next step of the process.

Thanks again for everyone's help,

Brian

[Former Community Member]

Add a [*] to the end of the binding instruction on each foeld in the Row1 subform. This tells the product that more than 1 row will be used.

Paul

[bmillhaus]

That definitely fixes my problem with the dynamic table, new rows that are added are empty and new data can be added without changing the data in the earlier rows, but my Workspace problem still exists as only the data in the first row seems to travel with the form when it is rendered in the next step.

Should I take this over to the Workspace forum?

Thanks so much,

Brian

[Former Community Member]

I think th eissue might be with your schema ..... those nodes must be set so that they can occur more than once.

I am not a schema expert so I do not know what the actual attribute is.

Paul

[Former Community Member]

The repeating row needs to be set as such in the schema (e.g. P1,Row[*]). Then the fields can be directly bound (e.g. stockNo, amount etc.) if you attach the schema I'll sort it out for you quick. If you cant attach the schema with the .xsd extension, just change it to .xxx and im sure when i change it back on my side it will be fine (I remember reading that in another post somewhere but havent tried it)

[bmillhaus]

Thanks so much for your help. I've attached the schema.

[Former Community Member]

I changed your script slightly. You don't need to use resolveNode if the elements are on the same level. I fixed the schema as well and bound it to the form again. It seems to be working fine now..

[bmillhaus]

Thanks but for some reason I am getting a 'not a valid archive file' error when I try to open the zip file. Could you attach just the form and then the schema as a .xxx file?

Thanks again for all your help,

Brian

[Former Community Member · Accepted solution]

There you go. Its no problem.

[bmillhaus]

That works!

Thanks so much for your help,

Brian