Taorbox

ook hier beter een exceptie raisen ipv een wlipke

BatchService injecten en testen voorzien die het gedrag van een true of false antwoord op BestaatBatch illustreren, dan had het gedoe hieronder niet naar boven gekomen

bovenstaand stukje is wreed tricky.
In principe gebruiken we hoe dan ook geen early quits, want die maken het lezen/volgen van code moeilijker.
Wat gebeurt er met ErrorMessage? Niets
In mijn testgeval gaf BestaatBatch blijkbaar een false en er is niets in resultaat/exception dat daarop wijst. De code geeft zelfs een 200 terug op hoger niveau

wlipkes galore! (zie lager)

als je dus een exceptie smijt in de lagere stukken, dan kan deze reutemeteut ook weg

#dim resultaat as %String

hoe dan ook: in VerwerkKlantEtiketAfdrukken wordt resultaat nergens ingevuld en zal het altijd een lege string zijn, wat een beetje zijn doe voorbijschiet



beter een exceptie laten smijten in de lagere regionen

Hier nog eens checken of als er dnacodes in zelfde batch zitten moeten die in dezelfde file geprint worden. dit nog eens checken. Misschien moet hiervoor nog aanpassing gebeuren want in print hadetik zij else kant worden wrs gwn de dnacodes direct in 1 file gezet en geen rekening gehouden met de dnacodes die in zelfdfe batch zitten en dus samen in 1 file moeten komen because performatie

Hier moet aantal dus altijd 1 zijn. Want in initiële print moet als ..geefLijnAantal > 1 dan moet er eigenlijk per etiket ook een andere dnacode zijn wat nu niet het geval.

Kan je heel deze method eigenlijk niet vervangen door 1 call naar de repository waar je een method "ZoekViaMeerdereDnaCodes" toevoegt die dan een zoekviafilter met een "in" ipv een "=" doet? Just wondering hoor, kan zijn dat dat niet werkt, maar het zou het natuurlijk wel een heel stuk simpeler maken (en geen aparte hoop testen nodig)

om als lezer exact te weten wat dit eigenlijk allemaal doet, moet je de testen voorzien

Vervang de early quit op de derde lijn hoe dan ook al door eentje op de eerste lijn. Quits moeten niet in het midden staan, enkel helemaal bovenaan of onderaan

##class naar constructor
DnaCode="" --> $$$HasLength(DnaCode)

$isObject en desnoods ook een .HasNext()

(ben niet in onderliggende code gaat zoeken, misschien weet ge het antwoord direct)
lopen we hier niet het risico dat we voor elke DnaCode in de iterator een bestandje krijgen?

en ook: als we afdrukken met een dnacode er op, moet het aantal altijd 1 zijn (zie opmerking een beetje hoger)

Ik weet dat dit stuk van KCA komt, maar hier klopt toch iets niet hoor. Stel dat we met 1 product hier binnenkomen, zonder DnaCodeIterator... dan gaat die ..GeefDnaCode ergens een bijna willekeurgie DnaCode uit zijn mouw schudden om dan mee te geven aan een etiket dat Aantal keer afgedrukt kan worden. Dat mag eigenlijk nooit gebeuren! We mogen geen etiketten met gelijke DnaCodes meermaals afdrukken (tenzij natuurlijk eentje kapot was en een gebruiker expliciet dat ene etiket opnieuw afdrukt)

Beter een $isObject gebruiken (doet in principe hetzelfde, maar is duidelijker)

Btw, wat als er een empty Iterator wordt meegegeven, dan gaat er helemaal niets gebeuren. Willen we dat (open vraag hoor)? Ik neig toch om er nog een .HasNext()-achtig stukje bij te zetten

hier moet ik eigenlijk zeggen dat we (in nieuwe stukken) niet meer werken met de DomeinContext, maar de klasse zelf gewoon Newen (in de constructor van deze klasse natuurlijk, wat trouwens ook zo zou moeten zijn als je wel via de DomeinContext werkt: gebruikte klassen altijd in de constructor opzetten)

TODO's doen of comment wegsmijten

heeeeeee, hier staat het in commentaar. comments wegsmijten

nonononono. copy-paste gevalleke van de proboxlogica denk ik
de product/klantetiketten moeten op vaste printers in de halux-bureau afgedrukt worden. De proboxetiketten worden op printers aan het einde van elke lijn afgedrukt en gebruiken daarom die mapProductieLijnOpPrinter

testen van elke method voorzien (die van de probox kunt ge al moven vanuit vhUnitTest.WSimpl.Halux.AAP.DnaCodeService.ProboxEtikettenAfdrukken.Test)

mag weg vanop de DnaCodeService