Grunderna i lärande i fjärde dimensionen
Den här serien är utformad för att hjälpa dem som kommer från FileMaker Pro eller som har viss erfarenhet av databasdesign med ett annat program. I den här serien, närhelst “4D” används, hänvisas det till “4th Dimension” och närhelst “FMP” används, hänvisas det till “FileMaker Pro”.
Det kanske största hindret när man kommer från FMP-världen är att 4D är fundamentalt annorlunda. Programmets grundfilosofi är annorlunda. Termerna är annorlunda. Jag ska försöka vänja läsaren vid 4D genom att förklara hur saker och ting hänger ihop mellan 4D och FMP. Vissa av dessa saker är dock mycket svåra eller omöjliga att relatera till eftersom de är unika för varje produkt.
Referenser för FMP kommer att gälla version 5.0.x och Standard Edition av 4D version 4.6.x.
Obs! Det nuvarande rekommenderade försäljningspriset för FMP 5.0 är 249 USD och för 4D Standard Edition är det 349 USD. Både 4D och FMP är plattformsoberoende. Båda fungerar på Macintosh- och Windows-system. Båda har webbfunktioner.
Del I kommer att ge lite historik för både FileMaker och 4D. Det kan vara intressant att notera att både 4D och FileMaker har sitt ursprung på Macintosh och ungefär samtidigt (mitten av 80-talet). Del I kommer också att täcka, inte alltför detaljerat, följande:
- Systemkrav
- Programstrukturer
- Nätverksskillnader
- Skillnader i runtime-versionerna
- Kompilator
- Webbhosting
- Datadiagram
- Plug-ins
- Verktyg/nyttoprogram
- Resurser
- Andra 4D-URL:er
Obs: Följande ordning och innehåll för varje del är preliminärt.
Relaterat: — Den långvariga relationsdatabasplattformen för team som behöver anpassade appar på skrivbordet, webben och mobilen från en enda fil..
- Del II kommer att täcka skapandet av ett enkelt 4D-program
- Del III kommer att täcka anpassade menyer
- Del IV kommer att täcka metoder
- Ytterligare delar TBD.
Viktiga slutsatser
- 4D och FileMaker Pro växte båda ur mitten av 1980-talets Macintosh-databasscen, men de löser samma problem med väldigt olika arkitekturer.
- Den svåraste delen av att gå från FMP till 4D är inte syntaxen – det är den underliggande filosofin för hur data, struktur och kod separeras.
- 4D exponerar en sann relationsmotor, ett programmeringsspråk (4D-språket) och en kompilator, medan FMP historiskt betonade en enfils, layoutdriven modell.
- Terminologin skiljer sig kraftigt mellan de två produkterna, så att lära sig 4D-vokabulären är en förutsättning för att läsa all 4D-dokumentation.
- Plattformsoberoende stöd och webbfunktioner finns i båda produkterna, men sättet var och en levererar dem – runtime, kompilator och plug-in-modell – skiljer sig avsevärt.
- Denna del I är en karta över terrängen; det praktiska byggandet börjar i del II.
Varför 4D känns annorlunda än FileMaker Pro
Om du har tillbringat flera år i FileMaker Pro är din mentala modell av en databas förmodligen uppbyggd kring en enda fil som innehåller tabeller, layouter, skript och relationer på ett och samma ställe. Du öppnar filen, ser en layout, klickar in i ett fält och börjar arbeta. Den modellen är bekväm och det är en av anledningarna till att FMP blev så populärt bland små team och medborgarutvecklare.
4D ber dig att tänka annorlunda. I 4D definieras databasens struktur (tabeller, fält, relationer) i ett separat strukturellt sammanhang från formulären (användargränssnittet) och från metoderna (koden). Denna separation ligger närmare hur traditionella klient/server-relationsdatabaser är organiserade, och det är den enskilt viktigaste konceptuella omställningen en FileMaker-utvecklare måste göra.
Ett användbart sätt att rama in skillnaden:
Vårt val: — Ett enkelt kalkylarksgränssnitt som sitter ovanpå en riktig relationsdatabas, med automatiseringar, vyer och delbara gränssnitt..
- FileMaker Pro tenderar att vara dokumentcentrerad. Filen är applikationen.
- 4D tenderar att vara strukturcentrerad. Strukturen definierar datamodellen, och applikationen byggs ovanpå den med formulär, metoder och menyer.
Inget av tillvägagångssätten är “bättre” i det abstrakta. FMP optimerar för snabb iteration av en enskild utvecklare. 4D optimerar för större, mer strukturerade och mer programmerbara applikationer — vilket är anledningen till att det lockade utvecklare som behövde ett riktigt programmeringsspråk och en kompilator.
En kort gemensam historik
Det är värt att stanna upp vid det faktum att både 4D och FileMaker har sitt ursprung på Macintosh och ungefär samtidigt, i mitten av 1980-talet. Det är ingen slump. Den ursprungliga Macintosh-datorn skapade en ny marknad för stationära databasverktyg som kunde användas av privatpersoner och småföretag snarare än av stordatoroperatörer.
FileMaker började som en Macintosh-produkt och köptes senare upp och utvecklades av Claris (en spin-off från Apple), vilket är anledningen till att så många långvariga Mac-användare associerar FileMaker med Apples ekosystem. 4D utvecklades av ACI (ACI US i USA) och växte till en plattformsoberoende utvecklingsmiljö med eget språk och kompilator.
Båda produkterna överlevde övergången från klassiskt Mac OS till Windows och till moderna operativsystem, och båda lade till webbfunktioner. Den gemensamma härkomsten är anledningen till att en FileMaker-utvecklare ofta kan läsa 4D-dokumentation och känna igen problemen som löses, även när lösningarna ser okända ut.
Systemkrav och plattformsoberoende verklighet
Både 4D och FMP är plattformsoberoende. Båda fungerar på Macintosh- och Windows-system. Båda har webbfunktioner. Så mycket är gemensamt.
Där de skiljer sig åt är i vad “cross platform” betyder för utvecklaren. I en FileMaker-värld utvecklar du vanligtvis på en plattform och samma fil öppnas på den andra, med layouter som anpassar sig. I 4D är plattformsoberoende utveckling mer explicit: du bygger en kompilerad eller tolkad applikation som måste distribueras till varje målplattform, och du måste vara medveten om plattformsspecifika beteenden, filsökvägar och gränssnittskonventioner.
Praktisk vägledning för utvecklaren som kommer från FMP:
- Bestäm dina distributionsmål tidigt. Om du bara distribuerar till en plattform kan du ignorera många plattformsoberoende nyanser. Om du distribuerar till båda, planera för det från det första formuläret.
- Testa på den “andra” plattformen innan du är djupt inne i projektet. Plattformsproblem är billiga att åtgärda tidigt och dyra att åtgärda sent.
- Förstå runtime-modellen. 4D skiljer mellan utvecklingsmiljön och den distribuerade körtiden (runtime), vilket är ett koncept som FileMaker-utvecklare ofta möter för första gången här.
Programstrukturer: Hur bitarna passar ihop
Detta är det avsnitt som mest lönar sig att läsa noggrant, eftersom det är här den filosofiska skillnaden blir konkret.
I 4D är de viktigaste strukturdelarna:
- Strukturen — definitionen av tabeller, fält och relationer. Detta är din datamodell.
- Formulär — användargränssnittet. Formulär är kopplade till tabeller och motsvarar FileMaker-layouter, men de är mer explicit separerade från data.
- Metoder — koden. 4D har ett fullständigt programmeringsspråk, och metoderna är där logiken bor.
- Menyer — anpassade menyer, som del III av denna serie kommer att täcka i detalj.
I FileMaker Pro är dessa ansvarsområden mer sammanblandade. En layout kan innehålla både presentation och logik (via skripttriggers och beräkningar), och själva filen är behållaren för allt.
Den praktiska konsekvensen är att du i 4D kommer att lägga mer tid på att designa innan du bygger. Det känns långsammare till en början och snabbare senare. FileMaker belönar att man hoppar rakt in; 4D belönar att man planerar strukturen först.
En grov jämförelse:
| Område | FileMaker Pro (5.0.x) | 4D (Standard Edition 4.6.x) |
|---|---|---|
| Datamodell | Tabeller och relationer inuti filen | Struktur definierad separat från UI |
| Användargränssnitt | Layouter | Formulär |
| Logik | Skript och beräkningar | Metoder (fullständigt språk) |
| Menyer | Inbyggda menyer, begränsad anpassning | Anpassade menyer (omfattas i del III) |
| Distribution | Öppna filen | Runtime och kompilerade distributionsalternativ |
| Extension | Plug-ins | Plug-ins |
Nätverksskillnader
Nätverk är ett av de områden där de två produkterna skiljer sig åt på sätt som är viktiga för verkliga distributioner.
FileMaker Pros nätverksmodell är uppbyggd kring att öppna en delad fil över ett nätverk, där FileMaker Server eller peer-to-peer-delning hanterar samtidig åtkomst. Den är utformad för att vara enkel: du delar en fil, andra öppnar den.
4D:s nätverksmodell återspeglar dess klient/server-arv. 4D-applikationer distribueras vanligtvis som en klient som ansluter till en serverprocess, och utvecklaren har mer kontroll – och mer ansvar – över hur data rör sig mellan dem. Detta är viktigt eftersom det påverkar prestandajustering, rekordlåsningsbeteende och hur du designar formulär som visar stora rekorduppsättningar.
För utvecklaren som kommer från FMP är nyckelfrågorna att ställa:
- Hur många samtidiga användare kommer faktiskt att ansluta?
- Kommer applikationen att köras över ett LAN, ett WAN eller det publika internet?
- Hur mycket data kommer varje formulär att hämta över nätverket, och kan det minskas?
Det här är frågor som FileMaker-utvecklare ofta kan skjuta upp. I 4D tenderar de att dyka upp tidigare.
Runtimes, kompilatorn och varför de är viktiga
Två av de mest utmärkande 4D-koncepten – och två av de minst bekanta för FileMaker-utvecklare – är runtime och kompilatorn.
En runtime är en version av din applikation som kan distribueras till användare som inte äger 4D-utvecklingsmiljön. Det är så 4D-utvecklare levererar fristående applikationer. FileMaker har ett analogt koncept i form av runtime-lösningar, men 4D:s runtime-modell är mer central för hur produkten används kommersiellt.
Kompilatorn tar din tolkade 4D-kod och kompilerar den till en snabbare, mer skyddad form. Kompilering handlar inte bara om hastighet; det handlar också om att skydda din källkod när du distribuerar en applikation. För utvecklare som bara har arbetat i FileMaker, där filen är applikationen och källkoden i praktiken är filen, är detta en genuint ny idé.
Så här bestämmer du om du ska kompilera:
- Kompilera när du distribuerar till slutanvändare och vill ha prestanda och källskydd.
- Behåll tolkad kod under utveckling, där den snabbare redigerings- och testcykeln är viktigare än råhastighet.
- Planera för kompilering tidigt, eftersom kod som kompileras rent vanligtvis är bättre strukturerad kod.
Webbhotsing, datadiagram och plug-ins
Båda produkterna har webbfunktioner, men de närmar sig webben på olika sätt. FileMakers webbpublicering har historiskt betonat att servera layouter till en webbläsare. 4D:s webbfunktioner är knutna till dess språk och dess server, vilket ger utvecklare mer programmatisk kontroll över vad som serveras och hur.
Datadiagram (data charting) är ett annat område där 4D-utvecklare historiskt sett har använt plug-ins och externa verktyg för att rendera grafer och rapporter. Om diagram är viktigt för din applikation, utvärdera det tidigt istället för att anta att det är inbyggt.
Plug-ins finns i båda ekosystemen. I FileMaker utökar plug-ins beräknings- och skriptmotorn. I 4D utökar plug-ins språket och kan haka djupt in i applikationen. De praktiska råden är desamma i båda världarna: föredra inbyggda funktioner där de finns, och behandla plug-ins som beroenden du måste underhålla genom olika versioner.
Verktyg, hjälpmedel och resurser
Några vanor skiljer utvecklare som trivs med 4D från dem som kämpar:
- Läs den officiella dokumentationen först. 4D:s dokumentation är den auktoritativa källan för språket och strukturmodellen.
- Använd utvecklargemenskapen. Diskussionslistor och användargrupper var, och förblir, platserna där praktisk 4D-kunskap finns.
- Håll ett personligt bibliotek med metoder. Eftersom 4D-kod är textbaserad och återanvändbar lönar sig ett välorganiserat metodbibliotek över flera projekt.
- Lär dig vokabulären medvetet. Termer som struktur, formulär, metod och runtime har specifika betydelser i 4D som skiljer sig från deras FileMaker-motsvarigheter.
För en bredare bakgrund om den relationsmodell som ligger till grund för båda produkterna förblir E. F. Codds ursprungliga arbete om relationsdatabaser den kanoniska referensen, och Wikipedia-artikeln om relationsmodellen är en rimlig utgångspunkt. För historien om Macintosh-plattformen som gav upphov till båda produkterna är Wikipedia-artikeln om Macintosh ett användbart sammanhang. För allmän databasterminologi är Wikipedia-artikeln om databashanteringssystem en hjälpsam orientering.
Tack
Särskilt tack till:
- Brendan Coveney, President ACI US, för hans hjälp med 4th Dimensions historia.
- Will Porter (wporter@polytrope.com) från POLYTROPE SOLUTIONS, Houston, Texas, The XXII Group, för hans hjälp med korrekturläsning och för att ha hållit mig på rätt spår.
- James Fortier (jim40er@halcyon.com) för att ha tillhandahållit några av resurserna och hjälpt till att korrekturläsa dokumentet.
- Douglas Blew (fridays@impluse.net) för förslag.
- Jim Staples (jstaples@acius.com) från ACI US, Inc., Macom/Press Relations, för korrekturläsning och kommentarer.
- David Graham (davidgraham@mac.com) för design av webb- och PDF-layouter för den här guiden.
Vanliga frågor
Är 4D i princip samma sak som FileMaker Pro?
Nej. Båda är plattformsoberoende databasprodukter som har sitt ursprung på Macintosh i mitten av 1980-talet och båda har webbkapacitet, men deras underliggande filosofier skiljer sig åt. FileMaker Pro är dokumentcentrerad, där filen är applikationen, medan 4D separerar datastrukturen, formulären och metoderna i distinkta ansvarsområden. Den separationen är anledningen till att 4D känns mer som en traditionell utvecklingsmiljö.
Behöver jag kunna ett programmeringsspråk för att använda 4D?
Du kan bygga enkla saker utan djup programmering, men 4D:s verkliga kraft ligger i dess språk och dess metoder. Om du kommer från FileMaker, där skript och beräkningar täcker mycket, kommer du att upptäcka att 4D förväntar sig att du skriver mer kod för motsvarande funktionalitet. Vinsten är mer kontroll och bättre struktur för större applikationer.
Vad är en 4D runtime, och varför spelar det någon roll?
En runtime är en distribuerbar version av din applikation som användare kan köra utan att äga hela 4D-utvecklingsmiljön. Det spelar roll eftersom det är så 4D-utvecklare levererar fristående applikationer till slutanvändare. FileMaker har ett liknande koncept, men i 4D är runtime-modellen mer central för kommersiell driftsättning.
Varför skulle jag kompilera min 4D-applikation?
Kompilering förbättrar prestandan och skyddar din källkod när du distribuerar applikationen. Under utvecklingen förblir du vanligtvis i tolkat läge för en snabbare redigerings- och testcykel, och du kompilerar när du är redo att leverera. Kod som kompilerar rent tenderar också att vara bättre organiserad, så det är värt att planera för kompilering tidigt.
Hur skiljer sig nätverksdelen mellan 4D och FileMaker Pro?
FileMaker Pros nätverk är uppbyggt kring att dela en fil, där FileMaker Server eller peer-to-peer-delning hanterar samtidig åtkomst. 4D:s nätverk återspeglar dess klient/server-arv, vilket ger utvecklare mer kontroll och mer ansvar över hur data rör sig mellan klient och server. Det påverkar prestandajustering, rekordlåsning och hur du designar formulär som visar stora rekordmängder.
Vad kommer del II av den här serien att täcka?
Del II kommer att täcka skapandet av ett enkelt 4D-program, genom att gå igenom processen från struktur till formulär till metod. Del III kommer att täcka anpassade menyer, och del IV kommer att täcka metoder mer på djupet. Ytterligare delar är ännu inte fastställda, och ordningen och innehållet i varje del är preliminära.
Copyright © 1994-2000 HPO Soft. All rights reserved.
Bygg en anpassad app gratis i 15 dagar
En appbyggare med låg kod som ansluts till den bredare Zoho-sviten och priser per användare snarare än per app.