Hoe documenteren

[Freaky]

Filemaker is een pracht van een programma , maar waar ik toch met zit is :

Hoe documenteren jullie jullie programma's ?

En dan bedoel ik op gebied van ontwikkeling ( geen gebruikershandleiding oid )

Je kan comments toevoegen in je scripts , je hebt je relationgraph , en wat nog ?

Hoe maken jullie je collega's wegwijs in je spaghetti van hersenspinsels ?

Gebruiken jullie een standaard , extern programma , ... ?

Alvast bedankt voor de tips

 

[Ari]

Volgens conventies en standaarden werken is alles. Zoiets is heel persoonlijk en je komt er heel wat (niet) tegen in het veld...

Deze heb ik in de loop der jaren ontwikkeld en zijn inmiddels heilig als iemand een FM klus voor mij doet.

EtW Filemaker Conventions.pdf

[hans erik]

Tsja, documenteren...

Ik zorg altijd voor veel comments in de scripts, een goed opgeruimd dataschema en ik voorzie bijna alle velden van commentaar.

En verder zorg ik meestal voor een helptabel waarin ook de Field Comments worden gedownload, die dan weer als Tooltips gebruikt worden. Maar voor 'echte' documentatie zijn er niet zoveel goede tools binnen FM, helaas. Want de beste documentatie is de documentatie die je echt gebruikt, en die dus altijd up to date en binnen muisbereik is.

Bepaalde specifieke oplossingen schrijf ik wel op in een Word- of Pagesdocument.

[hans erik]

On 10/9/2020 at 3:47 PM, Ari said:

Volgens conventies en standaarden werken is alles. Zoiets is heel persoonlijk en je komt er heel wat (niet) tegen in het veld...

Deze heb ik in de loop der jaren ontwikkeld en zijn inmiddels heilig als iemand een FM klus voor mij doet.

EtW Filemaker Conventions.pdf 227.19 kB · 16 downloads

Ik gebruik al jaren een systeem waarbij elke Table Occurrence een code en een naam heeft. De naam is min of meer vrij (maar verwijst natuurlijk wel naar de basetable cq functie van de TableOccurrence, maar de code geeft de hierarchie van de relaties weer. Uiteraard alleen icm Clusters van Table Occurrences (anker-boei, of hoe je het wilt noemen). In een 'alles-met-alles verbonden' schema is dit uiteraard onmogelijk.

Bijvoorbeeld een TOC gebaseerd op de tabel 'relaties' heeft dan RL_relaties.

De TOC met de contactpersonen die aan de relaties zijn gekoppeld: RL01_personen. Contacten van een persoon: RL011_contacten.

De orders van die relatie: RL02_orders.

enz.

En ik gebruik nooit spaties of tildes in namen van tabellen, velden of Table Occurrences. De hele boel is altijd 'SQL-safe'.

13 oktober 2020 aangepast door hans erik

[hans erik]

Ik gebruik sinds kort ook FMPerception, wat eigenlijk het beste te omschrijven is als een 'DDR browser'. Je maakt een DDR in XML formaat van je toepassing en met FMPerception kun je  dan de structuur van je toepassing bekijken. Alles is cross-linked, dus je kijkt naar een script en je kunt meteen doorklikken naar een custom functie bijvoorbeeld. Niet echt een documentatie tool op zich, maar je kunt het wel gebruiken om je documentatie te onderhouden.

Bijvoorbeeld:

- je opent in FMPerception de DDR en je kiest de optie 'Scripts (flat)'. Je krijgt dan een lijst van alle scripts.

- vervolgens kies je 'Export results to CSV...', daarmee maak je een CSV bestand aan van al je scripts (!). Niet in XML formaat overigens, maar plain text.

- het CSV bestand importeer je in een FileMaker database en presto! je hebt een tabel met een record voor elk script, met aparte velden voor scriptnaam, scriptID, een hele toeter aan opties en eigenschappen (zoals het aantal scriptstappen, aantal comments enz.) en een veld met de scriptstappen zoals je ze in de Script Workplace ziet, plain text dus, searchable.

Uiteindelijk ben ik met een kleine FM toepassing begonnen 'FMPerception companion' waarin ik dergelijke CSV exports standaardiseer, zodat je in luttele minuten een doorzoekbare database van je toepassing kunt maken.

[Freaky]

Top , hiermee kan ik aan de slag !

[hans erik]

De nederlandse kruidenier voegt er - 2 jaar later -nog iets aan toe: FMPerception is een fanstastisch tool, maar best prijzig als je elk jaar een update doet. Een update is 50% van de aanschafprijs en dat zou de moeite waard zijn als Claris elk jaar iets wezenlijks aan Filemaker verandert. Maar doen ze al jaren niet! Dus zolang de structuur van de XML van het ddr-rapport niet echt verandert is een update van FMPerception tamelijk zinloos. Komt er echt een nieuwe versie uit, dan is een nieuwe aanschaf van FMPerception alleszins gerechtvaardigd.