Ik ben al lange tijd bezig een oude applicatie, gebouwd in FMP 2 (!) en tjokvol herhalende velden (!!), te herbouwen. Het project nadert zijn eerste definitieve test. Maar met name in de user interface duiken nogal wat struikelblokken op. Ik vraag me af of een van jullie inventieve geesten daar suggesties over heeft.
Het zou te ver voeren de hele applicatie uit te leggen (dat wil ik overigens via backchannel best doen). Maar het hoofddoel is het berekenen van prijzen voor material handling systemen (lopende banden, distributie centra apparatuur etc.)
Ten grondslag aan alles ligt een soort produkt catalogus. Bij ieder produkt, dat een unieke code heeft, hoort een lijst van componenten. De gebruiker kies in een andere file op basis van de unieke code een produkt. In de oude situatie resulteerde dit in 1 record per produkt, de componenten 'woonden' in enkele herhalende velden.
Inmiddels heb ik dit deel van de applicatie omgebouw naar line items files. Afhankelijk van het produkt en de bijbehorende componenten zal; zijn nieuwe file niet slechts 1 record per produkt bevatten, maar zoveel records als er componenten zijn gekozen.
Voorbeeld:
een stukje lopende band van type aA heeft 22 componenten. De gebruiker kiest aA op grond van die type code, ziet een lijst in een portal waaruit hij kan kiezen. Als hij 1 motor, een noodstop en een frame kiest, zal zijn file bestaan uit drie records. Vergelijk met vroeger: toen zou dit 1 record zijn geworden met de complete lijst componenten, waarvan bij slechts 3 de gewenste aantallen werden ingevuld.
De gebruiker vindt het prachtig dat hij nu al die componenten separaat in zijn file heeft. Hij kan nu immers snel een analyse maken van hoeveel motoren er van een bepaald type inzitten. Hij kan ook bepaalde componenten isoleren etc. Maar hij kent ook situaties waarin hij een lijst wil zien van uitsluitend de hoofd produkten, zonder alle bijbehorende items. In een layout is dit te realiseren via subsummaries en een print preview, maar ik vraag mij af of het ook mogelijk is om het in browse mode te doen.
Een portal laat evenveel objecten zien als er zijn, dus van uniekheid komt dan niks terecht. Ik heb het nu tijdelijk opgelost door aan een global een lijst toe te kennen gebaseerd op de waarden van het unieke produktveld. Zo is dan toch een radio buttons lijst te realiseren die redelijk overzichtelijk is.
Maar de hamvraag is: zijn er alternatieve mogelijkheden?
ter info en bijna tot slot:
Een van de voornaamste opdrachten aan mij bij de herbouw was: niet meer files dan strikt noodzakelijk. Hoewel ik niet zonder meer mij in allerlei bochten wil wringen om alles in 1 file te proppen, is deze opdracht wel degelijk iets om rekening mee te houden. Klant is immers koning! En er zit ook wel een element van redelijkheid in, want deze applicatie draait in al onze vestigingen ter wereld en daar is de expertise niet altijd in gelijke mate aanwezig en riekt een groot aantal files naar gecompliceerdheid. Zelfs als dat niet klopt...
Tot slot nog een paar details:
een produkt heeft een unieke code. Aan die code hangen component items. Die items hebben ook een unieke code. Wat voor type component het is (een motor, een steun, een stuk geleideband) wordt aangegeven met keywords. Op die manier kunnen alle typen componenten in een en dezelfde file worden ondergebracht, in plaats van in zoveel tabellen als er typen componenten zijn. De programmeur die streng in de leer is zal wellicht geneigd zijn om te kiezen voor losse tabellen, maar in mijn geval is dat niet zo gebeurd, onder meer vanwege de stricte wensen van de opdrachtgever.
Question
Nicky
Beste mensen,
Ik ben al lange tijd bezig een oude applicatie, gebouwd in FMP 2 (!) en tjokvol herhalende velden (!!), te herbouwen. Het project nadert zijn eerste definitieve test. Maar met name in de user interface duiken nogal wat struikelblokken op. Ik vraag me af of een van jullie inventieve geesten daar suggesties over heeft.
Het zou te ver voeren de hele applicatie uit te leggen (dat wil ik overigens via backchannel best doen). Maar het hoofddoel is het berekenen van prijzen voor material handling systemen (lopende banden, distributie centra apparatuur etc.)
Ten grondslag aan alles ligt een soort produkt catalogus. Bij ieder produkt, dat een unieke code heeft, hoort een lijst van componenten. De gebruiker kies in een andere file op basis van de unieke code een produkt. In de oude situatie resulteerde dit in 1 record per produkt, de componenten 'woonden' in enkele herhalende velden.
Inmiddels heb ik dit deel van de applicatie omgebouw naar line items files. Afhankelijk van het produkt en de bijbehorende componenten zal; zijn nieuwe file niet slechts 1 record per produkt bevatten, maar zoveel records als er componenten zijn gekozen.
Voorbeeld:
een stukje lopende band van type aA heeft 22 componenten. De gebruiker kiest aA op grond van die type code, ziet een lijst in een portal waaruit hij kan kiezen. Als hij 1 motor, een noodstop en een frame kiest, zal zijn file bestaan uit drie records. Vergelijk met vroeger: toen zou dit 1 record zijn geworden met de complete lijst componenten, waarvan bij slechts 3 de gewenste aantallen werden ingevuld.
De gebruiker vindt het prachtig dat hij nu al die componenten separaat in zijn file heeft. Hij kan nu immers snel een analyse maken van hoeveel motoren er van een bepaald type inzitten. Hij kan ook bepaalde componenten isoleren etc. Maar hij kent ook situaties waarin hij een lijst wil zien van uitsluitend de hoofd produkten, zonder alle bijbehorende items. In een layout is dit te realiseren via subsummaries en een print preview, maar ik vraag mij af of het ook mogelijk is om het in browse mode te doen.
Een portal laat evenveel objecten zien als er zijn, dus van uniekheid komt dan niks terecht. Ik heb het nu tijdelijk opgelost door aan een global een lijst toe te kennen gebaseerd op de waarden van het unieke produktveld. Zo is dan toch een radio buttons lijst te realiseren die redelijk overzichtelijk is.
Maar de hamvraag is: zijn er alternatieve mogelijkheden?
ter info en bijna tot slot:
Een van de voornaamste opdrachten aan mij bij de herbouw was: niet meer files dan strikt noodzakelijk. Hoewel ik niet zonder meer mij in allerlei bochten wil wringen om alles in 1 file te proppen, is deze opdracht wel degelijk iets om rekening mee te houden. Klant is immers koning! En er zit ook wel een element van redelijkheid in, want deze applicatie draait in al onze vestigingen ter wereld en daar is de expertise niet altijd in gelijke mate aanwezig en riekt een groot aantal files naar gecompliceerdheid. Zelfs als dat niet klopt...
Tot slot nog een paar details:
een produkt heeft een unieke code. Aan die code hangen component items. Die items hebben ook een unieke code. Wat voor type component het is (een motor, een steun, een stuk geleideband) wordt aangegeven met keywords. Op die manier kunnen alle typen componenten in een en dezelfde file worden ondergebracht, in plaats van in zoveel tabellen als er typen componenten zijn. De programmeur die streng in de leer is zal wellicht geneigd zijn om te kiezen voor losse tabellen, maar in mijn geval is dat niet zo gebeurd, onder meer vanwege de stricte wensen van de opdrachtgever.
Elk advies is welkom!
Vriendelijke groet en bedankt voor uw aandacht,
Nicky
6 answers to this question
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.