Verbinders.cls.xml

Tja, een groot deel van de code heeft Sam overgenomen van mijn oude code, vandaar (idem voor notaties als ... '= ... )
Maar ik deel de mening van Tom : gebruik gerust onze "moderne" coding-conventions

Ja, o.a. voor Toepassing, ProductieWijze kan je de enu-waarden vinden in de excel-file : E:\svn\Files\trunk\Excel\Halux_Apps_Data\KAD Res.PIItems.xls
Ook voor ProfielPlaats zou je een enu kunnen maken (hiervan bestaat geen persistente klasse)

ge zijt uw testen vergeten committen

oneliner? zie een of ander ander kaartje dat ik vandaag gereviewed heb

algemene opmerking: je hebt hier in 1 commit verschillende dingen gedaan: enus gebruiken, kleuren veranderen, refactorke hier en daar. Maak er volgende keer gerust een hoop kleinere commitjes van

ge moet u echt niet inhouden om variabelen een langere naam te geven

hiep hoi

misschien in een apart kaartje: al die strings "LPR", "GL", ... enz zouden misschien beter in een enumeratie gestoken worden. Er bestaan er nu al een hoop in DOM.PM.enu.KAD*

geen ' maar $$$Not gebruiken (staat op meerdere plaatsen blijkbaar)

anders moet ge misschien eens ctrl-shift-f doen voor een single quote

Het zal waarschijnlijk iets SVG gerelateerd zijn, maar ik als leek weet niet wat Vcode is. Kan een andere naam de lading beter dekken? Of moet ik eerst maar wat meer SVG stuff leren? Vooral hieronder Vcode = 2 en Vcode = 1 zegt me echt niets

Gingen deze "higher level" componenten ook naar een Factory of niet?

zou het ok zijn om de ID en transformatie toe te voegen aan de "maak" method? Dan reduceert ge de lengte van deze methods een stuk en worden ze misschien gemakkelijker leesbaar? In de "maak" zelf wordt er namelijk ook al met de group gespeeld.

ik denk dat ge uw testen vergeten committen zijt

moeten deze twee methods geen private method zijn?