Grunnleggende om 4th Dimension Learning

Viktige takeaways

• 4D-verktøylinjen er et bekvemmelighetslag, ikke et krav – å skjule den er et legitimt første skritt for mange utviklere fordi ikonene er lite intuitive og menylinjen gir tilgang til de samme kommandoene.
• Databaseegenskaper bør stå på standardverdiene mens du lærer; å endre dem for tidlig kan maskere atferden du prøver å forstå.
• Egenskaper lagres med databasestrukturen, så de følger prosjektet og påvirker hver utvikler og hver utplasserte klient – behandle dem som beslutninger på teamnivå, ikke personlige preferanser.
• Skillet mellom database-egenskaper og applikasjons-/preferanse-innstillinger er viktig: den ene endrer produktet du leverer, den andre endrer bare arbeidsmiljøet ditt.
• En disiplinert oppsettsrekkefølge – opprett database, gjennomgå egenskaper, definer tabeller, definer felt, bygg skjemaer, koble til verdilister, legg inn eksempeldata – forhindrer omarbeid senere.

Hvorfor verktøylinjen er det første du bør bestemme deg for

4D-verktøylinjen sitter øverst i designmiljøet og gir rask tilgang til vanlige handlinger: åpne strukturredigeringen, skjemaredigeringen, metoderedigeringen, kjøre databasen, og så videre. I prinsippet høres det nyttig ut.

I praksis synes mange utviklere – inkludert forfatteren av de originale notatene denne artikkelen er basert på – at den er direkte distraherende. Ikonene er ikke selvforklarende, og det å holde musen over for å oppdage hva hver enkelt gjør, avbryter den mentale flyten ved design av en tabell eller et skjema.

Hvis dette beskriver deg, kan du slå den av. Åpne dialogboksen Databaseegenskaper fra Design-menyen (i klassisk 4D nås dette gjennom området Egenskaper/Preferanser), finn avkrysningsboksen Vis verktøylinje og fjern merket. Verktøylinjen forsvinner fra designmiljøet, og du navigerer i stedet gjennom menylinjen — Struktur, Skjema, Metode, Kjør, og så videre.

Dette er en liten avgjørelse, men den illustrerer et større prinsipp som er verdt å internalisere tidlig: 4D gir deg mye overflate, og ikke alt er nyttig for deg på dag én. Jobben din som nybegynner er å redusere støy slik at du kan se den underliggende modellen – tabeller, felt, skjemaer og relasjonene mellom dem.

Noen få praktiske merknader om beslutningen om verktøylinjen:

• Å skjule den er reversibelt. Ingenting ved å fjerne merket i boksen er destruktivt. Hvis du senere vil ha den tilbake, åpner du den samme dialogboksen på nytt og merker av for den.
• Menylinjen er kilden til sannheten. Hver knapp i verktøylinjen tilsvarer en menykommando. Å lære menybanen er mer varig kunnskap enn å lære posisjonen til et ikon.
• Tastatursnarveier slår begge deler. Når du kjenner menykommandoene, er det raskere å lære snarveiene deres (for eksempel snarveien for å kjøre databasen eller åpne strukturredigeringen) enn enten verktøylinjen eller menyene.
• Din preferanse kan avvike fra din kollegas. Fordi denne innstillingen ligger i databaseegenskapene, er den delt. Hvis du jobber i et team, bli enige om en konvensjon i stedet for å endre den frem og tilbake.

Databaseegenskaper: Hva de er og hvorfor de betyr noe

Dialogboksen Databaseegenskaper er der du konfigurerer innstillinger som gjelder for databasen som helhet, snarere enn for en enkelt tabell, et felt eller et skjema. Det er en av de første dialogene du møter etter å ha opprettet en ny database, og det er lett å enten ignorere den helt eller overkonfigurere den.

Relatert: Airtable — Et regneark-enkelt grensesnitt som sitter på toppen av en ekte relasjonsdatabase, med automatiseringer, visninger og delbare grensesnitt..

Det viktigste å forstå er omfanget av disse innstillingene. Databaseegenskaper lagres i databasestrukturfilen. Det betyr:

• De er delt — hver utvikler som åpner strukturen ser de samme egenskapsverdiene.
• De leveres — når du bygger en kompilert applikasjon eller distribuerer den tolkede databasen, følger egenskapene med.
• De er vedvarende — de overlever omstarter, ombygginger og (i de fleste tilfeller) strukturoppgraderinger.

Kontraster dette med innstillinger som finnes i selve 4D-applikasjonen eller i en preferansefil per bruker. Disse påvirker bare din maskin og din økt. Skillet er viktig fordi en endring som føles som «bare min preferanse», faktisk kan endre atferden for alle.

En praktisk regel for nybegynnere

Den opprinnelige veiledningen her er god og verdt å gjenta med ettertrykk: la de andre egenskapene stå på standardverdiene inntil videre. Det er mange alternativer i den dialogboksen, og de fleste av dem gjelder scenarier du ikke har møtt ennå. Å endre en egenskap du ikke forstår, er en pålitelig måte å skape en feil som ser ut som et kodeproblem, men som faktisk er et konfigurasjonsproblem – den vanskeligste typen å diagnostisere.

