Checkout Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
[ICT-5609] Parametriseren Images path in cache code

- code met expliciete verwijzing naar \\notes01\images aangepast met configItem, met default fallback op Notes01 indien niet gezet.

    • -4
    • +4
    ./ImageLinkImport/BlumImagesVoorAdminImporteerder.cls.xml
  1. … 18 more files in changeset.
[ICT-3847][rvMCL] PRJ029 - Uitfaseren WWW03 : ProductInfo via Vhisie4 : code productie-waardig maken...
[ICT-3847][rvMCL] PRJ029 - Uitfaseren WWW03 : ProductInfo via Vhisie4 : code productie-waardig maken...
[ICT-3847][rvMCL] PRJ029 - Uitfaseren WWW03 : ProductInfo via Vhisie4 : code productie-waardig maken

- Klasse BL.Legacy.HADWIZ kan ProductApi uitmocken + ProductInfoAesKey en -Domein via config-item opgehaald

- Klasse BL.Prod.ImageLink kan instance van BL.Legacy.HADWIZ injecteren

- vhUnitTest.BL.Prod.TestImageLink aangepast : Product en ProductApi uitgemockt; Resultaat geeft nieuwe url naar vhisie4

  1. … 3 more files in changeset.
[ICT-5051][rvNVT] FOP: DocBase Upgrade - Clean up caché-code na de go-live

- Opkuis - commentaar met verwijzing naar FOP verwijderd of aangepast

  1. … 1 more file in changeset.
[ICT-5051][rvNVT] FOP: DocBase Upgrade - Clean up caché-code na de go-live

- Opkuis: tijdelijke methods VerwerkTijdelijkActiefDocBaseV7() en StelInEnGeefTerugTijdelijkActiefVoorFakeTask() niet meer oproepen

- Opkuis globale variabele %WVActivateDocBaseV7

  1. … 7 more files in changeset.
[ICT-4648][rvTVE] FOP: DocBase Upgrade - aanpassingen in caché code (FopQueue via webservices)

[ICT-5021] FOP: DocBase Upgrade - Set up Web-folder (IIS) op DEV/ACP/PRD + aanpassen caché-code

- VoorraadTelling : tijdelijke work-around nu via method StelInEnGeefTerugTijdelijkActiefVoorFakeTask() i.p.v. dummytask zelf op te bouwen

[ICT-4648][rvTVE] FOP: DocBase Upgrade - aanpassingen in caché code (FopQueue via webservices)

- VoorraadTelling (backporten van cache01 impl.) : tijdelijke work-around. Eenmaal overgeschakeld naar V7 mag de dummy opgekuist worden.

[ICT-4648][rvTVE] FOP: DocBase Upgrade - aanpassingen in caché code (FopQueue via webservices)

- VoorraadTelling : bugfix in tijdelijke work-around. Eenmaal overgeschakeld naar V7 mag de dummy opgekuist worden.

[ICT-4648][rvTVE] FOP: DocBase Upgrade - aanpassingen in caché code (FopQueue via webservices)

- VoorraadTelling : Test/DEV-methods per ongeluk mee gecommit

- WimV is er een knoeiboel van aan t maken !!! :-O :-P

[ICT-4648][rvTVE] FOP: DocBase Upgrade - aanpassingen in caché code (FopQueue via webservices)

- VoorraadTelling (Poging 2) : TempDummyTask is een work-around om de bepaling van "IsActiefDocBaseV7" op één plaats te houden, nl. bij DocBaseV7Helper. Eenmaal overgeschakeld mag de dummy opgekuist worden.

- NIET MERGEN NAAR Deploy2010, tenzij ook svn rev. 73595 eerst gemerged wordt (i.e. "... methods VerwerkTijdelijkActiefDocBaseV7() en AnalyseerFopTaakVoorV7() toegevoegd ...")

[ICT-4648][rvTVE] FOP: DocBase Upgrade - aanpassingen in caché code (FopQueue via webservices)

- VoorraadTelling : UNDO van vorige commit : TempDummyTask is een work-around om de bepaling van "IsActiefDocBaseV7" op één plaats te houden, nl. bij DocBaseV7Helper. Eenmaal overgeschakeld mag de dummy opgekuist worden.

[ICT-4648][rvTVE] FOP: DocBase Upgrade - aanpassingen in caché code (FopQueue via webservices)

- VoorraadTelling : TempDummyTask is een work-around om de bepaling van "IsActiefDocBaseV7" op één plaats te houden, nl. bij DocBaseV7Helper. Eenmaal overgeschakeld mag de dummy opgekuist worden.

[ICT-4648][rvTVE] FOP: DocBase Upgrade - aanpassingen in caché code (FopQueue via webservices)

- VoorraadTelling PrintOne via DFS i.p.v. via watchfolder

