DomNaarDotnet.cls.xml

Was nu ook nodig, goed dat je meedenkt!

Kzou zeggen: niet vergeten die convertoren nog eens manueel te compileren nadat ge een GL hebt gedaan
Dat is bij mij toch al wel vaker nodig geweest.

FYI: iedere keer wanneer een kenmerk wordt toegevoegd aan de canonische waarde dient in productie een herbereken van de hashes te gebeuren. Anders kunnen er problemen optreden bij het opslaan van kenmerken. Op zich komen die problemen niet veel (nooit) voor maar beter deze info toch even delen dan later voor rare verrassingen te komen staan.

Misschien is het overzichtelijker om hier nog een tussenvariabele te gebruiken zodat het makkelijk is voor iemand die er niets van kent? 'AantalStuks' = LijstMetIdentNummers.GetAt(Index) ofzo, is maar een idee

Juist wat in het oog houden dat niet te veel maatwerkspecifieke methods hier komen te staan. Een afzonderlijke klasse kan nooit kwaad maar bij TBX is het ook wel wat uitgebreid precies Het is maar een mededeling, niet per se een opdracht

Heb wat zitten zoeken in .Net om om lege strings naar 0 de defaulteren, maar vond het niet direct. Is dan maar op deze manier gebleven tot er eens wat meer tijd is om naar te kijken (ik heb er een kaartje van gemaakt dat het niet uit het oog verloren wordt)

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