CacheAdminA_trunk2010/DOM/PM

TAORProduct

Checkout Tools

Line History

Line Count Graph
Line Count Graph

Stats

Commits this week: 0
Total Committers: 5
Last Commit: 04 Aug 15
Commits this week: 0
Total Lines of Code (LoC): 37
Net change in LoC this week: 0

Commit Activity

Commits By Day In Week
52 week commits volume
Commits By Day In Week
Commits by day
Commits By Day In Week
Commits by hour
Commits By Hour In Day
Commit calendar
 

Most active committers (90 days)

loading
loading
  • last updated a few seconds ago
All Commits Reviews
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Monday 07 Nov 2022
11:06 am

Tommy Hebb

Wednesday 02 Nov 2022
6:51 pm

Wim Vermeulen

6:51 pm

Wim Vermeulen

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

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.

6:38 pm

Wim Vermeulen

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

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!

Friday 21 Oct 2022
10:35 am

Tommy Hebb

De meeste testfiles heb ik maar buiten de review gehouden. Een aantal zijn toch toegevoegd, bij wijze van check van het resultaat is dat, denk ik, wel ok en het is bovendien soms ook moeilijk om ui...

De meeste testfiles heb ik maar buiten de review gehouden. Een aantal zijn toch toegevoegd, bij wijze van check van het resultaat is dat, denk ik, wel ok en het is bovendien soms ook moeilijk om uit te maken a.d.h.v. de changesets of het al dan niet over code gaat of testfiles.
P.s.: Ook kleine change in Econ (zie svn).

10:31 am

Tommy Hebb

[ICT-3120] [rvWV] PM: TAX: Front HoogteVerstelling MoventoKoppeling: release alle klanten:
[ICT-3120] [rvWV] PM: TAX: Front HoogteVerstelling MoventoKoppeling: release alle klanten:
Thursday 29 Sep 2022
4:58 pm

Tommy Hebb

[ICT-3120] [rvWV] PM: TAX: Front HoogteVerstelling MoventoKoppeling: release alle klanten:

- StringUtils Equals gebruikt want haakskes haakskes haakskes

- HeeftFrontHoogteVerstelling op een product geeft nu voor ALLE KoppelingTypes true terug, waardoor alles in de productieaansturing automatisch met HoogteVerstelling gaat zijn.

=> Eerdere poging tot (her)bereken via DOM.PM.Maatwerk.Calc.HF.impl.HalffabSpecKenmerkenAanpasser lukt niet, omdat de bereken voor productie het product niet wijzigt.

=> Op de nieuwe HalffabItemsboom staat dan wel de MoventoKoppeling, maar uiteindelijk wordt in de productieaansturing toch gekeken naar HeeftFrontHoogteVerstelling op het product zelf => dus dan geen witte rook

Options
    • -1
    • +1
    ./impl/TAORLadeImpl.cls.xml
  2. … 1 more file in changeset.
Monday 29 Nov 2021
9:39 am

Tommy Hebb

9:10 am

Wim Vermeulen

Tuesday 23 Nov 2021
10:40 am

Tommy Hebb

[ICT-2581] [rvWV] HX: TAX: Movento-koppeling: Aanpassing ProductCreatie volgens KoppelingType:
[ICT-2581] [rvWV] HX: TAX: Movento-koppeling: Aanpassing ProductCreatie volgens KoppelingType:
Friday 05 Nov 2021
10:50 am

Tommy Hebb

