WS.AX.DocGen.OfferteService.txt

FYI :
Bij een volgende uitbreiding van deze If-else, zullen we best de impl afzonderen in aparte method (of klasse).
Bvb. wanneer Revego (of eenvoudig maatwerk) erbij komt, kan de eerste if zijn :

if Not(GeefFamilie() = "Lade") then ... else ... 

Of als je dat nu reeds wil doen, feel free

FYI:
We hadden samen bekeken, in welke klasse we Mat-materiaal best zouden toevoegen.
Het is nu pas, tijdens review, dat me opvalt dat deze klasse (met "...Omschrijving" in de naam) NIET taalafhankelijk is, maar dat is dus eerder toevallig, omdat LBX, TAX en TBX in alle talen hetzelfde is.

Het had zeker niet verkeerd geweest om deze klasse verder uit te breiden met vertaling en MatMateriaal. My bad!
Voorlopig zullen we het hierbij laten. De huidige oplossing is zeker ook oké.

Is uw probleem natuurlijk, ge moet lezen wat er staat...

Bij AssertEquals() is het derde argument enkel zinvol als je daar een uitleg wil schrijven.

Met Asserts zoals hierboven lijkt het al gauw op

 	$$$AssertEquals(StreamSize, "") 

Dat staat er natuurlijk niet, maar mijn dislectisch brein interpretteert dit wel zo :-\
Ook met de andere Asserts in deze klasse heb ik moeite om snel te begrijpen wat er getest wordt.

Wil je de lege Comments in de Asserts (alle in de hele klasse) verwijderen?

Uw voorganger heeft niet proper gedaan
Vandaar mijn vraag of je hier het Boyscout principe wil toepassen? Merci Jo.

Deze assert (van uw voorganger) kan VEEL specifieker en veiliger :

	Do $$$AssertEquals(Stream.Size, StreamSize + (9*25 ))   ; i.e. "*" komt 9x per lijn voor, er zijn 25 lijnen.  

Wil je deze aanpassen? Thx.

Beter :
Replace naar "Line ... AA" of naar "Line ... 00" , want "Line ... 99" bestaat reeds vooraleer iets ge-replaced wordt --> werkt wel, maar is een beetje misleidend.
(wellicht ook in de volgende testmethods).

Twee belangrijke opmerkingen (dit is de vhisie van WV en JCL):

• input params zijn enerzijds te beperkt en anderzijds te specifiek : "MailOpdracht" -> beter een algemene "Opdracht" met ook "Render-opties" object [ Te bespreken met WV/JCL]
• OrderData is OK, maar de structuur moet een "propere" dto zijn die AX moet invullen, en wij zullen er in caché dan wel de bizarre "pxMemo"-structuur (e.d.) van maken
  Let wel: VH legt de propere structuur vast (eventueel met overleg met ADU)

Zelfde opmerking geldt uiteraard voor Offerte- en LeveringService.

Het "Resultaat" vind ik nogal kort door de bocht :

Technisch beschouwd :
Het resultaat van "Render" is een pdf-stream
Het resultaat van RenderAndFile is een bestand (of een error) --> ObjResultaat.BestandVolledigeNaam en ObjResultaat.ErrorMessage
Het resultaat van RenderAndMail is een OK of een error --> ObjResultaat.ErrorMessage
Het resultaat van RenderAndPrint is een OK of een error --> ObjResultaat.ErrorMessage

Conclusie:
ook al is "RenderAndFile" voorlopig de enige die resultaat MET inhoud teruggeeft, toch zou ik het result-object dus specifiek benoemen, iets zoals hierboven,
eerder dan RenderResultaat.DocNaam

Ook een property MailReplyTo bijvoegen (omdat de meeste mails vanuit de server verstuurd worden)
Dit principe moeten we meer en meer gaan gebruiken, om te vermijden dat de replies naar "CacheAdmin@..." worden gestuurd.