Hvis du handler: Zoho Creator — En lavkode-appbygger som kobles til den bredere Zoho-pakken og priser per bruker i stedet for per app..

Etter hvert som du blir mer kjent med 4D, vil du begynne å kjenne igjen når en egenskap er relevant. Det er det rette tidspunktet å endre den på. Eksperimentering oppmuntres, men gjør det bevisst: endre én egenskap, observer effekten og noter hva som skjedde.

Hvordan bestemme om en egenskap skal endres

Når du blir fristet til å endre noe i dialogboksen Databaseegenskaper, kjør det gjennom disse spørsmålene:

1. Forstår jeg hva denne innstillingen kontrollerer? Hvis ikke, la den stå. Slå det opp først.
2. Er dette en prosjektomfattende beslutning eller en personlig? Hvis den er personlig, hører den sannsynligvis ikke hjemme her.
3. Vil dette påvirke utplasserte klienter? Hvis ja, må det være et bevisst, dokumentert valg.
4. Kan jeg angre det enkelt? De fleste egenskaper er reversible, men noen samhandler med andre på måter som ikke er åpenbare.
5. Har jeg testet det i en kopi av databasen? For alt som ikke er trivielt, test på en duplikatstruktur før du committer.

Oppsettsekvensen, og hvor egenskaper passer inn

Det hjelper å se trinnet med egenskaper i sammenheng. Læringsstien lagt ut i denne serien er:

1. Opprett en database — start en ny strukturfil.
2. Databaseegenskaper — gå gjennom innstillingene for hele prosjektet, og godta foreløpig standardinnstillingene.
3. Tabeller — definer enhetene applikasjonen din skal lagre (kunder, fakturaer, produkter og så videre).
4. Datafelt — definer attributtene til hver tabell, og velg passende felttyper.
5. Skjemaer — utform inndata- og visningsskjermene brukerne faktisk skal jobbe med.
6. Verdilister (valglister) — lever kontrollert vokabular slik at brukere velger fra gyldige alternativer i stedet for å skrive fritekst.
7. Skriv inn eksempeldata — fyll ut databasen slik at du kan teste skjemaer og lister mot realistisk innhold.

Egenskaper kommer i andre rekke fordi de rammer inn alt som følger, men de er bevisst ikke stedet for å bruke energien tidlig. Det intellektuelle arbeidet i 4D ligger i trinn 3 til 6: å få datamodellen riktig, og deretter gjøre den brukbar.

Hvorfor rekkefølgen er viktig

• Tabeller før felt. Du kan ikke definere et felt på en fornuftig måte før du vet hvilken tabell det tilhører og hva den tabellen representerer.
• Felt før skjemaer. Et skjema er en visning av felt. Å utforme skjemaer først fører til felt som kun eksisterer for å betjene en layout.
• Skjemaer før verdilister (i praksis). Du oppdager ofte hvilke felt som trenger en valgliste mens du bygger skjemaet som bruker dem.
• Eksempeldata sist, men ikke minst. Tomme skjemaer skjuler problemer. Et skjema som ser bra ut med null poster, kan falle fra hverandre med ekte navn, lange adresser og grensetilfeller (edge-case values).

Databaseegenskaper vs. applikasjonspreferanser: En sammenligning

Nybegynnere blander ofte disse to kategoriene. De konfigureres på forskjellige steder, har forskjellig omfang og bør behandles forskjellig.

Aspekt	Databaseegenskaper	Applikasjons- / brukerpreferanser
Omfang	Databasestrukturen og alt bygget fra den	Din 4D-applikasjon og din arbeidsøkt
Hvem det påvirker	Alle utviklere og alle utplasserte klienter	Vanligvis bare deg
Hvor den bor	Inne i strukturfilen	I 4D-applikasjonen eller på en brukerspesifikk innstillingslokasjon
Følger med prosjektet?	Ja	Nei
Typiske eksempler	Verktøylinjesynlighet, oppstartsadferd, strukturomfattende alternativer	Vinduplasseringer, editor-font, lister over nylige filer
Råd til nybegynnere	Godta standardinnstillinger; endre bevisst og dokumenter	Juster fritt for å passe din komfort

Verktøylinjeinnstillingen er et litt uvanlig tilfelle: det føles som en personlig preferanse, men det er eksponert som en databaseegenskap. Det er nettopp derfor det er verdt å stoppe opp ved. Når en innstillings plassering og dens tilsynelatende omfang ikke samsvarer, sett ned farten og tenk på hvem andre som blir påvirket.

Relatert: Knack — En databasebygger uten kode rettet mot portaler, kataloger og interne verktøy – med fastpris i stedet for avgifter per bruker..

Praktisk veiledning for din første økt

Hvis du setter deg ned med 4D for første gang, er her en konkret måte å bruke den første timen produktivt på.

