Thoughts on importing fields with multiple subfields?

[rheingolden]

I'm working on a fork of the https://github.com/designermonkey/addresslocationfield extension to update it to support the importableField and ExportableField interfaces and I was wondering if anyone has any thoughts on the best / a standardized way that a field that has multiple sub-fields might be im/exported using this extension?

My core question is around how/if we can present an user interface in the importer builder page that would allow a user to map an existing arbitrary XML structure to the address field's sub-fields. It has been easy enough in implement prepareImportValue() to process a hard-coded XML format, but I wondering if there is anyway to make it more flexible. Could a field extension "publish" information about it's subfields to this extension, so multiple xpaths inputs could be specified instead of just one?

Would love to hear your thoughts on how to add import/export to a field like the address location field with maximum flexibility in the most "Symphony" way possible. Thank in advance! Let me know if one of the forum threads might be better place for this kind of conversation.

[brendo]

Interesting. So the idea that the Duplicator actually may have multiple 'fields' to help deal with the 'sub fields' of a Field, so:

• Address Field
• Address Field: Suburb
• Address Field: City
• Address Field: Postcode

Not a bad idea. It would some changes to 'collapse' all of these sub values into a single value to maintain support with the existing processRawFieldData and setDataFromPost functions, but as that logic would sit XML Importer side I don't think it's too much of a problem.

I'm guessing this hasn't been brought up sooner because we have few fields that actually implement sub fields. I know for Meta Keys a strange format is supported to help prefill multiple values. This could be applied here as well, but admittedly it's definitely not as elegant!

[andrewminton]

This also applies to the password field of members if I'm not mistaken. The checkPostFieldData() function tries to find the array of 'password' and 'confirm' when attempting an import, but that is obviously not available from a standard remote datasource feed. Keep on getting an offset string error when attempting to import data from old DB system into an updated build.