4. dimension læringsgrundlag

Af HPO Software Learning Desk · Opdateret 25. september 2026

Den måske største forhindring ved at komme fra FMP-verdenen er, at 4D er fundamentalt anderledes. Programmets grundlæggende filosofi er anderledes. Terminologien er anderledes. Jeg vil forsøge at guide læseren ind i 4D ved at forklare, hvordan tingene hænger sammen mellem 4D og FMP. Men nogle af disse ting er meget svære eller umulige at relatere, fordi de er unikke for hvert produkt.

Referencer for FMP vil være for version 5.0.x og Standard Edition af 4D version 4.6.x.

Bemærk: Den nuværende vejledende udsalgspris for FMP 5.0 er $249 og for 4D Standard Edition er $349. Både 4D og FMP er cross-platform. Begge fungerer på Macintosh- og Windows-systemer. Begge har web-funktioner.

Del I vil give en smule historie for både FileMaker og 4D. Det kan være interessant at bemærke, at både 4D og FileMaker opstod på Macintosh og på omtrent samme tid (midten af 80’erne). Del I vil også dække følgende, dog ikke i for mange detaljer:

Systemkrav
Programstrukturer
Netværksforskelle
Forskelle i runtime-versionerne
Compiler
Webhosting
Datadiagrammer
Plug-ins
Værktøjer/Utilities
Ressourcer
Andre 4D URL’er

Bemærk: Den følgende rækkefølge og indhold af hver del er foreløbig.

Del II vil dække oprettelse af et simpelt 4D-program
Del III vil dække brugerdefinerede menuer
Del IV vil dække metoder
Yderligere dele TBD.

Key Takeaways

4D og FileMaker Pro voksede begge ud af midten af 1980’ernes Macintosh-databasescene, men de løser de samme problemer med meget forskellige arkitekturer.
Den sværeste del ved at flytte fra FMP til 4D er ikke syntaksen – det er den underliggende filosofi om, hvordan data, struktur og kode adskilles.
4D eksponerer en ægte relationel motor, et programmeringssprog (4D-sproget) og en compiler, hvorimod FMP historisk har lagt vægt på en enkelt-fil, layout-drevet model.
Terminologien adskiller sig markant mellem de to produkter, så at lære 4D-ordforrådet er en forudsætning for at læse enhver 4D-dokumentation.
Cross-platform-understøttelse og web-kapacitet findes i begge produkter, men måden hver af dem leverer dem på – runtime, compiler og plug-in-model – er markant forskellig.
Denne del I er et kort over terrænet; det praktiske byggearbejde starter i del II.

Hvorfor 4D føles anderledes end FileMaker Pro

Hvis du har brugt år i FileMaker Pro, er din mentale model af en database sandsynligvis bygget op omkring en enkelt fil, der indeholder tabeller, layouts, scripts og relationer på ét sted. Du åbner filen, du ser et layout, du klikker ind i et felt, og så er du i gang. Den model er praktisk, og det er en af grundene til, at FMP blev så populær blandt små teams og citizen developers.

Relateret: — En regneark-simpel grænseflade, der sidder oven på en rigtig relationel database, med automatiseringer, visninger og delbare grænseflader..

4D beder dig om at tænke anderledes. I 4D er databasens struktur (tabeller, felter, relationer) defineret i en separat strukturel kontekst fra formularerne (brugergrænsefladen) og fra metoderne (koden). Denne adskillelse ligger tættere på, hvordan traditionelle klient/server relationelle databaser er organiseret, og det er det vigtigste konceptuelle skift, som en FileMaker-udvikler skal foretage.

En nyttig måde at indramme forskellen på:

FileMaker Pro har tendens til at være dokumentcentreret. Filen er applikationen.
4D har tendens til at være strukturcentreret. Strukturen definerer datamodellen, og applikationen bygges oven på den med formularer, metoder og menuer.

Ingen af tilgangene er “bedre” i det abstrakte. FMP optimerer til hurtig iteration for en enkelt udvikler. 4D optimerer til større, mere strukturerede og mere programmerbare applikationer – hvilket er grunden til, at det tiltrak udviklere, der havde brug for et rigtigt programmeringssprog og en compiler.

Hvis du handler: — En lavkode-appbygger, der tilsluttes den bredere Zoho-suite og priser pr. bruger i stedet for pr. app..

