FLOWTOE3.mac.rou

Checkout Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
[ICT-1967] [rvPVR] SST - mail voor Halux planning niet helemaal correct
[ICT-1967] [rvPVR] SST - mail voor Halux planning niet helemaal correct
[ICT-1967] [rvPVR] SST - mail voor Halux planning niet helemaal correct
[ICT-1967] [rvPVR] SST - mail voor Halux planning niet helemaal correct
Zal toch niet doorgaan omdat de gebruikte UniekeClassificatieCode niet geldig is voor bv alle cabloxxen dus is het te moeilijk om dit te veralgemenen

Zal toch niet doorgaan omdat de gebruikte UniekeClassificatieCode niet geldig is voor bv alle cabloxxen dus is het te moeilijk om dit te veralgemenen

hoort onderstaande functionaliteit niet eerder in DOM.PM.impl.ProductTypeAPIimpl ? Daar staat al vergelijkbare code (voor andere soorten producten). Desnoods pakt ge die uniekeclassificatecodelogic...

hoort onderstaande functionaliteit niet eerder in DOM.PM.impl.ProductTypeAPIimpl ? Daar staat al vergelijkbare code (voor andere soorten producten). Desnoods pakt ge die uniekeclassificatecodelogica ook mee. Voordeel is dat anderen het dan ook kunnen gebruiken, want niemand gaat er aan denken om dat in deze mac-file te zoeken

Cabloxx is met twee x'en. Is detail, maar als er ooit iemand op gaat zoeken met de juiste naam gaat ie dit niet vinden

Cabloxx is met twee x'en. Is detail, maar als er ooit iemand op gaat zoeken met de juiste naam gaat ie dit niet vinden

Als er geen expliciete reden is om via de domeincontext te gaan, kan je die API gewoon newen hier

Als er geen expliciete reden is om via de domeincontext te gaan, kan je die API gewoon newen hier

[ICT-1461] HLX: Opsplitsen van glassetjes, verzagingen en cabloxen in aparte toeleveringen
[ICT-1461] HLX: Opsplitsen van glassetjes, verzagingen en cabloxen in aparte toeleveringen
Openstaand onderwerp voor het team. http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/smile.gif voor mij is het verschil tussen de INT file van een mockable class ...

Openstaand onderwerp voor het team.

voor mij is het verschil tussen de INT file van een mockable class die overerft van implementatie of van interface, reden genoeg.

  • interface heeft enkel de 3 methods met testframework code. (geen implementatie)
  • door tech mockable wordt de volledige implementatie overgenomen in de INT van de mockclass. -> onnodig en neemt extra memory bij testen. Dit is net wat we niet willen bij testen.
idem.

idem.

idem

idem

Kurt, ik deel hier de mening van Martijn. Volgens mij voldoende om de Utils-klasse te laten afleiden van TECH.Mockable

Kurt, ik deel hier de mening van Martijn.
Volgens mij voldoende om de Utils-klasse te laten afleiden van TECH.Mockable

Waarom een interface?

Waarom een interface?

Waarom is interface?

Waarom is interface?

ICT-930: Refactoring nodig voor klassen van activiteiten. (vooral spoelbak is meer dan enkel spoelbak.)
ICT-930: Refactoring nodig voor klassen van activiteiten. (vooral spoelbak is meer dan enkel spoelbak.)
ICT-930: Refactoring nodig voor klassen van activiteiten. (vooral spoelbak is meer dan enkel spoelbak.)
ICT-930: Refactoring nodig voor klassen van activiteiten. (vooral spoelbak is meer dan enkel spoelbak.)
De stat juist, Heb ik bewust gewijzigd. Anders krijgen we standaard het gedrag dat spoelbak en smalle lade altijd in spoelbakgroep terecht komen en default gedrag is dat dit niet gebeurd. daarom he...

De stat juist, Heb ik bewust gewijzigd. Anders krijgen we standaard het gedrag dat spoelbak en smalle lade altijd in spoelbakgroep terecht komen en default gedrag is dat dit niet gebeurd. daarom heb ik ook de altijdsplitser moeten toevoegen.
maw indien true, faalde de bestaande testen op gewone aantallen als er geen splitser meegegeven wordt..

(Ik vind het nog steeds een gevaarlijk iets om te beslissen dat de groepering per kenmerk vervangen wordt door groepering op productiegroep, terwijl het in dit geval toevallig hetzelfde is.)

Kritische vraag (misschien om in de groep te gooien) : Is dit een project-setting? --> volgens mij enkel bedoeld om iets nieuw te kunnen "infaseren". Nadien wordt een project-setting opgekuist (in ...

Kritische vraag (misschien om in de groep te gooien) :
Is dit een project-setting? --> volgens mij enkel bedoeld om iets nieuw te kunnen "infaseren". Nadien wordt een project-setting opgekuist (in theorie althans )
Is dit dan eerder een gewone ConfigItem? --> is eigenlijk bedoeld om onderscheid te kunnen maken tussen de verschillende omgevingen (bvb. andere waarde op PROD dan op DEV)
Is het voldoende om deze gewoon als Class Parameter te definieren? --> volgens mij wel. Dit is een single-responsibility klasse, dus een wijziging van de waarde committen en mergen, kan supersnel.

Willen we dit toch wegtrekken uit onze code, dan misschien toch een aparte data-structuur voor maken. Functioneel is config-item hiervoor ook wel geschikt, maar ik vraag me af of we den boel dan niet te veel gaan vervuilen?