Checkout Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
[ICT-1438] TBX/LBX/TAX uitfasering matmateriaal = antislip - Cache gedeelte (commit By PeterV - PVR)

- Uitfasering voor antislip: Matkleur Zwart en ladediepte 550 ook niet meer mogelijk

    • -1
    • +1
    ./PM/TBX/impl/AntislipMattenUitfaseren.cls.xml
[ICT-1438] TBX/LBX/TAX uitfasering matmateriaal = antislip - Cache gedeelte (commit By PeterV - PVR)

- Eerste fase uitfasering voor antislip: Matkleur Zwart en ladediepte 450 niet meer mogelijk

    • -5
    • +3
    ./PM/TBX/impl/AntislipMattenUitfaseren.cls.xml
Properder: If ((MatKleur = "Z") & (LadeDiepte > 450)) Dat geeft at runtime exact hetzelfde resultaat, maar is 1 If ipv een geneste If, dus leesbaarder. Idem voor die hieronder...

Properder: If ((MatKleur = "Z") & (LadeDiepte > 450))
Dat geeft at runtime exact hetzelfde resultaat, maar is 1 If ipv een geneste If, dus leesbaarder.

Idem voor die hieronder...

Hier een beetje hetzelfde... nieuwe code, ook al is het gebaseerd op een copy/paste, graag refactoren volgens huidige conventies. Je hoeft het nu niet meer aan te passen. Onthoud het voor de volgen...

Hier een beetje hetzelfde... nieuwe code, ook al is het gebaseerd op een copy/paste, graag refactoren volgens huidige conventies. Je hoeft het nu niet meer aan te passen. Onthoud het voor de volgende keer.

"$lb" = $ListBuild
"$lg" = $ListGet
"n" = New
"s" = Set
"q" = Quit
Wat spaties hier en daar voor en na =-teken en na komma en zo.

Opletten voor casing graag http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/smile.gif Variabele-namen beginnen met hoofdletter (Msg, Bool). Misschien de variabele...

Opletten voor casing graag

Variabele-namen beginnen met hoofdletter (Msg, Bool).
Misschien de variabele Bool dan ineens hernoemen naar het meer beschrijvende: IsValid.
Set met hoofdletter.

P.s.: OMG wat een klasse!!! lol Je hoeft niet de hele klasse aan te passen in dit geval (veel te veel werk), maar als je code toevoegt, zet die dan wel ineens volgens onze huidige conventies.

Als alle lijnen in comment staan, misschien toch een extra comment-lijntje toevoegen met de reden waarom. Ik vermoed in afwachting van dat de code actief moet gezet worden? Maar de call zelf staat ...

Als alle lijnen in comment staan, misschien toch een extra comment-lijntje toevoegen met de reden waarom. Ik vermoed in afwachting van dat de code actief moet gezet worden? Maar de call zelf staat toch in comment in de klasse APPS.EC.impl.ConfiguratorService.KenmerkMogelijkhedenPostProcessor?

Anderzijds... moet je hier niet enkel diegene voorzien die in klasse APPS.EC.impl.ConfiguratorService.KenmerkMogelijkhedenPostProcessor nog niet voorzien waren?

Louter ter info: Ook nog even meegeven dat iedere enum, die dus per definitie af moet leiden van TECH.Enumeration, automatisch daarom ook beschikt over een ValueListIterator. Als je dus alle enumwaarden van een enum moet overlopen, dan is gebruik maken van die iterator wellicht overzichtelijker dan voor iedere waarde een codelijn te voorzien.

[ICT-1437] TBX/LBX/TAX uitfasering matmateriaal = antislip - Cache gedeelte
[ICT-1437] TBX/LBX/TAX uitfasering matmateriaal = antislip - Cache gedeelte
[ICT-1438] TBX/LBX/TAX uitfasering matmateriaal = antislip - Cache gedeelte

- Momenteel staat de toegevoegd code nog in commentaar, op deze manier is het makkelijk om de code te actieveren onder de juiste condities

- Zowel een change in ladediepte als in matkleur zullen checken indien de combinatie mat/ladediepte wel nog geldig is en zal een melding weergeven indien dit niet zo is

    • -0
    • +30
    ./PM/TBX/impl/AntislipMattenUitfaseren.cls.xml
  1. … 1 more file in changeset.
Idem voor de cleanup van de UTDataVoorKvik --> aparte method Hier zelfs geen parameters nodig, denk.

Idem voor de cleanup van de UTDataVoorKvik --> aparte method
Hier zelfs geen parameters nodig, denk.

Ik heb lang gezocht naar het verschil in setup tussen deze method en de method erboven. Door de setup (de lijnen hierboven) in een aparte private method te zetten wordt het onderscheid meteen duide...