[ICT-4648][rvTVE] FOP: DocBase Upgrade - aanpassingen in caché code (FopQueue via webservices)

- VoorraadTelling bugfix (anders Command-error)

Dit is net het herophalen van data waarvan we al zeker zijn dat bestaat. We hebben in een vorige stap die data opgezocht. Nu willen we die nog eens gaan uitlezen uit de DB.

Dit is net het herophalen van data waarvan we al zeker zijn dat bestaat. We hebben in een vorige stap die data opgezocht. Nu willen we die nog eens gaan uitlezen uit de DB.

Nee, het is best van deze data op te kuisen. Kan in het slechtste geval nog vervuild zijn van de vorige iteraties over de bonnummers

Nee, het is best van deze data op te kuisen. Kan in het slechtste geval nog vervuild zijn van de vorige iteraties over de bonnummers

OrderAPI newen in constructor graag.

OrderAPI newen in constructor graag.

Ook hier gebeurt wel heel erg veel op 1 lijn hé... Tenminste het product verdient wel een eigen lijn vind ik en dan nog liefst met een ProductRolAPI die in de constructor genewed wordt (en tevens n...

Ook hier gebeurt wel heel erg veel op 1 lijn hé...
Tenminste het product verdient wel een eigen lijn vind ik en dan nog liefst met een ProductRolAPI die in de constructor genewed wordt (en tevens niet van de DomeinContext afgenomen wordt )

Typo http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/smile.gif

Typo

Deze houdt toch risico in, denk ik, want je geeft normaal een object terug van type DS.Prod.OptiBox.BoxDataMetID, maar de logica laat toe dat dit object undefined is en op de volgende lijn van het ...

Deze houdt toch risico in, denk ik, want je geeft normaal een object terug van type DS.Prod.OptiBox.BoxDataMetID, maar de logica laat toe dat dit object undefined is en op de volgende lijn van het stuk code dat deze private method gebruikt wordt er gebruik gemaakt van een property van dit object. Je komt ermee weg omdat de repo daar met lege strings overweg kan, maar 't is niet helemaal correct zoals het hier afgehandeld wordt. Minimaal zou je een leeg object moeten teruggeven, of je moet er nog een "Bestaat..." of "Heeft..." tussen moeten steken.

Hier gebeurt wel heel erg veel op 1 lijn hé http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/smile.gif Tenminste het product verdient wel een eigen lijn vind ik en...

Hier gebeurt wel heel erg veel op 1 lijn hé
Tenminste het product verdient wel een eigen lijn vind ik en dan nog liefst met een ProductRolAPI die in de constructor genewed wordt (en tevens niet van de DomeinContext afgenomen wordt )

Is het niet gevaarlijk die al uit de repo te gaan verwijderen terwijl er nog processen (de calls hieronder) in gang gaan gezet worden, die misschien nog gaan crashen? Moet deze verwijder niet op he...

Is het niet gevaarlijk die al uit de repo te gaan verwijderen terwijl er nog processen (de calls hieronder) in gang gaan gezet worden, die misschien nog gaan crashen? Moet deze verwijder niet op het einde van deze method uitgevoerd worden (vlak voor het loggen dat hij ermee klaar is)?

Aangezien ge hier beide mogelijkheden voorziet (injecteren of de echte gebruiken) moet ge dat ook bij de parameter duidelijk maken door die als lege string te defaulten, zoals bij de andere paramet...

Aangezien ge hier beide mogelijkheden voorziet (injecteren of de echte gebruiken) moet ge dat ook bij de parameter duidelijk maken door die als lege string te defaulten, zoals bij de andere parameters gedaan is. Op die manier, als iemand deze klasse instantieert ergens, ziet die persoon gelijk aan de parameterdefinitie dat die niet per se moet meegegeven worden (en dat dan een nieuwe instantie voorzien is door deze constructor).

Graag de èchte instantiëren en niet van de DomeinContext afnemen.

Graag de èchte instantiëren en niet van de DomeinContext afnemen.

Moet/mag deze lijn in comment blijven staan? Graag comment erachter met meer duiding.

Moet/mag deze lijn in comment blijven staan? Graag comment erachter met meer duiding.

Best diene Partialloadonfloor hier ook nog eens defaulten op 0, want hij wordt in deze method rechtstreeks gebruikt enerzijds en anderzijds wordt hij als parameter in de aanroepende method toch ook...

Best diene Partialloadonfloor hier ook nog eens defaulten op 0, want hij wordt in deze method rechtstreeks gebruikt enerzijds en anderzijds wordt hij als parameter in de aanroepende method toch ook al gedefaulted op 0, dus mag consistent zijn, zoals gedaan is bij MinFillPercentage. Kan anders gevaar opleveren als deze private method ooit nog door een andere method gecalled wordt ook, waarin dan deze parameter nergens gedefaulted staat. (= undefined at runtime)