EconNaarApps

TestFiles reviewen, is in dit soort stories bijna onbegonnen werk. Ik heb zo goed en zo kwaad mogelijk de changes bekeken.
Alvast bedankt om het aantal testfiles te filteren.
Het geheel lijkt me wel oké te zijn.

Ook in eCon enkele commits gereviewed.

De dossiercode "LI7K" was blijkbaar een onbedoelde tussenstap (Tricky situatie met de TAOR Losse componenten)
In combinatie met svn rev. 69413 is dit wel een correcte overgang.

Hierbij is deze change nagekeken en goedgekeurd!

Ge ziet niets over 't hoofd :-D Ge hebt helemaal gelijk! Is een 1-op-1-property, dus mag automatisch geconverteerd worden. In tegenstelling tot DwarsverdelingAantal, want daar is de property-naam verschillend (cq. AantalDwarsverdelingen in APPS).

Aangepast naar "Dwarsverdelingen te picken"

Als opmerking in de kantlijn (dus je moet niks aanpassen) : hier moeten we eigenlijk gebruik maken van het berekende HalffabItem en daarvan de (bewerkte) lengte opvragen. Nu staat er duplicate logica.
Maar ik geloof best, zonder het na te kijken, dat in deze klasse nog code staat die vertrekt van de ingegevenKenmerken i.p.v. halffabItem.

DwarsverdelingKleur zit volgens mij "impliciet" in de ConverteerGegenereerdeProperties()
hiervoor is geen "uitzondering nodig".
Tijdens de uitbreidingsfase en review lijkt het me handig om te zien dat beide properties zijn toegevoegd. Maar eenmaal in productie (en ondersteund door automatische testen) kan dit het standaard pad volgen.
Of zie ik iets over t hoofd?

Tekst correct?
Zonder kar --> geen vakken, right?

Er bestaan nog extra testen voor convertoren, je moet es kijken naar mijn commit 68434, daar staan bijna alle in behalve 'appsnaarecon', das de enige wss

Ah oke, op deze manier heb je het opgelost haha, al de comments voor niets . Ik heb daar nog altijd mijn bedenkingen bij om het onder die Data.bomkenmerken te brengen, we verliezen zo toch wel een simpel overzicht over alles zoals blijkt uit mijn opmerkingen, maar dat is mijn mening

Als stuklijst hier niet moet verwerkt worden moet die wel worden toegevoegd aan bovenstaande Converteer method. Anders zal er helemaal niets gebeuren voor deze property

Stuklijst heb je gestoken onder Data.bomkenmerken en niet data.kenmerken. Deze method gaat code genereren, je moet maar eens kijken in de gecompileerde versie van deze klasse. Daar ga je op regel 182 zien wat ik bedoel

Ik heb me hier al vragen over gesteld of het bij de mat (en mss ook de rest als ik er nu over nadenk) ook niet verkeerd zit. Bij LBX heb je daar die Clone ervan en ga je niet de oorspronkelijke kenmerken overschrijven. Hier werk je zonder clone en ga je eigenlijk het oorspronkelijke object verder aanvullen. Dit is niet echt gewenst gedrag aangezien we dan ook mogelijks een andere canonische waarde uitkomen verder in de flow. Dat zit allemaal jammer genoeg heel tricky in elkaar :|. We willen eigenlijk gewoon het object een beetje manipuleren vooraleer we het sturen naar .net maar we willen die aangepaste versie niet opslaan in de DB. Veiliger zou zijn om eigenlijk een convertor te hebben in .net maar dat is net het probleem dat we hier oplossen

TBX kenmerken