Op zich goed, maar de WerklijstItemsUitvoerder zou eens een refactor kunnen gebruiken, er zit nu nogal veel logica in voor de mattenlijsten (en de synchrostangen, dat is door mij )
Ik herinner me dat René van Encoway had gezegd dat "Concat()" ook werkt met meer dan 2 parameters : Concat ( str1, str2, str3 ) dan moet je geen 2 concats nesten, en dat leest ook gemakkelijker.
Zeer kleine opmerking, dus jira-kaartje mag op "review klaar" blijven staan.
Classification:
Improvement desirable
Ranking:
Minor
Best diene Partialloadonfloor hier ook nog eens defaulten op 0, want hij wordt in deze method rechtstreeks gebruikt enerzijds en anderzijds wordt hij als parameter in de aanroepende method toch ook al gedefaulted op 0, dus mag consistent zijn, zoals gedaan is bij MinFillPercentage. Kan anders gevaar opleveren als deze private method ooit nog door een andere method gecalled wordt ook, waarin dan deze parameter nergens gedefaulted staat. (= undefined at runtime)
Aangezien ge hier beide mogelijkheden voorziet (injecteren of de echte gebruiken) moet ge dat ook bij de parameter duidelijk maken door die als lege string te defaulten, zoals bij de andere parameters gedaan is. Op die manier, als iemand deze klasse instantieert ergens, ziet die persoon gelijk aan de parameterdefinitie dat die niet per se moet meegegeven worden (en dat dan een nieuwe instantie voorzien is door deze constructor).
Is het niet gevaarlijk die al uit de repo te gaan verwijderen terwijl er nog processen (de calls hieronder) in gang gaan gezet worden, die misschien nog gaan crashen? Moet deze verwijder niet op het einde van deze method uitgevoerd worden (vlak voor het loggen dat hij ermee klaar is)?
Ranking:
Major
Classification:
Not conforming to standards
Hier gebeurt wel heel erg veel op 1 lijn hé Tenminste het product verdient wel een eigen lijn vind ik en dan nog liefst met een ProductRolAPI die in de constructor genewed wordt (en tevens niet van de DomeinContext afgenomen wordt )
Classification:
Improvement desirable
Ranking:
Minor
Deze houdt toch risico in, denk ik, want je geeft normaal een object terug van type DS.Prod.OptiBox.BoxDataMetID, maar de logica laat toe dat dit object undefined is en op de volgende lijn van het stuk code dat deze private method gebruikt wordt er gebruik gemaakt van een property van dit object. Je komt ermee weg omdat de repo daar met lege strings overweg kan, maar 't is niet helemaal correct zoals het hier afgehandeld wordt. Minimaal zou je een leeg object moeten teruggeven, of je moet er nog een "Bestaat..." of "Heeft..." tussen moeten steken.
Ranking:
Major
Classification:
Not conforming to standards
Ook hier gebeurt wel heel erg veel op 1 lijn hé... Tenminste het product verdient wel een eigen lijn vind ik en dan nog liefst met een ProductRolAPI die in de constructor genewed wordt (en tevens niet van de DomeinContext afgenomen wordt )
Dit is net het herophalen van data waarvan we al zeker zijn dat bestaat. We hebben in een vorige stap die data opgezocht. Nu willen we die nog eens gaan uitlezen uit de DB.
De nieuwe BlumPL-personality daar heb ik nog geen Confluencepagina van gemaakt, maar dit is een minimale setup van de vorige waarbij alles klant-gerelateerd weg is.
Ik kan gokken waarom je undefined zet, maar best dat je dit in de commit-message vermeldt. Tip: in de Encoway repository kan je nu ook een commit message wijzigen : rechtste klik - Edit Log Message
Goeie aanpak, alleen vreemd dat je dan geen variabele gemaakt hebt voor "HoogteFrontBevestigingMidden" en "HoogteFrontBevestigingBoven". Dan staat de berekening er ook slechts 1x i.p.v. 2x (links & rechts)
Ik heb ondertussen 2 NietMee-characteristics toegevoegd aan de CustomView van "M_LBX_Model" in de (voorlopige) "ViewSection3" --> doe jij hetzelfde in je 3D-model?
Zou dit interessant zijn om achter een config setting te steken? Als dit de enige wijzigingen zijn voor L5 kan dit ook wel gewoon wachten met naar productie te gaan tot lijn 5 er is natuurlijk, up to you!
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
Naar analogie met "OpvullijstKleur" en "OpvullijstLengte", lijkt me iets beter om "OpvullijstDikte" als varnaam te gebruiken. cfr. "C_BOX_OpvullijstDikte" , deze is (nog) niet beschikbaar in 3D, maar dat is voorlopig oké voor mij.