[XMLPort] How do I give an Element linked to a Table a value?

Hello helpfull people,

Following is part of my XML export:

  • labels Element (Text)
    • label Element (Text)
      • type Attribute (Text)
      • options Element (Text)
        - quantity Element (Text)
      • values Element (Text)
        - value Element (Table → myTable)
        - key Attribute (Text)
        - type Attribute (Text)
        - language Attribute (Text)

I would like the following xml:

1 MyValue

I use code to retreive the information I need for the “key”, “type” and “language” attributes
by using " key := ‘bla’ " in the Export::OnBeforePassVariable function.

The problem is that it isn’t possible to say " value := ‘bla’ " because value is already linked to a table.

How can I insert a value into the value element tag without changing my xml output?

Many Thanks

Jamie Bosmans

What exactly is “MyTable” in this case ?
If it is what I would think, then the key, type and language attributes are fields within that table ?

If so, why do you use seperate variables for these?

MyTable is just a table I created with some fields in it. Key, type and language variables are not fields in that table though, they need to be calculated using the fields of the table.

For example the MyTable contains fields like “id” and “caption” then I ,for example, type " key := MyTable.id + ‘.’ + MyTable.caption ". and it would export that line as:

My question is : how do I get a value assigned to the “value” element while it is attached to MyTable?

Thanks for any help or insight provided

There are Triggers under each data element where assignments can be made.

Do you have the XMLPort Designer granule on the licence and can you see the Triggers?

[:)]

I shall try to clarify with images. Sorry if my information wasn’t clearly worded.

picture 1 : http://users.skynet.be/fa100155/dynamicspic1.jpg the xmlport designer. You can see that the “value” tag is linked to the RetLabel Variable table (previously named MyTable here) and that it has some attributes. I can assign these without a problem but I also want a real value in the “value” element tag.

Currently the xml outputs this :

But I want this kind of output : MyValue here </ value>

How can I let the XMLPort export the “MyValue here” text?

Picture 2 is the current code. http://users.skynet.be/fa100155/dynamicspic2.jpg

Hi,

the Output you want should look like this: <value key=“something” type=“xs:string” language=“1033” MyValue here </ value> (There is a > too much in your line).

Apart from that, I do not think you can achieve this result with the XMLPort Designer. Can’t you use an Attribute for the “MyValue”?

My XML is correct , there should be a > there.

But no the external party is not able to change its XML input.

Dynamics NAV should be able to handle this, or is it not completely compliant with XML structures?

Otherwise how would you import an element value if it also has attributes? for example : value

That would be possible if it were a regular text element. In your example it is a table element though, which is what makes it an issue.

Exactly :slight_smile:

Can I confirm that this is indeed impossible in dynamics nav?

To your XML: Sorry, I stand corrected.

Well impossible is a strong word. You can’t do it with the XML-Port. You can always do it the “old fashioned way” - writing a file (from a Report) with FILE.WRITE. Or you can write the XML-File with the XMLPort and the “MyValue” as an Attribute, open the resulting File and delete the offending Text (programmatically that is of course).

Thanks for your help.

What a shame that dynamics nav doesn’t support this. It doesn’t seem like a big thing to code.

I’ll accept the answer since it seems to be the only way.

What are you talking about? Yes NAV does support this, you just have to structure your XMLPort to be able to accept your XML. Use text elements instead of a table element and deal with the values in the XMLPort triggers.

Accept my XML? Not sure what you mean there.

It’s an export not an import and if I change the “value” element to text instead of table, I don’t think it will be exporting the attribute values key, type and language.

So far all NAV experts have told me it isn’t possible, if you believe they are wrong please let me know how to work around this issue.

You said “NAV doesn’t support this”, and I am saying it does. You have been given a number of alternatives to accomplish your goal, and you insist on making snide remarks. Yes you can get your XML to export exactly like you want. I still think it should be possible with an XMLPort, but you might have to program some of the values yourself.

You use an XMLPort to create an XML document. You call the XMLPort from another object, and create this XML Document. You can then access everything inside this XML document and manipulate it exactly the way you need. So the ‘Value’ element does not have values coming out of the XMLPort, it would be an easy thing to loop through those elements and fille them based on the attribute values after the fact.

Don’t say “NAV doesn’t support this”, and claim that it is “not compliant”, when all it is going on here is that YOU don’t know how to do it.

For the record, I am not saying anyone is wrong here, just that there are more ways than one to skin a cat

The only possible way is to use the MSXMLDOM automation object for this purpose.

It requires a little bit more coding but can be done easily.

Examples on how to deal with these automation server objects can be found in the codeunits in Navision which have “XML” in their names.

You can still use an XMLPort to get you 95% of the way and use MSXMLDOM to set the value node. I would probably add the value as a separate element to the XMLPort, and manipulate that into the value element after the fact.

What I object to is blanket statements like “NAV doesn’t support this”, or “it is impossible to use XMLPorts for this”

DenSter : What are you talking about? I expected more professionalism from this board to be honest.

My first topic and I already get flamed for things I didn’t do. Saying something isn’t supported is not a snide remark.

And according to other people both in this thread and at my workplace it is not possible to do this in the XMLPort. This means that the XMLPort doesn’t support the full range of options that are available to XML, which is what I said.

With an attitude like that I would prefer that you didn’t post in this topic anymore.

To all the rest: Thanks for the help. Solution is not to use the xmlport or to process the xml file afterwards so that it will show exactly what you need.

We’re all passionate about NAV. [:$]

Trust me, if I were flaming you, you’d know, we’re having a friendly disagreement. The snide remarks I am talking about was your comment about me when you said something about “all the NAV experts are saying this” and basically saying that I am wrong because you found some people that contradict me. I’m not going to go down that path. When I said “what are you talking about” I was asking “what are you talking about”, because you were drawing the conclusion that something “is not supported by NAV”, when it really is. Don’t put words into my mouth. Think what you want, I’m not going to change that.

You can read between the lines all you want, but I’ve spent significant time on this thread to try to help you. You clearly need some help here, and I thought I might help you move ahead a little bit. Some people in here are saying you can’t use XMLPorts for this, I say you can, you just need to do a little more than that. The alternative is to program the entire XML yourself, which will be much more work. Suit yourself though, it’s not my project.

If you don’t appreciate my help then don’t take it. Calling me out like this and questioning my “professionalism” is… wel… unprofessional [:)]. It doesn’t matter really, you’re not listening to what I’m trying to say anyway.

Let’s take it this way:

XMLports are a powerful tool which solve a lot of challenges but it is not the perfect tool for creating and reading all types of xml files.

There is a always a number of ways to solve a problem a Navision programmer is facing. In this forum, each specialist suggests a solution which is - according to his/her experience - the most logic/easiest/best/whatever way to solve the problem.

I for myself find the XMLDOM easier to use, more flexible and faster to develop than the XMLports.

In the end it is up to the starter of the thread which way to go or which solution to try.
There is no need to put any snide remarks to a post as everybody is answering the questions in a good mood and not to put someone into a wrong direction on purpose.
Contradictions are the natural way of learning - and that is the reason for (hopefully) all of us to contribute in this forum.