adrianheine added a comment.
I think we could re-use and generalize that ›statement group‹ term if we would
want to. It's only used in Wikibase view, Wikibase datamodel JavaScript and one
location in Wikibase client. I have a hard time coming up with a better name
for the general concept instead. We could use ›partition‹ instead, making the
service class interface something like `StatementListPartitioner`, but that
feels really awkward compared to `StatementGrouper`, considering that the
latter is just a special case of the former.
As for the infrastructure in JS, it seems necessary for the approach I would
take. The problem we need to solve in JS is that our views basically need two
inputs: The data model object they are representing (`this.options.value`) and
the DOM element they are working on (`this.element[0]`). These must match,
obviously. Currently, we traverse the entity and the DOM and expect both to
match. That's not completely wrong, but it's not so great either. Introducing
multiple statement sections would be reflected in the DOM, but not in data
model entity. So we need a way to order and group the data model data so that
it matches the DOM. My proposal would be to do that in
`wikibase.view.StatementSectionsView` using a `StatementGrouper`. So,
`StatementSectionsView` would get the `wikibase.datamodel.StatementGroupSet`
(basically a hash map from `propertyId` to `StatementList`) and build a list of
`StatementGroupSet`s using the `StatementGrouper`.
Another approach would be to ditch `wbEntity`, just follow the structure of the
DOM and pass the editable data model objects in a flat structure, i. e.
`wbEntityStatements = { guid: wb.datamodel.Statement }`. The `statementview`
would then either fetch its `Statement` object from a store it got passed in
using the guid that's represented somewhere in the DOM or some factory would
inspect the DOM, grab the guid, fetch the `Statement` object and give it to the
`statementview`. That's a quite some work to implement, would probably be a lot
nicer, but would probably also mean that we won't be able to easily construct
an `entityview` without DOM. Something we don't do anyway, currently. I'd
prefer to not tie identifier sections to that change, if we actually want to do
it, though.
TASK DETAIL
https://phabricator.wikimedia.org/T117421
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: adrianheine
Cc: Lydia_Pintscher, Aklapper, Sjoerddebruin, Liuxinyu970226, Ltrlg,
Daniel_Mietchen, Ricordisamoa, Legoktm, Pigsonthewing, Filceolaire, PKM, Laddo,
Sannita, Addshore, Multichill, Bene, Tobi_WMDE_SW, Snaterlicious, thiemowmde,
adrianheine, Micru, jayvdb, MGChecker, DSGalaktos, Agabi10, Zolo,
Wikidata-bugs, aude, Mbch331
_______________________________________________
Wikidata-bugs mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
