Change Details

Currently, Wikibase\Repo\Api\EditEntity::getChangeOps hard-codes what kind of information can exist in an entity, along with knowledge about how that information is represented in the input data. To allow entity types that have additional fields, we need some sort of plugin mechanism that allows EditEntity::getChangeOps to construct change-ops for the non-standard parts of the entity. Outline of how the plugin mechanism should look like as of 06.01.2017: - there should be a ChangeOpDeserializer interface introduced for services that process serialized change ops and return ChangeOp instances. Initial version of the interface has been introduced in https://gerrit.wikimedia.org/r/#/c/329376/ (already merged), with a bit different approach proposed in https://gerrit.wikimedia.org/r/#/c/330698/, - API\EditEntity should not know any details of how to generate change ops from the json-array-like input. It should be done by ChangeOpDeserializer instances. - Entity type definitions should provide a new property (work-in-progress name "changeop-deserializer-callback") that would allow EditEntity (and potentially other classes) to instantiate ChangeOp objects relevant for the particular entity type. - All item- and property-specific code currently in Api\EditEntity::getChangeOps would be moved to relevant ChangeOpDeserializers and to item and property type definitions. - entity type definitions of new entity types (MediaInfo, Lexeme) would declare instantiation of their own specific ChangeOp objects, no longer being bound to labels, descriptions etc. - Note: initially we have been considering that entity type definition would expose some callback to Api\EditEntity. That would a function getting in serialized entity change data s provided in API request, and return a ChangeOp instance. Given how ChangeOpDeserializer is modelled now maybe it would make more sense to have a property in entity type definition called "changeop-deserializer" (without a "callback" prefix) that would instantiate the actual ChangeOpDeserializer. That might be cleaner and easier to analyze? Patches for review: * [ ] https://gerrit.wikimedia.org/r/328357 * [ ] https://gerrit.wikimedia.org/r/331609

Currently, Wikibase\Repo\Api\EditEntity::getChangeOps hard-codes what kind of information can exist in an entity, along with knowledge about how that information is represented in the input data. To allow entity types that have additional fields, we need some sort of plugin mechanism that allows EditEntity::getChangeOps to construct change-ops for the non-standard parts of the entity. Outline of how the plugin mechanism should look like as of 06.01.2017: - there should be a ChangeOpDeserializer interface introduced for services that process serialized change ops and return ChangeOp instances. Initial version of the interface has been introduced in https://gerrit.wikimedia.org/r/#/c/329376/ (already merged), with a bit different approach proposed in https://gerrit.wikimedia.org/r/#/c/330698/, - API\EditEntity should not know any details of how to generate change ops from the json-array-like input. It should be done by ChangeOpDeserializer instances. - Entity type definitions should provide a new property (work-in-progress name "changeop-deserializer-callback") that would allow EditEntity (and potentially other classes) to instantiate ChangeOp objects relevant for the particular entity type. - All item- and property-specific code currently in Api\EditEntity::getChangeOps would be moved to relevant ChangeOpDeserializers and to item and property type definitions. - entity type definitions of new entity types (MediaInfo, Lexeme) would declare instantiation of their own specific ChangeOp objects, no longer being bound to labels, descriptions etc. - Note: initially we have been considering that entity type definition would expose some callback to Api\EditEntity. That would a function getting in serialized entity change data s provided in API request, and return a ChangeOp instance. Given how ChangeOpDeserializer is modelled now maybe it would make more sense to have a property in entity type definition called "changeop-deserializer" (without a "callback" prefix) that would instantiate the actual ChangeOpDeserializer. That might be cleaner and easier to analyze? Patches for review: * [x] https://gerrit.wikimedia.org/r/328357 * [x] https://gerrit.wikimedia.org/r/331609 * …

Currently, Wikibase\Repo\Api\EditEntity::getChangeOps hard-codes what kind of information can exist in an entity, along with knowledge about how that information is represented in the input data. To allow entity types that have additional fields, we need some sort of plugin mechanism that allows EditEntity::getChangeOps to construct change-ops for the non-standard parts of the entity. Outline of how the plugin mechanism should look like as of 06.01.2017: - there should be a ChangeOpDeserializer interface introduced for services that process serialized change ops and return ChangeOp instances. Initial version of the interface has been introduced in https://gerrit.wikimedia.org/r/#/c/329376/ (already merged), with a bit different approach proposed in https://gerrit.wikimedia.org/r/#/c/330698/, - API\EditEntity should not know any details of how to generate change ops from the json-array-like input. It should be done by ChangeOpDeserializer instances. - Entity type definitions should provide a new property (work-in-progress name "changeop-deserializer-callback") that would allow EditEntity (and potentially other classes) to instantiate ChangeOp objects relevant for the particular entity type. - All item- and property-specific code currently in Api\EditEntity::getChangeOps would be moved to relevant ChangeOpDeserializers and to item and property type definitions. - entity type definitions of new entity types (MediaInfo, Lexeme) would declare instantiation of their own specific ChangeOp objects, no longer being bound to labels, descriptions etc. - Note: initially we have been considering that entity type definition would expose some callback to Api\EditEntity. That would a function getting in serialized entity change data s provided in API request, and return a ChangeOp instance. Given how ChangeOpDeserializer is modelled now maybe it would make more sense to have a property in entity type definition called "changeop-deserializer" (without a "callback" prefix) that would instantiate the actual ChangeOpDeserializer. That might be cleaner and easier to analyze? Patches for review: * [ * [x] https://gerrit.wikimedia.org/r/328357 * [ * [x] https://gerrit.wikimedia.org/r/331609 * …