Kas 2581 pub proof documents tab

[ghost]

Jira
kaleidos-project pull-request
Build #67

Issues:

• timestamps op file zijn created en modified: ik wist niet welke ontvangst en welke upload-timestamp waren.
• De filename wordt blijkbaar niet meer server-side bepaald. Dit moet dan ook op andere plaatsen (vb. BatchDocumentPublicationModal) aangepast worden.

Test data
Er is een methode generateTestData in de documents-route. Deze verwacht dat er al 6 pieces in de database zitten. In de modelhook kan deze gecalled worden.

Note voor review
De modal "Nieuwe aanvraag" moet nog niet gereviewed worden.

Verklaringen

• Waarom heb ik een Row-object aangemaakt?

  • alle pieces in 1 call door 'publication-subcase' te querien.
  • geen calls naar 'publicationSubcase' of ander related model per document (includes worden blijkbaar genegeert in omgekeerde richting)
  • Het hangt ook samen met het gebruik van prov:used & dossier:genereert in de backend: mu-cl-resources lijkt het onderscheid niet te begrijpen als pieces dezelfde relaties/predicates hebben voor verschillende resources.

  Een alternatief had geweest:

  • drie queries naar 'piece' (sourceDocuments, proofingActivity.generatedPieces, publicationActivity.generatedPieces).
  • 'include' had dan correct gewerkt.

• unique-id helper: een manier om een id te genereren in de template in een #each loop. (Ember RFC)
  Dit was nodig om EmberPopover te laten werken.
  Er is ook een polyfill voor: npm

• buildIncludeString-functie:

  • een javascript object maakt het voor mij veel leesbaarder dan een include-string. Ik heb al regelmatig vergissingen begaan bij het schrijven van zo'n string.
  • maakt het ook mogelijk dynamisch fragmenten (zoals de file-relationship van een piece) te includen.
    werking is geinspireerd op store.query(...)'s filter-parameter.
    Dit kan in een utils/file.js.

• #method()-notatie is nieuwe JS voor private fields: MDN documentatie

[ghost]

Michael had me dit geschreven in de chat

Nadat ik je pull-request (#965) nog eens (met je toegevoegde verduidelijkingen) doorlopen heb, kom ik tot de conclusie dat nog enkele aanpassingen nodig zijn om in lijn te komen met de meest toegepaste patronen binnen onze app. Tegelijkertijd kan ook de leesbaarheid hier en daar beter. Ik zou je willen vragen om:

1. de model-hook te herwerken zodat this.model objecten van het type Piece bevat (je gaf aan dat hiermee ook de custom object weg kunnen. Indien dit kan graag, maar het is geen must)
2. de include statements meteen binnen de query als dasherized strings uit te schrijven (buildIncludeString kan daarmee weg)
3. de sortering binnen de route (als deel van de model-hook) af te handelen
4. de test-data generatie in de finale versie van de PR te verwijderen.

1 + 3

• Hangen samen met het toevoegen van relaties naar de verschillende types activiteiten in het Piece-model. Erika raadde aan dit niet te veranderen.

2 + 4

• done

Kan iemand me meer duidelijkheid geven of mijn aanpassingen voldoende zijn?

[erikap]

Ik begrijp niet goed waarom 1 + 3 samenhangen met het al dan niet definieren van de inverse relaties?
Deze route gedraagt zich anders dan de meeste andere routes, maar is wel heel gelijkaardig aan de translation-documents route. Bekijk die dus zeker eens als referentie. In deze route wordt een niet-gepagineerde, volledige lijst van documenten samengesteld in de frontend op basis van verschillende queries naar de backend. Dat impliceert dat de sortering van die lijst ook in de frontend moet gebeuren. Ik begrijp niet waarom die inverse relaties daarvoor noodzakelijk zijn?

[ghost]

Noodzaak voor de inverse relaties is het negeren van includes door ember-data als ze in de omgekeerde richting worden opgevraagd: dit is nu het geval in vertalingen: er is een publication-subcase-request per piece.
Michael had daarom voorgesteld om 3 calls te doen: 1 per piece-relatie. Hiervoor had ik de inverse relaties nodig: dan zouden de publication-subcase-relaties wel gedetecteerd worden door Ember Data.
Mij leek het best om het zo te houden, ook al returnt hierdoor de model-hook iets anders dan verwacht.

[erikap]

Dan zou ik voor de aanpak gaan die @MikiDi voorstelde en de inverse relaties wél definieren (met inderdaad een custom predicaat voor iedere relatie). Ik denk ook dat dat het issue gaat oplossen met de 'verdwijnende' documenten tussen de aanvragen en documenten tab dat je meldde op de chat, omdat de cache dan correct gecleared zal worden wat nu niet het geval is, vermoed ik.

[ghost]

• 1: Opgesplitst in 3 calls op piece als model.
• 3: sort gebeurt in controller om dubbele sort-code te vermijden

Rebuild Jenkins#73