MaatwerkProductImpl.cls.xml

Checkout Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
$TR best vervangen naar "$Translate" volgens coding conventions http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/smile.gif

$TR best vervangen naar "$Translate" volgens coding conventions

[ICT-3916] [Cache] Order vergelijk software
[ICT-3916] [Cache] Order vergelijk software
[ICT-3916] [Cache] Order vergelijk software
  1. … 10 more files in changeset.
Ik had deze in de klassenaam zelf misschien ook "converter" bijgezet. Nu is dit HalffabItemsboom, maar is op die manier niet echt duidelijk dat het om een converter gaat zonder naar de folder te ki...

Ik had deze in de klassenaam zelf misschien ook "converter" bijgezet. Nu is dit HalffabItemsboom, maar is op die manier niet echt duidelijk dat het om een converter gaat zonder naar de folder te kijken (zelfde voor LBXKenmerken)

Zijn deze lijnen in commentaar nog relevant?

Zijn deze lijnen in commentaar nog relevant?

Samengesteld ipv SamenGesteld

Samengesteld ipv SamenGesteld

'Dotnet' -> Encoway

'Dotnet' -> Encoway

Rol doet niets, mag weg

Rol doet niets, mag weg

ProductApi is nergens gedefinieerd als input parameter, dus deze inject is niet nodig

ProductApi is nergens gedefinieerd als input parameter, dus deze inject is niet nodig

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 vhcon...

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

Ik zou deze in een config item plaatsen

Ik zou deze in een config item plaatsen

In enu steken en hier ook naar verwijzen?

In enu steken en hier ook naar verwijzen?

Mijn gevoel is om dit ook in een aparte klasse te plaatsen en onder test te steken (ook al zal deze klasse dan vrij klein zijn)

Mijn gevoel is om dit ook in een aparte klasse te plaatsen en onder test te steken (ook al zal deze klasse dan vrij klein zijn)

Talen kunnen eventueel in een aparte enu?

Talen kunnen eventueel in een aparte enu?

Variabele naam aanpassen naar Encoway ipv dotnet

Variabele naam aanpassen naar Encoway ipv dotnet

Variabele naam aanpassen naar Encoway ipv dotnet

Variabele naam aanpassen naar Encoway ipv dotnet

[ICT-3982] Productcreatie in cache voor encowayconfiguraties
[ICT-3982] Productcreatie in cache voor encowayconfiguraties
[ICT-3982] Productcreatie in cache voor encowayconfiguraties
  1. … 28 more files in changeset.
[ICT-2581] [rvWV] HX: TAX: Movento-koppeling: Aanpassing ProductCreatie volgens KoppelingType:
[ICT-2581] [rvWV] HX: TAX: Movento-koppeling: Aanpassing ProductCreatie volgens KoppelingType:
[ICT-2581] [rvWV] HX: TAX: Movento-koppeling: Aanpassing ProductCreatie volgens KoppelingType:

- HeeftFrontHoogteVerstelling niet meer via KlantInstellingenService => Nu volgens of KoppelingType = Movento

- Opkuis injectie KlantInstellingenService wegens niet meer nodig

  1. … 1 more file in changeset.
Heum... waarom? Die verandert toch nooit en hoeft tussen UTs toch ook niet eventueel te veranderen? Toch zeker niet sinds er in de constructor ervan niets meer gebeurt. Ik dacht dat een OnBeforeOne...

Heum... waarom? Die verandert toch nooit en hoeft tussen UTs toch ook niet eventueel te veranderen? Toch zeker niet sinds er in de constructor ervan niets meer gebeurt.
Ik dacht dat een OnBeforeOneTest bedoeld is voor als er een gevaar is dat hij door eerdere UTs zou kunnen bevuild worden, wat hier niet het geval is.

Bwa, is een beetje zo gegroeid door refactoren... Waarom een Bepaler new'en per UnitTest, als je hem gewoon 1 keer kunt new'en in een OnBeforeAllTests? Daarna de afweging: Waarom dan nog de call on...

Bwa, is een beetje zo gegroeid door refactoren...
Waarom een Bepaler new'en per UnitTest, als je hem gewoon 1 keer kunt new'en in een OnBeforeAllTests?
Daarna de afweging: Waarom dan nog de call onder test speciaal gaan afzonderen? En bovendien: Waarom beschikken we anders over een $$$AssertTrue en $$$AssertFalse?
Het was bovendien daardoor ook niet meer nodig om een betekenisvolle, extra lokale variabele te voorzien in de UnitTesten (VerwachtInOpstartfase), dus ook al een regel minder per UT, zonder aan leesbaarheid in te boeten (eerder het tegendeel).
Doe de nieuwe versie eens open in studio en zie eens hoe leesbaar die is
Misschien moeten we dan eerder (mettertijd, als die klassen eens onder change komen) die van LBX en TBX aanpassen naar dit model?