Class
Specific data classes implement the method like this:
This is fine, as long as one such data type does get used for only one source data type, if it does get used for multiple source data types this does not work as a unique relation source
In order to still use the system in such cases, it is necessary to create new classes like
This seems like always reinventing the wheel.
I'd therefore like to suggest smth. like this
This would allow importer implementations to easily set the required import type (if the specific data classes are also changed accordigly) without having to extend the data classes.
XF\Import\Data
has an abstract method getImportType
that returns the string to be used for import logs.Specific data classes implement the method like this:
PHP:
public function getImportType()
{
return 'thread';
}
This is fine, as long as one such data type does get used for only one source data type, if it does get used for multiple source data types this does not work as a unique relation source
oldId
=> newID
is required per data type.In order to still use the system in such cases, it is necessary to create new classes like
XFI\Import\Data\vBulletinBlogText
, XFI\Import\Data\vBulletinBlogAttachment
, XFI\Import\Data\vBulletinBlogUser
.This seems like always reinventing the wheel.
I'd therefore like to suggest smth. like this
PHP:
abstract class AbstractData
{
protected $importType;
public function getImportType(): string
{
if (!is_string($this->importType))
{
throw new \LogicException("importType must be a string");
}
return $this->importType;
}
public function setImportType(string $importType): void
{
$this->importType = $importType;
}
}
This would allow importer implementations to easily set the required import type (if the specific data classes are also changed accordigly) without having to extend the data classes.
Upvote
1