DataMProductOrderlijn.cls.xml

Checkout Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
[ICT-1876] BIDI: Orderingave: Error zGeefIngegevenKenmerken in BLDTOE+29^FLOWORD7 (bij order2admin):...
[ICT-1876] BIDI: Orderingave: Error zGeefIngegevenKenmerken in BLDTOE+29^FLOWORD7 (bij order2admin):...
[ICT-1876] BIDI: Orderingave: Error zGeefIngegevenKenmerken in BLDTOE+29^FLOWORD7 (bij order2admin):

- Gerelateerd aan vorige aanpassing, zijnde [ICT-759] [rvWV] PM: Maatwerk: BOMBOL VHIP481: Waarschuwing indien wijzigen variant die reeds voorbij orderklaar is:

- OrderService => Niet het Order moet bewaard worden, maar wel de OrderLijn, want daar zit de wijziging op. Order bewaren op die plek is overhead, want is op PRNr op OrderLijn na ongewijzigd.

- ProductOrderlijn => Property ProductIdIsGewijzigd als pointer om op juiste moment indexen te killen en rebuilden => Gebeurde blijkbaar (nog) niet in hoofde van de ProductUpdater, door vorige implementatie van VerwijderIndexenIndienNodig en BouwIndexenIndienNodig.

- ProductOrderlijn => Indexen rebuilden in ZetProductID weggehaald (was toevoeging in bovengenoemde story) => Was onzinnig, want in SWNODE^FLOWORD2 wordt gepersisteerde data opgehaald en die is op dat moment nog ongewijzigd (nog met oude PRNr) => Zou dus enkel de VerwijderIndexen ongedaan maken ipv de nieuwe te zetten.

- ProductOrderlijn => Voor rebuilden van indexen na zetten van ProductID voor ProductUpdate wordt nu vertrouwd op de Save => Die doet de Save van de Super vooraleer de indexen te rebuilden, dus al met juiste data opgehaald in SWNODE^FLOWORD2.

- ProductOrderlijn => Geen event ingesloten => Order2Admin volgt sowieso nog.

- DataMProductOrderlijn-Mock uitgebreid met Save.

  1. … 3 more files in changeset.
Telegramstijl, omdat ze anders te lang worden en de variaties nu eenmaal soms ingewikkeld zijnhttp://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/wink.gif

Telegramstijl, omdat ze anders te lang worden en de variaties nu eenmaal soms ingewikkeld zijn

Idem reply hierboven.

Idem reply hierboven.

Zoals besproken... Dit ging over de property-namen, maar... toch liever niet. In de properties kunnen soms mocks, soms stubs gestoken worden, afhankelijk van wat de UnitTest nodig heeft.

Zoals besproken... Dit ging over de property-namen, maar... toch liever niet. In de properties kunnen soms mocks, soms stubs gestoken worden, afhankelijk van wat de UnitTest nodig heeft.

Done!

Done!

Done

Done

Done! (smartass http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/wink.gif )

Done! (smartass )

Done!

Done!

Done, maar staat momenteel al nieuwe openstaande wijziging op die klasse, die nog niet gecommit mag worden, dus komt daarna wel.

Done, maar staat momenteel al nieuwe openstaande wijziging op die klasse, die nog niet gecommit mag worden, dus komt daarna wel.

Done, maar staat momenteel al nieuwe openstaande wijziging op die klasse, die nog niet gecommit mag worden, dus komt daarna wel.

Done, maar staat momenteel al nieuwe openstaande wijziging op die klasse, die nog niet gecommit mag worden, dus komt daarna wel.

Done en done en done! http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/smile.gif

Done en done en done!

Normaal binnen de scope blijven, ik weet het, maar ik dacht de while op deze manier zo proper en leesbaar mogelijk te houden. Uiteindelijk wordt elk van die dim'ekes toch in die while gebruikt en o...

Normaal binnen de scope blijven, ik weet het, maar ik dacht de while op deze manier zo proper en leesbaar mogelijk te houden. Uiteindelijk wordt elk van die dim'ekes toch in die while gebruikt en omhelst die while de volledige method.

Denk het niet. Nu krijgt ge alle OrderLijnIterators netjes op een rijtje via code completion. Eentje is dan de volledige, sommige zijn "via" dit, andere "via" dat, ...

Denk het niet. Nu krijgt ge alle OrderLijnIterators netjes op een rijtje via code completion. Eentje is dan de volledige, sommige zijn "via" dit, andere "via" dat, ...

Had ik al aangepast inmiddels, zit al in volgende review http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/wink.gif

Had ik al aangepast inmiddels, zit al in volgende review

test namen zeggen niet duidelijk wat er getest wordt.

test namen zeggen niet duidelijk wat er getest wordt.

(Is bestaande code natuurlijk) hoeft geen lokale var te zijn. mag rechtstreeks op ..ProductService(Mock)

(Is bestaande code natuurlijk) hoeft geen lokale var te zijn. mag rechtstreeks op ..ProductService(Mock)

Refact nodig zodat namen van bestaande code ook ProductServiceMock worden, etc..

Refact nodig zodat namen van bestaande code ook ProductServiceMock worden, etc..

in deze situatie gebruiken we veelal if $$asserttrue(.. hasnext){ assert.. next() } omdat de .next hiervan afhankelijk is. ..

in deze situatie gebruiken we veelal
if $$asserttrue(.. hasnext)

Unknown macro: { assert.. next() }


omdat de .next hiervan afhankelijk is. ..

es afstemmen met team of we dim buiten lussen houden als ze enkel binnen lus gebruikt worden.

es afstemmen met team of we dim buiten lussen houden als ze enkel binnen lus gebruikt worden.

"Order heeft 1 orderlijn met gevraagde InventransId"

"Order heeft 1 orderlijn met gevraagde InventransId"

"Order heeft geen orderlijnen." voor mij maakt het niet uit of ze zitten of liggen. :o)

"Order heeft geen orderlijnen." voor mij maakt het niet uit of ze zitten of liggen. :o)

Toelevering heeft normaal gezien ook een productlijniterator, dan hoef je type niet mee te geven.

Toelevering heeft normaal gezien ook een productlijniterator, dan hoef je type niet mee te geven.

$$$haslength ?

$$$haslength ?

ik vind deze ook goed, maar kan het zijn dat we declaraties altijd op de plaats zetten waar ze gebruikt worden ? in dit geval binnen de while ?

ik vind deze ook goed, maar kan het zijn dat we declaraties altijd op de plaats zetten waar ze gebruikt worden ? in dit geval binnen de while ?

Moet "iterator" altijd achteraan in benaming ? (ben ook niet zeker) -> bv GeefOrderlijnenViaAXInventTransIdIterator als naam

Moet "iterator" altijd achteraan in benaming ? (ben ook niet zeker) -> bv GeefOrderlijnenViaAXInventTransIdIterator als naam