En kort delt historie

Det er værd at dvæle ved det faktum, at både 4D og FileMaker opstod på Macintosh og på nogenlunde samme tid i midten af 1980’erne. Det er ikke en tilfældighed. Den originale Macintosh skabte et nyt marked for desktop-databaseværktøjer, der kunne bruges af enkeltpersoner og små virksomheder frem for af mainframe-operatører.

FileMaker begyndte som et Macintosh-produkt og blev senere opkøbt og udviklet af Claris (et spin-off fra Apple), hvilket er grunden til, at så mange mangeårige Mac-brugere forbinder FileMaker med Apple-økosystemet. 4D blev udviklet af ACI (ACI US i USA), og det voksede til et cross-platform udviklingsmiljø med sit eget sprog og compiler.

Begge produkter overlevede overgangen fra klassisk Mac OS til Windows og til moderne operativsystemer, og begge tilføjede web-funktioner. Denne delte afstamning er grunden til, at en FileMaker-udvikler ofte kan læse 4D-dokumentation og genkende de problemer, der bliver løst, selv når løsningerne ser ukendte ud.

Systemkrav og cross-platform realiteter

Både 4D og FMP er cross-platform. Begge fungerer på Macintosh- og Windows-systemer. Begge har web-funktioner. Det er det, de har til fælles.

Hvor de divergerer, er i hvad “cross platform” betyder for udvikleren. I en FileMaker-verden udvikler man typisk på én platform, og den samme fil åbner på den anden med layouts, der tilpasser sig. I 4D er cross-platform-udvikling mere eksplicit: du bygger en kompileret eller fortolket applikation, der skal implementeres til hver målplatform, og du skal være bevidst om platformsspecifik adfærd, filstier og grænsefladekonventioner.

Praktisk vejledning til udvikleren, der kommer fra FMP:

Relateret: — En kodefri databasebygger rettet mod portaler, mapper og interne værktøjer - med faste priser i stedet for gebyrer pr. bruger..

Beslut dine implementeringsmål tidligt. Hvis du kun implementerer til én platform, kan du ignorere mange cross-platform-nuancer. Hvis du implementerer til begge, skal du planlægge det fra den første formular.
Test på den “anden” platform, før du er dybt inde i projektet. Cross-platform-problemer er billige at rette tidligt og dyre at rette sent.
Forstå runtime-modellen. 4D skelner mellem udviklingsmiljøet og den implementerede runtime, hvilket er et koncept, FileMaker-udviklere ofte møder for første gang her.

Programstrukturer: Hvordan stykkerne passer sammen

Det er det afsnit, der giver mest afkast ved omhyggelig læsning, for det er her, den filosofiske forskel bliver konkret.

I 4D er de vigtigste strukturelle dele:

Strukturen — definitionen af tabeller, felter og relationer. Dette er din datamodel.
Formularer — brugergrænsefladen. Formularer er knyttet til tabeller og svarer til FileMaker-layouts, men de er mere eksplicit adskilt fra dataene.
Metoder — koden. 4D har et fuldt programmeringssprog, og metoder er der, hvor logikken bor.
Menuer — brugerdefinerede menuer, som del III af denne serie vil dække i detaljer.

I FileMaker Pro er disse hensyn mere sammenblandede. Et layout kan indeholde både præsentation og logik (via script-triggere og beregninger), og selve filen er containeren for alt.

Vores valg: — Den langvarige relationsdatabaseplatform til teams, der har brug for tilpassede apps på desktop, web og mobil fra en enkelt fil..

Den praktiske konsekvens er, at du i 4D vil bruge mere tid på at designe, før du bygger. Det føles langsommere i starten og hurtigere senere. FileMaker belønner, at man hopper direkte i det; 4D belønner, at man planlægger strukturen først.

En grov sammenligning:

Hensyn	FileMaker Pro (5.0.x)	4D (Standard Edition 4.6.x)
Datamodel	Tabeller og relationer inde i filen	Struktur defineret separat fra UI
Brugergrænseflade	Layouts	Formularer
Logik	Scripts og beregninger	Metoder (fuldt sprog)
Menuer	Indbyggede menuer, begrænset tilpasning	Brugerdefinerede menuer (dækket i del III)
Implementering	Åbn filen	Runtime og kompilerede implementeringsmuligheder
Udvidelse	Plug-ins	Plug-ins

