Checkout Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Correctie : in dit uitzonderlijke geval lukt het niet om af te leiden van TECH.RegisteredObject --> in totaal zullen er 3 klassen zijn die dus afleiden van (%RegisteredObject,%XML.Adaptor)

Correctie : in dit uitzonderlijke geval lukt het niet om af te leiden van TECH.RegisteredObject
--> in totaal zullen er 3 klassen zijn die dus afleiden van (%RegisteredObject,%XML.Adaptor)

Je hebt hier en daar ook nog wat dingen gecommit die te maken hebben met SvgGroups enzo. Is dat iets dat ook in dit kaartje (andere overerving) moet zitten?

Je hebt hier en daar ook nog wat dingen gecommit die te maken hebben met SvgGroups enzo. Is dat iets dat ook in dit kaartje (andere overerving) moet zitten?

afleiden van TECH.RegisteredObject, niet van %RegisteredObject. Ook op een paar andere plaatsen.

afleiden van TECH.RegisteredObject, niet van %RegisteredObject. Ook op een paar andere plaatsen.

mag weg

mag weg

mag deze dan niet volledig weg?

mag deze dan niet volledig weg?

Ook properties asserten, niet enkel de SVG output (idem voor andere testjes hieronder)

Ook properties asserten, niet enkel de SVG output (idem voor andere testjes hieronder)

niet noodzakelijk voor een goeie werking http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/smile.gif (hieronder ook nog eentje)

niet noodzakelijk voor een goeie werking (hieronder ook nog eentje)

dees gaat altijd true zijn, ge hebt hierboven twee items toegevoegd.

dees gaat altijd true zijn, ge hebt hierboven twee items toegevoegd.

[ICT-1196] SVG-013 Factory toepassen op de svg basiselementen
[ICT-1196] SVG-013 Factory toepassen op de svg basiselementen
Wim Vermeulen schrijft uw gedacht ook eens neer ivm het meegeven van values aan de constructor. Sam en ik hebben het er gisteren even over gehad. In theorie is het properder om de constructor enkel...

Wim Vermeulen schrijft uw gedacht ook eens neer ivm het meegeven van values aan de constructor. Sam en ik hebben het er gisteren even over gehad. In theorie is het properder om de constructor enkel objecten mee te geven waarop dependencies zijn. Dan moet elk basisobject natuurlijk wel een "setparams" of "initialize" method krijgen.
Voordeel: testen duidelijker en conform de rest van de nieuwere code
Nadeel: Sam gaat wat door zijn code moeten crossen om het over te zetten (dacht dat het bij het DomElement wel al zo was)

commentaarlijnen kan je beter wegsmijten

commentaarlijnen kan je beter wegsmijten

deze review werd aangemaakt zonder directe link naar het issue in kwestie

deze review werd aangemaakt zonder directe link naar het issue in kwestie