Ik heb lang gezocht naar het verschil in setup tussen deze method en de method erboven.
Door de setup (de lijnen hierboven) in een aparte private method te zetten wordt het onderscheid meteen duidelijk:

bvb. Do ..SetUpUTDataVoorKvik ( PalletIdVoorEWMS, PalletIdVoorEWPAL )

En hierdoor worden de 2 tests meteen een pak overzichtelijker

MethodNaam volgens vh-conventies : ZetOpEWPAL() en KuisOpEWPAL() en ZetOpEWMSData()

MethodNaam volgens vh-conventies : ZetOpEWPAL() en KuisOpEWPAL() en ZetOpEWMSData()

Als er palletten meegeven zijn, en we vinden niet wat we zoeken, dan stoppen we. Als er geen palletten meegegeven zijn moeten we verder. (fallback) de test op Count is dus essentieel. en dient niet...

Als er palletten meegeven zijn, en we vinden niet wat we zoeken, dan stoppen we.
Als er geen palletten meegegeven zijn moeten we verder. (fallback)
de test op Count is dus essentieel. en dient niet om de 0 te detecteren, maar om niet 0 te detecteren.

OPGELET: Tracht zoveel mogelijk de code van deze klasse tussen caché v5 en cache2010 in sync te houden. Net voor uw wijzigingen waren deze methods redelijk goed in sync (behalve method FPalletsPerP...

OPGELET:
Tracht zoveel mogelijk de code van deze klasse tussen caché v5 en cache2010 in sync te houden.
Net voor uw wijzigingen waren deze methods redelijk goed in sync (behalve method FPalletsPerProdNr() die is ge-refactored).
Na uw wijzigingen dreigt de code uiteen te lopen en wordt het steeds lastiger voor iemand anders om nog toe te voegen, of erger nog: om te troubleshooten!

Maak er desnoods een apart kaartje van. Of overleg met Pieter en/of met mij

Early quit :-O Gelukkig gaat ie binnenkort wel weg.

Early quit :-O
Gelukkig gaat ie binnenkort wel weg.

Als reviewer ben ik verplicht om dit aan te geven : embedded sql aanpassen : beter : wegwerken en vervangen door TECH.Resultset reden: gedrag is beter onder controle bij errors, early quits, onvoo...

Als reviewer ben ik verplicht om dit aan te geven :

embedded sql aanpassen :
beter : wegwerken en vervangen door TECH.Resultset
reden: gedrag is beter onder controle bij errors, early quits, onvoorspelbaar gedrag indien 2 sql's gemixed worden (lees op andere stacklevel een andere &sql doorlopen), compile-issues.

In dit specifiek geval zou ik misschien toch ook de &sql behouden.

Zeer goed dat je deze lijn erbij zet! http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/smile.gif

Zeer goed dat je deze lijn erbij zet!

Count() is niet nodig, want als Count=0 , dan zal Find() ook niks vinden.

Count() is niet nodig, want als Count=0 , dan zal Find() ook niks vinden.

[ICT778] MAG: Picking: juiste exemplaren picken (voor het juiste order)
[ICT778] MAG: Picking: juiste exemplaren picken (voor het juiste order)
[ICT778] MAG: Picking: juiste exemplaren picken (voor het juiste order)

- ECP mapping voor EWPAL (DOM/MAG/impl/DataM/DragerInhoudEnDoel.cls

- Backport wijziging Cache05 (BL/MB/UGLYPicking/OrderReservatie.cls)

- Uitbereding om voorlopig alleen voor KVIK palletten te filteren op basis van EWPAL

    • -0
    • +63
    ./MAG/impl/DataM/DragerInhoudEnDoel.cls.xml
[ICT778] MAG: Picking: juiste exemplaren picken (voor het juiste order)

- ECP mapping voor EWPAL (DOM/MAG/impl/DataM/DragerInhoudEnDoel.cls

- Backport wijziging Cache05 (BL/MB/UGLYPicking/OrderReservatie.cls)

- Uitbereding om voorlopig alleen voor KVIK palletten te filteren op basis van EWPAL

  1. … 1 more file in changeset.
Merged manually from trunk2010 :

[UST4175] PA-UB-007: DnaCode Tabel maken - DnaCode datastructuur

[UST4175] PA-UB-007: DnaCode Tabel maken - status-enumeratie

    • -0
    • +56
    ./Halux/AAP/enu/DnaCodeStatus.cls.xml
    • -0
    • +153
    ./Halux/AAP/DnaCode.cls.xml
DOM.PM.enu.LinkType (hieronder nog een paar keer) (en ook in ander testje)

DOM.PM.enu.LinkType (hieronder nog een paar keer) (en ook in ander testje)