Using core importer routines to import pages/stacks/global areas?

[mlocati]

The core is able to export and import pages/stacks/global areas in CIF format.

When the Migration Tool (MT for short) is used to export the data to a CIF file, it uses the core functions.

But when MT is used to import data from a CIF file, it extracts the info it contains, and executes some code that's almost the same as the one we already have in the core.

Instead of maintaining the same code twice (both in the core and in the migration tool), what about the following approach?

1. when MT reads the elements of the CIF file (for example, a <page> element) it still extracts some details (eg for checking if there are problems and for showing the users some info about the stuff being imported).
2. instead of extracting every data from CIF, MT stores the whole XML element (eg, the <page> element with all its attributes and child nodes)
3. instead of running some code like this, we create a SimpleXML element on the fly and pass it to the core functions (like this)

Other importers (like the one that imports data from WordPress) can simply create the XML with the data being imported.

[aembler]

This sounds nice in theory, but the migration tool doesn't just import into its own data structures for fun. It has to enable mapping between attribute types, attempting to transform data it doesn't understand, allow you to pick and choose which things you want to try and include into the batch, etc... I'm not clear on how this change would impact how the migration tool works today.

[mlocati]

If the migration tool has to change (for example) the handle of an attribute type, it can generate a simplexml element on the fly with the changed attribute type...