• Opprett databasen med et tydelig, beskrivende navn. Unngå mellomrom og spesialtegn i strukturfilnavnet hvis du planlegger å flytte det mellom maskiner eller referere til det fra skript.
• Åpne Databaseegenskaper og les gjennom alternativene uten å endre dem. Lesing er gratis; det bygger et mentalt kart over hva som kan konfigureres.
• Fjern merket for “Vis verktøylinje” hvis du synes det er distraherende. Dette er den eneste endringen den opprinnelige veiledningen støtter, og den er trygg.
• Lukk dialogen og gå videre til Tabeller. Motstå trangen til å utforske hver eneste fane.
• Hold en kort notatfil hvor du registrerer alle egenskaper du faktisk endrer og hvorfor. Ditt fremtidige jeg, og dine lagkamerater, vil takke deg.

Vanlige nybegynnerfeil på dette stadiet

• Overkonfigurering før modellering. Å bruke en time i egenskapsdialogen og ti minutter på datamodellen er bakvendt.
• Å anta at en innstilling er personlig når den er delt. Se sammenligningstabellen ovenfor.
• Endre flere egenskaper samtidig. Hvis noe går i stykker, vil du ikke vite hvilken endring som forårsaket det.
• Ignorere dialogen fullstendig. Standardinnstillinger er vanligvis riktige, men “vanligvis” er ikke “alltid” — vit hva som er der.

Hvor du kan gå dypere

4D-plattformen har en lang historie og en betydelig mengde dokumentasjon. Den offisielle 4D-dokumentasjonssiden vedlikeholdt av 4D SAS er den autoritative referansen for hver egenskap, kommando og editor i produktet, og den er verdt å bokmerke tidlig. For generell bakgrunn om produktet og dets opprinnelse, gir Wikipedia-artikkelen om 4D (programming language) nyttig kontekst om hvordan plattformen utviklet seg fra en relasjonsdatabase til et fullstendig applikasjonsutviklingsmiljø.

Hvis du kommer fra en SQL-bakgrunn, er Wikipedia-oversikten over relasjonsmodellen en nyttig oppfriskning av konseptene som 4D implementerer i sitt eget formspråk – tabeller, poster, felt og relasjoner – selv om 4Ds terminologi og verktøy skiller seg fra en typisk SQL-server. Og fordi 4D-applikasjoner ofte distribueres sammen med forretningsprogramvare for generell bruk, er dokumentasjonssidene for Microsoft Learn og Apple Developer nyttige referanser når du trenger å forstå vertsoperativsystemets konvensjoner for vinduer, filer og brukergrensesnittets oppførsel.

Vårt valg: Claris FileMaker Pro — Den langvarige relasjonsdatabaseplattformen for team som trenger tilpassede apper på skrivebord, nett og mobil fra én enkelt fil..

Ingenting av dette erstatter praktisk tid i strukturredigereren. Den raskeste måten å lære 4D på er å bygge en liten, ekte database – noe du faktisk ønsker å spore – og la egenskapsdialogen forbli stille i bakgrunnen til du har en grunn til å åpne den.

Vanlige spørsmål

Bør jeg skjule 4D-verktøylinjen?

Det er helt et spørsmål om personlig arbeidsstil. Mange utviklere skjuler den fordi ikonene ikke er intuitive og menylinjen viser de samme kommandoene, mens andre foretrekker tilgang med ett klikk. Innstillingen kan reverseres, så prøv begge måter og behold den som hjelper deg med å holde fokus.

Er databaseegenskaper det samme som mine personlige preferanser?

Nei. Databaseegenskaper lagres sammen med strukturfilen og gjelder derfor for alle utviklere og alle distribuerte klienter. Personlige preferanser påvirker kun din egen maskin og økt. Når en innstilling føles personlig, men finnes i dialogboksen for databaseegenskaper, må du behandle den som en delt avgjørelse.

Hvorfor skal jeg la standardverdiene for egenskaper være i fred med det første?

Fordi de fleste alternativene adresserer situasjoner du ikke har vært borti ennå, og å endre en innstilling du ikke forstår kan føre til oppførsel som ser ut som en kodefeil, men som egentlig er et konfigurasjonsproblem. Standardverdier er et rimelig utgangspunkt; se på dem på nytt når du vet hva hver enkelt gjør.

Hva er riktig rekkefølge for å sette opp en ny 4D-database?

Opprett databasen, se gjennom egenskapene, definer tabellene dine, definer feltene i hver tabell, utform skjemaene, sett opp verdilister for kontrollerte felt, og skriv deretter inn eksempeldata. Denne rekkefølgen holder hver beslutning forankret i den forrige og unngår omarbeiding.

Må jeg konfigurere egenskaper før jeg bygger tabeller og skjemaer?

Nei. Egenskapsdialogen rammer inn prosjektet, men det vesentlige arbeidet skjer i struktur- og skjemaredigererne. Du kan bygge en komplett, fungerende database uten å berøre de fleste egenskapene, og du kan gå tilbake til dem senere når et spesifikt behov oppstår.

Hvordan vet jeg når det er på tide å endre en databaseegenskap?

Når du kan angi tydelig hva innstillingen kontrollerer, hvem den påvirker, og hva du forventer skal endre seg som et resultat – og ideelt sett etter å ha testet det på en kopi av strukturen. Hvis du ikke kan svare på disse spørsmålene ennå, la den stå på standard og fortsett å bygge.