[Import] Support importing the XML format we export to (names are attributes, not elements)

[dkarlovi]

Q	A
Bug report?	no
Feature request?	yes
BC Break report?	no
RFC?	no
Branch?	master

[dpfaffenbauer]

a better explanation pls, also examples would help.

[dpfaffenbauer]

Well, PR?

[dpfaffenbauer]

Thinking about it, it is not 100% possible to support it, since you have interpreters that will transform your data, so you have to have reverse interpreters in some way. also, what if you create sub-arrays of your data in an interpreter, we cannot really read multi-dimensional data.

So, it would only work for the first level of properties anyway.

[blankse]

@dpfaffenbauer I have following use case:

1. I want export objects
2. Change field name or make these translatable (This remove the data)
3. Import the objects to the new fields

So I have also seen, that the interpreter are often only for the import reason:

• assets_url
• href
• multi_href
• ...

There are no counterpart. Shouln't be every interpreter have a method for import and export? Or declared interpreter for export or import. So not all are available. Do I overlook something? If not, I can do a PR

[dkarlovi]

@dpfaffenbauer I mean more like, we should be able to natively map the data into something, don't mean it has to be using the same profile. :)

[dpfaffenbauer]

There are counterparts for those if you really think about it:

assets_url = expression href = expression multi_href = iterator + expression

I know what you mean, but we cannot 100% make every interpreter work in both directions. Thats also not intended, if you need to do exports and then imports with ImportDefinitions, you can, just map it yourself correctly.

[blankse]

Yes with iterator and expression (value ? value.getId()) I could create counterparts. But I need new interpreter for import now. I create 2 PR for this.