Netværksforskelle

Netværk er et af de områder, hvor de to produkter divergerer på måder, der har betydning for reelle implementeringer.

FileMaker Pros netværksmodel er bygget op omkring åbning af en delt fil over et netværk, hvor FileMaker Server eller peer-to-peer-deling håndterer samtidig adgang. Det er designet til at være enkelt: du deler en fil, andre åbner den.

4D’s netværksmodel afspejler dens klient/server-arv. 4D-applikationer implementeres typisk som en klient, der forbinder til en serverproces, og udvikleren har mere kontrol — og mere ansvar — over, hvordan data bevæger sig mellem dem. Dette er vigtigt, fordi det påvirker ydeevneoptimering, record-locking-adfærd og hvordan du designer formularer, der viser store rekordsæt.

For udvikleren, der kommer fra FMP, er de vigtigste spørgsmål at stille:

Hvor mange samtidige brugere vil faktisk oprette forbindelse?
Vil applikationen køre over et LAN, et WAN eller det offentlige internet?
Hvor meget data vil hver formular trække over netværket, og kan det reduceres?

Det er spørgsmål, som FileMaker-udviklere ofte kan udskyde. I 4D har de en tendens til at dukke op tidligere.

Runtimes, compileren og hvorfor de betyder noget

To af de mest karakteristiske 4D-koncepter — og to af de mindst kendte for FileMaker-udviklere — er runtime og compileren.

En runtime er en version af din applikation, der kan distribueres til brugere, som ikke ejer 4D-udviklingsmiljøet. Det er sådan, 4D-udviklere leverer standalone-applikationer. FileMaker har et analogt koncept i runtime-løsninger, men 4D’s runtime-model er mere central for, hvordan produktet bruges kommercielt.

Compileren tager din fortolkede 4D-kode og kompilerer den til en hurtigere og mere beskyttet form. Kompilering handler ikke kun om hastighed; det handler også om at beskytte din kildekode, når du distribuerer en applikation. For udviklere, der kun har arbejdet i FileMaker, hvor filen er applikationen og kilden effektivt er filen, er dette en helt ny idé.

Sådan beslutter du, om du skal kompilere:

Kompilér, når du distribuerer til slutbrugere og ønsker ydeevne og kildebeskyttelse.
Forbliv fortolket under udvikling, hvor den hurtigere redigerings-test-cyklus betyder mere end rå hastighed.
Planlæg kompilering tidligt, fordi kode, der kompilerer rent, normalt er bedre struktureret kode.

Webhosting, datadiagrammer og plug-ins

Begge produkter har web-funktioner, men de griber webben an forskelligt. FileMakers webpublicering har historisk lagt vægt på at servere layouts til en browser. 4D’s web-funktioner er knyttet til dets sprog og dets server, hvilket giver udviklere mere programmatisk kontrol over, hvad der serveres, og hvordan.

Datadiagrammer (data charting) er et andet område, hvor 4D-udviklere historisk har grebet efter plug-ins og eksterne værktøjer til at gengive grafer og rapporter. Hvis diagrammer er vigtige for din applikation, bør du evaluere det tidligt i stedet for at antage, at det er indbygget.

Plug-ins findes i begge økosystemer. I FileMaker udvider plug-ins beregnings- og script-motoren. I 4D udvider plug-ins sproget og kan koble sig dybt ind i applikationen. Det praktiske råd er det samme i begge verdener: Foretræk indbyggede funktioner, hvor de findes, og behandl plug-ins som afhængigheder, du skal vedligeholde på tværs af versioner.

Værktøjer, hjælpeprogrammer og ressourcer

Et par vaner adskiller udviklere, der trives med 4D, fra dem, der kæmper:

Læs først den officielle dokumentation. 4D’s dokumentation er den autoritative kilde til sproget og strukturmodellen.
Brug udviklerfællesskabet. Diskussionslister og brugergrupper var, og er stadig, der hvor den praktiske 4D-viden findes.
Bevar et personligt bibliotek af metoder. Fordi 4D-kode er tekstbaseret og genbrugelig, betaler et velorganiseret metodebibliotek sig på tværs af projekter.
Lær ordforrådet bevidst. Udtryk som struktur, form, metode og runtime har specifikke betydninger i 4D, der adskiller sig fra deres FileMaker-modstykker.