[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

Options
    • -2
    • +2
    ./impl/TAORLadeImpl.cls.xml
  2. … 1 more file in changeset.
Tuesday 16 Mar 2021
4:47 pm

Tommy Hebb

4:46 pm

Tom Vermeulen

Thursday 11 Mar 2021
4:43 pm

Tommy Hebb

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.

3:13 pm

Tommy Hebb

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?

8:57 am

Wim Vermeulen

Wednesday 10 Mar 2021
7:51 pm

Wim Vermeulen

Ik had verwacht dat "Product" of "ProductId" reeds werd doorgeven via de LadeInfo, maar dat blijkt toch niet het geval. Als dit wel zo was, dan had het niet nodig geweest om de extra parameter (pro...

Ik had verwacht dat "Product" of "ProductId" reeds werd doorgeven via de LadeInfo, maar dat blijkt toch niet het geval.
Als dit wel zo was, dan had het niet nodig geweest om de extra parameter (productieSequentie) toe te voegen.
Na al je inspanningen, keur ik deze oplossing goed

7:29 pm

Wim Vermeulen

Ik begrijp niet echt waarom je deze "Assert..." method hebt weggewerkt. Dit is immers een algemeen gebruikt principe, o.a. om aan te geven dat de test-methods in deze klasse dezelfde logica oproepe...

Ik begrijp niet echt waarom je deze "Assert..." method hebt weggewerkt.
Dit is immers een algemeen gebruikt principe, o.a. om aan te geven dat de test-methods in deze klasse dezelfde logica oproepen. Hoe eenvoudig deze ook is.

En voor zover consistentie een argument i : de implementatie bij TAX is nu minder consistent met die van LBX en TBX.

Ik vind dit geen drama, hoor. Als je wilt kunnen we hierover van gedachten wisselen

7:17 pm

Wim Vermeulen

Kleine suggestie : OpstartfaseBepaler voor iedere test(method) newen, dat is ietsje properder --> dus in de OnBeforeOneTest() is beter. Let op: parameter (aTestCase) !

Kleine suggestie :
OpstartfaseBepaler voor iedere test(method) newen, dat is ietsje properder --> dus in de OnBeforeOneTest() is beter.
Let op: parameter (aTestCase) !

Tuesday 09 Mar 2021
3:16 pm

Tommy Hebb

[ICT-2144] [rvWV] HX: TAX koppeling: hoogteverstelling pilootklanten productieaansturing (frontverstelmogelijkheid):

- BEGIN GRONDIGE REFACTOR => Architecturaal is het niet ok dat in productie-aansturing met KlantId gewerkt wordt => Behavior HeeftFrontHoogteVerstelling al op het product zetten.

Options
    • -0
    • +5
    ./TAORLade.cls.xml
    • -0
    • +8
    ./impl/TAORLadeImpl.cls.xml
  3. … 2 more files in changeset.
Monday 01 Mar 2021
9:55 am

Tom Vermeulen

ineens een Set van maken, lijn wordt korter en leesbaarder

ineens een Set van maken, lijn wordt korter en leesbaarder

Friday 26 Feb 2021
3:00 pm

Tommy Hebb

[ICT-2144] [rvWV] HX: TAX koppeling: hoogteverstelling pilootklanten productieaansturing...
[ICT-2144] [rvWV] HX: TAX koppeling: hoogteverstelling pilootklanten productieaansturing...
Thursday 28 Jan 2021
11:49 am

Wim Vermeulen

8:41 am

Peter Vercoutter

Wednesday 27 Jan 2021
7:57 pm

Wim Vermeulen

Reden van deze wijzigingen : method .GeefProductSpecificatie() kan antwoorden met een leeg object. Wanneer men hierop meteen .GeefIngegevenKenmerken() oproept, crasht caché met een "InvalidOref" en...

Reden van deze wijzigingen :
method .GeefProductSpecificatie() kan antwoorden met een leeg object.
Wanneer men hierop meteen .GeefIngegevenKenmerken() oproept, crasht caché met een "InvalidOref" en geen enkele notie over welk product het gaat.
In de rechtstreekse implementatie van .GeefIngegevenKenmerken() is deze fout wel goed opgevangen, en zal een leesbare foutmelding gesmeten worden.

7:53 pm

Wim Vermeulen

[ICT-1976] PM: MaatwerkProduct heeft geen IngegevenKenmerken (cfr. SST-LBX)
[ICT-1976] PM: MaatwerkProduct heeft geen IngegevenKenmerken (cfr. SST-LBX)
Tuesday 03 Nov 2020
5:45 pm

Wim Vermeulen

[ICT-1976] PM: MaatwerkProduct heeft geen IngegevenKenmerken (cfr. SST-LBX)

- TAORLadeImpl, method call aanpassen : GeefIngegevenKenmerken() op MaatwerkProductImpl.cls rechtstreeks oproepen

Options
    • -1
    • +1
    ./impl/TAORLadeImpl.cls.xml
Friday 10 Jan 2020
9:32 am

Peter Vercoutter

Thursday 19 Dec 2019
1:57 pm

Tom Vermeulen

1:57 pm

Tom Vermeulen

zie TAOR-opmerking hieronder

zie TAOR-opmerking hieronder