dto

Zijn deze lijnen in commentaar nog relevant?

Samengesteld ipv SamenGesteld

'Dotnet' -> Encoway

ProductApi is nergens gedefinieerd als input parameter, dus deze inject is niet nodig

Ik zou dit niet als constructor porperty meegeven, want nu moet je overal waar je de VHConfigHelper wilt gebruiken, eerst hem initialiseren in de code zelf. Op die manier kan je moeilijker de vhconfighelper injecteren.

Er is wel de method 'ZetVhConfig', maar die moet je dan eerst aanroepen vooraleer je de andere methods kan gebruiken. Ergens lijkt mij dat wat zot, omdat je dan snel fouten kan maken

Mijn gevoel is om dit ook in een aparte klasse te plaatsen en onder test te steken (ook al zal deze klasse dan vrij klein zijn)

Talen kunnen eventueel in een aparte enu?

Variabele naam aanpassen naar Encoway ipv dotnet

Variabele naam aanpassen naar Encoway ipv dotnet

Testje bijgezet als AttrVsAdminProdNr niet SalesPriceBOM is => dan moet er betreffende de ProductIdRecycleerder niets gebeuren.

Ik vond dat nogal overkill, omdat die list dan amper een codelijn of 6 later alweer omgezet zou moeten worden naar een delimited string. Moest de omzetting naar delimited string in een andere method gebeuren, dan zou ik het zeker gedaan hebben

Ook zoals aan telefoon besproken... het gaat over de LadeVariant zoals gekend in AX, waarvoor overal in de BOMBOL de AXimpl gebruikt wordt.

Zoals besproken aan de telefoon: Dat Request komt in de BOMBOL-interface ook al binnen als parameter, dus de afhankelijkheid is sowieso al een feit. Bovendien wordt er 1 laagje hoger ook een andere property van uitgelezen

ikzelf probeer constructies als deze meestal te vermijden omdat het om de zoveel tijd wel eens kan leiden naar een rariteit met die delimiter. Misschien beter om een list te gebruiken? Kunt ge gewoon op adden indien nodig. Een list kan daarna 'gewoon' in een delimited string omgezet worden indien nodig.

minor nitpicking: ik las dit als een Event "OnJadajada" en het duurde toch een fractie van een seconde voor ik doorhad dat dat niet echt logisch zou zijn indeze context. Een kleine "B" was misschien logische geweest. Nogmaals: kommaneuken hoor

een beetje in de trand van de vorige opmerking: zou het niet properder zijn om de DOM....LadeVariant te gebruiken (qua hiërarchie hé). Je gaat dan wel een 'converter' moeten opzetten die de AX-variant omzet naar een DOM-variant, maar daar kan de LadeVariantBepaler zich mee bezighouden. Op die manier verdwijnt de dependency op AXimpl.* package

Van deze request wordt enkel Request.Attribute gebruikt. Het zou beter zijn om die attribute als parameter mee te geven, anders introduceer je een (extra?) afhankelijkheid tss WSimpl en AXif packages.