WMDE-leszek added a comment.
There's been no update here since a year. Here is what's there now, to have an overview:
One can create form/sense using wbeditentity, either by:
new=form/new=sense and data containing lexemeId=L123, or
id=123 and data containing element in forms or senses that has t
gerritbot added a comment.
Change 374524 abandoned by WMDE-leszek:
[DNM][POC] Demonstrate how possibly API class could allow handling "hierarchical entity IDs".
https://gerrit.wikimedia.org/r/374524TASK DETAILhttps://phabricator.wikimedia.org/T172192EMAIL PREFERENCEShttps://phabricator.wikimedia.o
Addshore added a comment.
Create those using wbeditentity
+1 as said previously.
Clients should be able to re-use code for creating different kinds of entities
Forms and Senses should be treated just like other entities, for consistency
All APIs that create or edit entities must consistently ap
gerritbot added a comment.
Change 374524 had a related patch set uploaded (by WMDE-leszek; owner: WMDE-leszek):
[mediawiki/extensions/Wikibase@master] [DNM][POC] Demonstrate how possibly API class could allow handling "hierarchical entity IDs".
https://gerrit.wikimedia.org/r/374524TASK DETAILhttps
Aleksey_WMDE added a comment.
We also can have this knowledge in only in the presentation layer (HTML/API), but not in the object model and serialization.TASK DETAILhttps://phabricator.wikimedia.org/T172192EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Alekse
daniel added a comment.
In T172192#3493920, @Aleksey_WMDE wrote:
... That's actually part of the data model specification.
As I understood it is not set in stone, or is it?
It was discussed over and over, and has become part of a spec. Nothing is using the spec yet, but we'd have to have a very
Aleksey_WMDE added a comment.
... That's actually part of the data model specification.
As I understood it is not set in stone, or is it?TASK DETAILhttps://phabricator.wikimedia.org/T172192EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Aleksey_WMDECc: Jakob_
daniel added a comment.
Some points from my side:
Clients should be able to re-use code for creating different kinds of entities
Forms and Senses should be treated just like other entities, for consistency
All APIs that create or edit entities must consistently apply the appropriate checks for pe
daniel added a comment.
Form/Sense class should not reference Lexeme in any way (neither on object level, nor having LexemeId as a part of it's ID). I can see how this can improve maintainability
I strongly disagree. Forms and Senses must have the Lexeme ID as part of their ID. That's actually par
Aleksey_WMDE added a comment.
Points to consider:
Request structure is strict and can be easily converted to class/struct in statically typed programming languages
JSON Request (if any is present) structure can be described with json-schema (for better documentation and easier validation)
IDs of
Aleksey_WMDE added a comment.
It would be nice if everyone wrote points that he/she thinks are important to consider to make a decision.TASK DETAILhttps://phabricator.wikimedia.org/T172192EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Aleksey_WMDECc: Jakob_WM
11 matches
Mail list logo
