Checkout Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Ook een klein stukje in Econ! (zie svn)

Ook een klein stukje in Econ! (zie svn)

[ICT-1693] TAXEB1 - PM: Maatwerk: BevatGeleiderBevestigingSchroeven = True indien Alpnach:
[ICT-1693] TAXEB1 - PM: Maatwerk: BevatGeleiderBevestigingSchroeven = True indien Alpnach:
Ik heb ze er zelf onlangs opgezet en ze zijn nooit in gebruik genomen, dus er is geen risico hier http://subversion02.vanhoecke.be/static/ogdo0b/2static/images/wiki/icons/emoticons/wink.gif

Ik heb ze er zelf onlangs opgezet en ze zijn nooit in gebruik genomen, dus er is geen risico hier

Oppassen met opkuisen van Storage !!! In bestaande data zullen items 4, 5 en 6 nog steeds ingevuld zijn. Wanneer je later een nieuwe property toevoegd, zal die onterecht verwijzen naar item 4. In ...

Oppassen met opkuisen van Storage !!!
In bestaande data zullen items 4, 5 en 6 nog steeds ingevuld zijn.
Wanneer je later een nieuwe property toevoegd, zal die onterecht verwijzen naar item 4.

In deze klasse zal het mogelijk geen gevaar vormen, maar let er wel op, in de toekomst. Bij twijfel, kom maar vragen.

[ICT831] TAXFP1: Afwerking:
[ICT831] TAXFP1: Afwerking:
deze dan ineens ook renamen van EconConverter naar AxNaarEconConverter zoals op de andere plaatsen

deze dan ineens ook renamen van EconConverter naar AxNaarEconConverter zoals op de andere plaatsen

Ge kunt best ook nog testen voor TAX en TBX toevoegen (aparte klaskes). Dan is het volledig. Ge kunt nooit weten dat daar nog iets speciaals inzit. Ik denk niet dat het nodig is, maar als die conve...

Ge kunt best ook nog testen voor TAX en TBX toevoegen (aparte klaskes). Dan is het volledig. Ge kunt nooit weten dat daar nog iets speciaals inzit.
Ik denk niet dat het nodig is, maar als die conversie zelf veel scheelt van die van LBX, dan kunt ge best de converter opsplitsen per ladetype

[UST3999] VHIP481 BOMKenmerken: Afstemmen converter AX to ECONKenmerken:
[UST3999] VHIP481 BOMKenmerken: Afstemmen converter AX to ECONKenmerken:
Nope, enkel een Mock doet dat hé, een Fake moet je handmatig aanpassen. Good call!!! Was het vergeten. Aangepast en kaartje alvast doorgeschoven naar Review klaar.

Nope, enkel een Mock doet dat hé, een Fake moet je handmatig aanpassen.
Good call!!! Was het vergeten.
Aangepast en kaartje alvast doorgeschoven naar Review klaar.

deze zou toch automatisch verwijderd moeten zijn? misschien een recompile nog eens doen ofzo

deze zou toch automatisch verwijderd moeten zijn? misschien een recompile nog eens doen ofzo

Formaat ligt nog niet vast, ik moest 'voorlopig doen alsof'. Testjes schrijven leek mij in deze situatie al wat overkill. Beter efkes wachten tot we weten hoe de data eruit gaat zien. Dan zal ik id...

Formaat ligt nog niet vast, ik moest 'voorlopig doen alsof'.
Testjes schrijven leek mij in deze situatie al wat overkill. Beter efkes wachten tot we weten hoe de data eruit gaat zien. Dan zal ik idd de nodige testjes gaan schrijven.

Omwille van verwarring die dan ontstaat in mijn klasse: WSimpl.AX.CalculatedProduct.Converter.AxProductKenmerkenConverter. Daar gebeuren de achtereenvolgende conversies, waaronder: #dim EconConfigu...

Omwille van verwarring die dan ontstaat in mijn klasse: WSimpl.AX.CalculatedProduct.Converter.AxProductKenmerkenConverter.
Daar gebeuren de achtereenvolgende conversies, waaronder:
#dim EconConfiguratie As %ArrayOfDataTypes = ..EconConverter.ConvertAxConfiguratieToEconConfiguratie(Attributes)
#dim EconConfiguratieAsObject As ECON.PM.Maatwerk.dto.EconConfiguratie = ..EconConfiguratieConverter.ConvertEconConfiguratieToObject(EconConfiguratie)
Die van Vhisie4 maakt er een EconConfiguratie van (zie dto hierboven), terwijl 'die van mij' maar van een %List naar een %ArrayOfDataTypes converteert.

Ik snap wat ge bedoelt... Ik call de method nu rechtstreeks van klasse ECONimpl.PM.Maatwerk.AppsConverter en heb de call in 'deze' klasse terug in de Convert-method gestoken, zoals voorheen.

Ik snap wat ge bedoelt... Ik call de method nu rechtstreeks van klasse ECONimpl.PM.Maatwerk.AppsConverter en heb de call in 'deze' klasse terug in de Convert-method gestoken, zoals voorheen.

Best wel, zolang AX nog niet voorzien is. Enkel deze ene lijn geeft toegang tot de nieuwe implementatie. Zolang de volledige flow niet kan getest worden (AX => Cache => AX) is het onnodig om risico...

Best wel, zolang AX nog niet voorzien is. Enkel deze ene lijn geeft toegang tot de nieuwe implementatie. Zolang de volledige flow niet kan getest worden (AX => Cache => AX) is het onnodig om risico te lopen.

Als je hier echt zinnige data in gaat steken (geen idee of het formaat al wat vastligt), zie dan dat je testen hebt conform al de andere kenmerkenconverters. Maw: al onze standaardlades converteren...

Als je hier echt zinnige data in gaat steken (geen idee of het formaat al wat vastligt), zie dan dat je testen hebt conform al de andere kenmerkenconverters. Maw: al onze standaardlades converteren en de resultaten asserten

Zou je deze ook niet EconConfiguratieConverter noemen? Dat komt overeen met die van de Vhisie4.

Zou je deze ook niet EconConfiguratieConverter noemen? Dat komt overeen met die van de Vhisie4.

private is het nodig deze oneliner af te zonderen? De methodname ConverteerEconNaarApps wordt ook al veel gebruikt in het hele Econ-verhaal en zou misschien misleidend kunnen zijn voor arme sukkel...

private

is het nodig deze oneliner af te zonderen? De methodname ConverteerEconNaarApps wordt ook al veel gebruikt in het hele Econ-verhaal en zou misschien misleidend kunnen zijn voor arme sukkelaars die een grep moeten doen

moet dat nog in commentaar staan?

moet dat nog in commentaar staan?