| WMDE-leszek edited the task description. (Show Details) |
EDIT DETAILS
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?
...
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?
TASK DETAIL
EMAIL PREFERENCES
To: Ladsgroup, WMDE-leszek
Cc: gerritbot, Jakob_WMDE, WMDE-leszek, Aklapper, Addshore, Ladsgroup, daniel, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331
Cc: gerritbot, Jakob_WMDE, WMDE-leszek, Aklapper, Addshore, Ladsgroup, daniel, Th3d3v1ls, Ramalepe, Liugev6, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