For en bredere baggrund om den relationelle model, der ligger til grund for begge produkter, forbliver E. F. Codds originale arbejde med relationelle databaser den kanoniske reference, og Wikipedia-artiklen om den relationelle model er et rimeligt udgangspunkt. For historien om Macintosh-platformen, der gav anledning til begge produkter, er Wikipedia-artiklen om Macintosh en nyttig kontekst. For generel databaseterminologi er Wikipedia-artiklen om databasestyringssystemer en nyttig orientering.

Anerkendelser

Særlig tak til:

Brendan Coveney, præsident ACI US, for hans hjælp med historien om 4th Dimension.
Will Porter (wporter@polytrope.com) fra POLYTROPE SOLUTIONS, Houston, Texas, The XXII Group, for hans hjælp med at læse korrektur og holde mig på rette vej.
James Fortier (jim40er@halcyon.com) for at levere nogle af ressourcerne og hjælpe med at læse korrektur på dokumentet.
Douglas Blew (fridays@impluse.net) for forslag.
Jim Staples (jstaples@acius.com) fra ACI US, Inc., Macom/Press Relations, for korrekturlæsning og kommentarer.
David Graham (davidgraham@mac.com) for design af web- og PDF-layouts til denne vejledning.

Ofte stillede spørgsmål

Er 4D dybest set det samme som FileMaker Pro?

Nej. Begge er databaseprodukter på tværs af platforme, der opstod på Macintosh i midten af 1980’erne, og begge har web-funktioner, men deres underliggende filosofier er forskellige. FileMaker Pro er dokumentcentreret, hvor filen er applikationen, mens 4D adskiller datastrukturen, formularerne og metoderne i særskilte anliggender. Denne adskillelse er grunden til, at 4D føles mere som et traditionelt udviklingsmiljø.

Skal jeg kende et programmeringssprog for at bruge 4D?

Du kan bygge simple ting uden dyb programmering, men 4Ds virkelige styrke ligger i dets sprog og dets metoder. Kommer du fra FileMaker, hvor scripts og beregninger dækker meget, vil du opdage, at 4D forventer, at du skriver mere kode for tilsvarende funktionalitet. Gevinsten er mere kontrol og bedre struktur til større applikationer.

Hvad er en 4D runtime, og hvorfor betyder det noget?

En runtime er en distribuerbar version af din applikation, som brugere kan køre uden at eje det fulde 4D-udviklingsmiljø. Det betyder noget, fordi det er sådan, 4D-udviklere leverer selvstændige applikationer til slutbrugere. FileMaker har et lignende koncept, men i 4D er runtime-modellen mere central for kommerciel implementering.

Hvorfor skulle jeg kompilere min 4D-applikation?

Kompilering forbedrer ydeevnen og beskytter din kildekode, når du distribuerer applikationen. Under udvikling forbliver du generelt i fortolket tilstand for en hurtigere redigerings- og testcyklus, og du kompilerer, når du er klar til at sende. Kode, der kompilerer rent, har også en tendens til at være bedre organiseret, så det er umagen værd at planlægge kompilering tidligt.

Hvor forskellig er netværksdelen mellem 4D og FileMaker Pro?

FileMaker Pros netværk er bygget op omkring deling af en fil, hvor FileMaker Server eller peer-to-peer-deling håndterer samtidig adgang. 4D’s netværk afspejler dets klient/server-arv, hvilket giver udviklere mere kontrol og mere ansvar for, hvordan data bevæger sig mellem klient og server. Det påvirker præstationsoptimering, rekordlåsning og hvordan du designer formularer, der viser store rekordsæt.

Hvad vil del II af denne serie dække?

Del II vil dække oprettelse af et simpelt 4D-program og gennemgå processen fra struktur til formular til metode. Del III vil dække brugerdefinerede menuer, og del IV vil dække metoder mere i dybden. Yderligere dele skal fastlægges, og rækkefølgen og indholdet af hver del er foreløbig.

Prøv FileMaker gratis i 45 dage

Den langvarige relationsdatabaseplatform til teams, der har brug for tilpassede apps på desktop, web og mobil fra en enkelt fil.