I have a repeating element in the data DOM and need to be able to insert a new element into the list. When I use xfa.resolveNodes("list.item[*]")
I get a list
object and can use list.insert(newItem, list.item(1))
to insert the item before the 2nd item. The list.length increases by one so it appears the insert was successful.
The problem is that the list object doesn't seem to be bound to the data DOM. That is, the item I inserted doesn't show up in the data DOM. My question is, "How can I have the data DOM reflect the changes I make to the list object?" Converting the list to a string using saveXML
doesn't work because saveXML is not a valid method for list objects.
Views
Replies
Total Likes
Hey,
Just a wild (educated) guess here. Try:
xfa.form.remerge(); //javaScript
or
xfa.form.remerge() //formCalc
at the end of your insertion script.
Good luck!!
Stephen
Views
Replies
Total Likes
I know I have to call xfa.form.remerge() to get the changed data DOM to appear in the form _after_ I've updated the data DOM. My problem is in updating the data DOM. I can add nodes using assignNode or loadXML but I want to insert a node into a list at a specific location - which appears to work - but the updated list does not appear in the data DOM, only the original list.
Views
Replies
Total Likes
If the data dom is changed (xfa.datasets.data......) then a remerge happens automatically. This means that your form will revert back to the original state that it was in when it was loaded. I do not recommend changing the data dom. Can you explain why you are changing it and we can see if there is another way?
Views
Replies
Total Likes
That's not been my experience. I've updated the data DOM using loadXML with data from a WSDL connection and the form doesn't display the new information unless I explicitly call xfa.form.remerge(). There's nothing automatic about it, otherwise there'd be no point in making it part of the API. My problem, as I said, is that the list object from resolveNodes("list.writer[*]") seems to be a copy of the 'writer' nodes in the list and not the actual list itself. I can call the list.insert method with a new 'writer' element - let's say there's a child element
New Guy - and the list.length is +1 from the original list. However, if I issue the resolveNodes("list.writer[*]").length = the original length, _not_ +1 as expected. What I'm trying to do is re-assign permits from one permit writer to another. The initial data includes rows only for those permit writers who have been assigned permits. However, the list of writers that appears in the drop-down list has some writers who are new so there is no section in the XML for them. I need to insert a section for a new writer if a permit is re-assigned to that writer. My work-around will be to add the new writers to the original data so I don't have to worry about inserting them. That will mean a little more work on the XSL transform of the SQL query but it's a lot easier than trying to debug JavaScript in Acrobat.Views
Replies
Total Likes
What I meant was if there is a node added to the data dom then the template dom and data dom are automatically remerged and any changes to the template are lost. When you make the WS call there is a parameter on the Execute tabo f the Invoke Button that can force the remerge for you. This is also available through script. But back to your issue .....so if you are putting data into the Dom to not use the Data Dom and then this revert back to the original template will not happen.
The other technique woudl be to use E4X to make a Dom in teh javascript and populate your list from that. There is no means to persist this Dom outside of your script but nce your list is populated you shouldn't need it anyways. (This is the preferred way IMHO)
Make sense?
Paul
Views
Replies
Total Likes
Well I rebuilt the data to include the items I was attempting to insert so that issue has gone away. Now all I have to do is add items to or delete items from a list and think I've uncovered a bug in Acrobat 9.4. I'm using E4X now to avoid a lot of resolveNode calls and it's working like a charm except for one thing: loadXML is not preserving the attributes on the root list node. I have an E4X var that represents a node that has attributes and repeating child elements. Then I use resolveNode to get the DOM node representation and replace it using loadXML. So here's my problem:
// listE4X is the E4X var, listNode is the DOM node returned from xfa.resolveNode
// the DOM node should look like
// <permitList status="Unclaimed Backlog" writer="> No Writer Assigned <">
//
// the following successfully replaces the child elements of listNode but ERASES THE ATTRIBUTES
// (the attributes on the <permitList> tag are lost)
//
listNode.loadXML(listE4X.toXMLString(), true, true);
//
// the following FAILS to rreplace the existing DOM node and instead NESTS the
// <permitList status='xxx' >...</permitList> inside another
// <permitList> tag with NO attributes
listNode.loadXML(listE4X.toXMLString(), false, true);
//
The weird part is that the orignal listE4X variable is obtained using listNode.saveXML() and it has the attributes, so I know the attributes are there (they are also present in the data XML used to populate the form. I've worked around that weirdness by doing the loadXML close to the document root with a node that has not attributes.
BTW there is another place where xfa.form.remerge() is called automatically - after the DataConnection::postExecute event as described here: http://forms.stefcameron.com/2009/03/23/pre-process-web-service-responses/. Thanks for jogging my memory about that.
Views
Replies
Total Likes
Not sure that I follow everything you are talking about there ....but a node that has attributes is not represented that way in the data dom. If I have a node like this:
<permitList status="Unclaimed Backlog" writer="> No Writer Assigned <">
When I load it in the Dom it wil lbe represented as:
<permitList>
<@status>
<@writer>
So the attributes will be represented as child nodes with an @ prepended to it. So if you ask for the permitList node then you will only get the value and not the attributes. If you know tha t the attributes exist you can make a separate call to those child nodes to get the values.
You can see this for yourselve by dumping the Dom into a multiline field and scrolling to the appropriate area to see what is there:
You can use this command to dump the dom to a field:
TextField1.rawValue = xfa.datasets.data.saveXML("pretty")
Hope that helps
Paul
Well, that feature is not very well documented. Can you give me a reference for that information, preferably including a page number? I can't find any information on how XFA treats attributes other than this in http://partners.adobe.com/public/developer/en/xml/data_handling_2.0.pdf:
Some data-loader options cause the data-loader to load only a subset of data from the XML-data-DOM into the XFAdata-DOM. The result is that the ignored data is still in the XML-data-DOM but is not accessible through the XFAdata-DOM. Consequently the XFA application is unable to alter the ignored data. When the data-unloader writes out a new XML-data-document, since the ignored data has been kept untouched in the XML-data-DOM, it is written out in the new document without significant changes. This applies by-default to attributes.
Is there a way to change the default so that the data-loader loads the attributes from the XML-data-DOM to the XFA-data-DOM or should I just forget about using attributes altogether? It's pretty lame to have your tools dictating how you design your XML schemas.
In any case, saveXML
dumps the attributes correctly from the data DOM but loadXML
overwrites the attributes even if the second argument is true
- in which case the JavaScript spec says the root element is ignored. If the root element is ignored why is Acrobat erasing the attributes from the root element (that is, from the reference node)?
Message was edited by: Don@NDEQ
Views
Replies
Total Likes
You are right it is not well documented .....it is an uncommon occurance to have to manipulate the dom. The individual commands are welldocumented but the technique in putting them all together to manipulate the dom is not. That being said there is nothing wrong with loading attributes into the dom ...you just have to know how they are represented. I agree that you shoudl not have to adjust your schema to match the tool.
I woudl like to see how you are using the commands are you able to share your form and the sample data so I can see what is happening?
Paul
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies