Ga naar inhoud
  • 0

Separate data format op server: wat met accounts?


LcGrs

Vraag

Hallo,

 

Even een vraag (wellicht al voor wat gevorderden):

Ik ben al een heel eind aan het experimenteren met Filemaker en... het loopt als een trein. Ontwikkelen gaat erg vlot en de samenwerking tussen FM Pro (server) en FM Go is geweldig. Ik heb hier een testversie van FM Server geïnstalleerd: ik heb nog nooit zo snel een server werkend gekregen (maar om eerlijk te zijn, ik heb ook nog nooit een server opgezet). 10' tijd en de zaak was draaiend.

In loop hier ook wat te dromen over / experimenteren met wat in de toekomst een grotere toepassing zou kunnen worden (als het haalbaar is) en heb daarbij een vraag betreffende FM Server:

Ik heb begrepen dat er via "Separate Data Format" een mogelijkheid is om de database en script in afzonderlijke bestanden te zetten, maar toch nog even deze vraag: wat dan met accounts en privilegesets? Moet dat in het bestand met scripts of in het bestand met de database?

Het tweede lijkt me logischer, want als je het een nieuwe versie van het script installeert wil je niet dat de gebruiker alle accounts en privilegesets opnieuw moet installeren.

 

Iemand tips?

Bedankt!

Link naar reactie

Aanbevolen berichten

  • 0

Daar ben ik ook mee bezig en het werkt gewoon goed als je de privileges in het script en layoutsbestand doet.

Je moet dan wel in het database deel de koppeling maken naar het database bestand en daar de relaties maken anders werken je zaken niet correct.

De database in het andere.

Je kunt het scriptbestand autoriseren in het data bestand.

Zo heb je de data en de oplossing gescheiden.

Link naar reactie
  • 0

Wat getest:

 

Account gegevens in database bestand, geeft dat de database niet toegankelijk is zonder aanmelden met account en wachtwoord: perfect. Alleen kan het bestand met script geopend worden zonder inloggen en geeft deze toegang tot de gegevens in de database (zonder aanmelden met paswoord) - niet goed dus

 

Blijkbaar moet de gegevens met accounts en privilegesets in het bestand met scripts, en een (1) wachtwoord op het bestand met de database zodat dit niet rechtstreeks kan geopend worden.

Dit werkt wel, maar dan zit ik met een vraag: wat als je een nieuwe versie van het script installeert, wat dan? Je zou kunnen een script maken dat accounts uit de database laadt en nieuwe accounts aanmaakt met bijhorende scriptprivileges. Allemaal bruikbaar, maar wat met de instellingen van die privilegescripts? Moet de gebruiker die dan allemaal opnieuw instellen telkens er een nieuwe versie geïnstalleerd wordt? Da's onbegonnen werk... - Of niet?

Link naar reactie
  • 0

Ik gebruik het separation model eigenlijk altijd en ik pas dan de volgende constructie toe:

 

- een interfacefile waar normale gebruikers aanloggen als guest (zonder wachtwoord), met [data entry only]. In de interfacefile kun je niks qua ontwerp, tenzij er een script is dat dat mogelijk maakt. Maar je kunt jezelf als gast geen toegang verschaffen tot de layoutmodus of de scripteditor om maar wat te noemen.

- een datafile waar [guest access] disabled is, waar je dus als gast zonder wachtwoord nooit binnenkomt, ook niet met een script.

 

Iemand die aanlogt krijgt dus altijd de usernaem/password dialoog van het databestand voor zich. Daar wordt dus alle security geregeld.

Werkt eigenlijk wel goed, ook met WebDirect. Je hoeft gebruikers maar op 1 plek toe te voegen, namelijk in het databestand. De het interfacebestand kun je zonder enige extra actie vervangen door een nieuwe versie.

 

Maar je moet wel bepaalde achterdeurtjes in de gaten houden:

 

Alleen kan het bestand met script geopend worden zonder inloggen en geeft deze toegang tot de gegevens in de database (zonder aanmelden met paswoord) - niet goed dus

 

Je kunt het zo inrichten dat een normale gebruiker het databestand alleen kan openen vanuit de interfacefile. Dus een openscript dat die check uitvoert.

 

HE

Link naar reactie
  • 0

Hangt af van het stadium waarin mijn oplossing zich bevindt.

 

- ik breng de wijzigingen altijd eerst in de datafile van de klant aan.

- als de datafile klein is, maak ik een backup en haal die over naar mijn eigen omgeving.

- is de datafile groot, dan breng ik de wijzigingen in mijn eigen datafile ook aan, in precies dezelfde volgorde.

 

Dat laatste is een nauwkeurig werkje, omdat je de volgorde waarin je de velden toevoegt heel goed in de gaten moet houden.

 

Gaat het om 1 of 2 velden, dan doe ik het altijd op de tweede manier, en soms haal ik dan een backup terug om zeker te zijn dat de datafiles 100% identiek zijn.

 

Als je een oplossing hebt die 'in productie is' mag je aannemen dat het aantal wijzigingen aan de tabelstructuur (velden, en relaties voor berekeningen) beperkt is. De meeste wijzigingen doe je dan in de interface file. Ik denk: 99,8% van de wijzigingen aan de interface, de overige 0,2% aan de datafile.

 

NB ik heb ook wel een oplossing waar ik de datafile op verschillende plaatsen heb draaaien. Daarvoor heb ik een bestand met scripts die de data overpompen en de keys goed zetten. Werkt als een tierelier, maar wel een ingewikkelde oplossing. En in dat geval: NOOIT een veld een andere naam geven. Maar dat is sowieso 'bad practice'.

 

HE

Link naar reactie
  • 0
- een interfacefile waar normale gebruikers aanloggen als guest (zonder wachtwoord), met [data entry only]. In de interfacefile kun je niks qua ontwerp, tenzij er een script is dat dat mogelijk maakt. Maar je kunt jezelf als gast geen toegang verschaffen tot de layoutmodus of de scripteditor om maar wat te noemen.

- een datafile waar [guest access] disabled is, waar je dus als gast zonder wachtwoord nooit binnenkomt, ook niet met een script.

 

Nog wat lopen testen en dit blijkt het inderdaad te zijn.

 

Een beperking: het gebruik van uitgebreide privilegesets lukt niet meer - maar da's niet zo erg: bij nader inzien lijkt het me geen sterk plan om eindgebruikers daarmee te laten spelen.

 

Je kunt het zo inrichten dat een normale gebruiker het databastand alleen kan openen vanuit de interfacefile. Dus een openscript dat die check uitvoert.

 

Da's ook gelukt. Inderdaad vrij eenvoud te doen.

Link naar reactie
  • 0

Tsja, ik begrijp dat sommige ontwikkelaars het concept van het separation model ver van hun bed vinden, maar het loont de moeite om het eens uit te proberen.

Met name bij grotere projecten (en of een project groot wordt weet je meestal van te voren niet :-) ) zijn de voordelen enorm: eenvoudige updates, aparte interfaces voor verschillende doelgroepen en platforms, noem maar op.

 

Trouwens: een oplossing in FileMaker Go waarbij je deels off-line en deels on-line werkt is in feite niks anders.

 

Er zijn wel een paar zaken waar je op moet letten en ik vind het jammer dat de handleiding noch de Advanced Training manual hier serieuze aandacht aan besteden.

Een paar paragraafjes hier en daar bij het datamodelleren en dan heb je het wel gehad.

Link naar reactie
  • 0

 

Gescheiden interfaces per doelgroep noem je als voordeel. Daar zit wel wat in maar heeft tevens het nadeel dat je meerdere interface bestanden moet onderhouden. En dat terwijl je met behulp van platformparameters, accounts en privilegesets ook prima kunt bepalen welke schermen/data men te zien krijgt in een toepassing met slechts één enkel bestand.

 

Heb je wel gelijk in, moet je ook heel erg selectief in zijn. Voorbeeld: je hebt een desktop interface voor een toepassing die in een LAN draait. Dan is de complexiteit / grootte van eht schema geen probleem omdat de bandbreedte en de CPU resources 'onbeperkt' zijn. Maar als je een heel erg 'lean and mean' bestand hebt voor een iPhone of iPad, dan zitten al die layouts en scripts eerder in de weg. En je hebt in zo'n geval toch al gauw een gescheiden ontwikkeltraject.

 

Maar een veel belangrijker punt is een testversie: je kunt rustig een tweede of derde versie van je interface bestand neerzetten voor een selecte groep gebruikers, om interface en workflow concepten uit te proberen, met de live data of (liever) met een testdatabase. Bevalt het, dan zet je de boel live, zo niet, dan niet. Die flexibiliteit heb je nooit met een 'single-file' solution. Probeer maar eens een versie terug te gaan...

 

Hoe ga je om met berekeningsvelden waarbij de berekening afhangt van velden in andere tabellen? Plaats je de relaties in het databestand of in het interfacebestand? Ik zou kiezen voor het databestand wat wel als nadeel kan hebben dat wanneer je dezelfde relatie ook weer in het interfacebestand nodig hebt, je dubbel werk aan het doen bent.

 

Dat klopt, relaties voor berekeningen maak je in het databestand natuurlijk. En ja, je hebt dan 'dubbele relaties', al is dat schijn: ze dienen een ander doel. De een voor de business logic (hoe de data berekend worden) en de ander voor de presentation logic, hoe de gebruiker met de data werkt.

Er is nog een ander voordeel: het schema van je datafile is veel simpeler (mag ik hopen) en dus loop je ook niet zo gauw tegen context-problemen aan bij een berekening. Er zijn niet zoveel opties (om het fout te doen).

 

 

Makkelijk de interface kunnen updaten is het sterke en meest gehoorde argument. Mijn ervaring is dat ook de data kant nogal eens moet meeveranderen. Ook dat gedeelte is nauwelijks stabiel te noemen. Maar misschien ligt dat aan mijn manier van ontwikkelen of aan mijn type klanten; gaandeweg het gebruik komen nieuwe inzichten, ideeén en wensen naar boven die ook wijzigingen in het datagedeelte noodzakelijk maken.

 

Zeker! Alleen ik maak veel meer en veel ingrijpender aanpassingen aan de interfacefile dan aan de datafile.

 

Om in een niet-gescheiden toepassing te kunnen updaten is een export-import noodzakelijk. Hierbij zitten er wat addertjes onder het gras die echter goed scriptmatig zijn op te lossen. Wanneer je eenmaal zo'n script hebt is deze ook goed te onderhouden en kun je met een simpele druk-op-de-knop de data in een nieuwe versie pompen)

 

Zo'n script heb ik ook en dat werkt ook prima. Waar ik ook tegenaan loop zijn Remote Containers: je kunt een Filemaker bestand op een server wel vervangen, maar haal het niet in je hoofd om op de deleteknop van de console te drukken! Dan zijn al je remote containers ook weg. En ik houd ook niet zo van het overbrengen van honderden Megabytes over een internet verbinding...

 

BTW: ik breng ook niet alles in de datafile onder. Een tabel voor een Virtual List of een kalender enzo dat zit natuurlijk in de interface file. Het criterium is dat ik het zonder nadenken weg moet kunnen gooien/vervangen, dat er dus geen gebruikersgegevens in zitten.

 

Trouwens: als je de data in een 'single file solution' overbrengt naar een nieuwe versie, wat doe je dan met de FMP accounts en hun wachtwoorden?

 

HE

Link naar reactie
  • 0

Ik vind FileMaker een prachtig pakket maar version management is een groot gemis in het platform.

Je kunt dit proberen op te lossen met data interface te scheiden maar daar kleven veel nadelen aan.

 

Enkele problemen die je nog bij scheiden van data en interface ondergaat:

- Caching! (Je krijgt 2 caches de data file heeft niet altijd door dat de cache moet worden vernieuwd dit heb je al bij een singel file maar wordt nog erger met 2 files )

- Alle zaken die per file zijn (variable/taal settings etc)

- Continue moeten schakelen tussen de files

- Complexiteit (zaken doorgeven met scriptparameters en dergelijke)

- Niet dynamisch kunnen instellen van external resources geeft veel problemen

- Perform on server

-

 

Wij gebruiken het wel bijvoorbeeld voor iPad module die dan makkelijk is te vervangen.

Maar eigenlijk moet FileMaker eens een fatsoenlijke version management mogelijkheid bieden. Bijvoorbeeld update file met DDR XML.

 

Groet WJ.

Link naar reactie
  • 0
Ik vind FileMaker een prachtig pakket maar version management is een groot gemis in het platform.

Je kunt dit proberen op te lossen met data interface te scheiden maar daar kleven veel nadelen aan.

Op zich helemaal mee eens, maar dat heeft hier natuurlijk niet zoveel mee te maken, dit is gewoon een algemeen FileMaker probleem! Wat ik bedoel is, je kunt gemakkelijk een testomgeving creëren en daar snel schakelen naar andere versies terwijl de normale gebruikers daar niks van merken.

 

- Caching! (Je krijgt 2 caches de data file heeft niet altijd door dat de cache moet worden vernieuwd dit heb je al bij een singel file maar wordt nog erger met 2 files )

Op zich wel een probleem, ik neem aan dat je de cache bedoelt die FMP op de client aanhoudt? Dat probleem is toch precies hetzelfde, je hebt toch alleen portals e.d. in de interfacefile. Bij PSoS treedt wel een heel vervelend probleem op, maar dat heeft vooral te maken met het gebrekkige refresh mechanisme. Hier moet FileMaker echt iets aan doen.

 

- Complexiteit (zaken doorgeven met scriptparameters en dergelijke)

Dat maakt volgens mij geen enkel verschil. Alle contexts worden bepaald in de interfacefile, en (bijna) alle scripts draaien in de interfacefile.

 

NB ik gebruik in de interfacefile overigens wel (veel!) globale velden voor tijdelijke opslag van Foreign Keys en parameters. Anders werkt het niet en moet je ook heel vaak switchen naar de datafile voor aanpassingen. Dat is dus wel een keuze voor een bepaalde architectuur.

 

- Niet dynamisch kunnen instellen van external resources geeft veel problemen

 

Snap ik niet, wat bedoel je daarmee? Dat kun je toch sowieso niet.

 

- Perform on server

Klopt, ben ik wel achter gekomen, vind ik wel jammer. Moet je inderdaad oplossen met een re-login. En zoals gezegd, de refresh is beneden de maat.

 

Maar eigenlijk moet FileMaker eens een fatsoenlijke version management mogelijkheid bieden. Bijvoorbeeld update file met DDR XML.

Helemaal mee eens, dat zou mooi zijn! En dan ook mijn stokpaardje: FieldID's optioneel in de veldlijstjes displayen. De huidige weergave dateert alweer van FileMaker 3.0. Ik ben wel behoudend, maar dit gaat me toch een beetje ver.

 

HE

Link naar reactie
  • 0

Caching probleem:

Komt erop neer dat de data file niet goed doorheeft wanneer de cache joins moeten worden geleegd.

Je hebt 2 files met 2 file caches. Gewoon gezegd je zult meer refresh flush moeten gebruiken en portalen zullen moeilijker updaten.

 

Complexiteit:

Heel simpel 1 file is een stuk eenvoudiger hoe je het ook went of keert. En dit zeg ik niet omdat we nooit met meerder files werken.

 

Niet dynamisch kunnen instellen van external resources:

Deze heb je niet nodig als je met 1 file werkt.....

 

Wil niet zeggen dat de voordelen van interface en data gescheiden toch kiest en blij mee bent natuurlijk. Iedereen zijn manier van werken. En het makkelijker kunnen updaten vind ik echt een groot voordeel.

 

Helemaal mee eens, dat zou mooi zijn! En dan ook mijn stokpaardje: FieldID's optioneel in de veldlijstjes displayen. De huidige weergave dateert alweer van FileMaker 3.0. Ik ben wel behoudend, maar dit gaat me toch een beetje ver.

Helemaal voor !!!

 

Groet,

 

WJ

Link naar reactie
  • 0

Niet dynamisch kunnen instellen van external resources:

Deze heb je niet nodig als je met 1 file werkt.....

OK, snap ik. Ik denk dat ontwikkelaars die met single-file solutions werken en nooit een ESS koppeling hebben ingesteld de External Reources dialoog niet vaak zullen tegenkomen. Die heb je dan gewoon niet nodig!

 

Overigens: de 'carry-over' van de accountgegevens loopt ook via deze file referenties (d.w.z. dat een gekoppeld bestand zonder dialoog wordt geopend als de credentials hetzelfde zijn). Daarmee komen we ook weer terug bij de oorsponkelijke topic :-)

Link naar reactie
  • 0

Zoveel ontwikkelaars ... zoveel meningen. Ik ontwikkel nu alweer enkele jaren bij nieuwe projecten met data en interface gescheiden en heb veel oude projecten waarbij dat niet werd gedaan en veel van de oude projecten hebben ook nog eens veel bestanden. Deze projecten worden alleen niet alleen door mij bediend, maar ook mijn collega's werken er af en toe en soms regelmatig aan en ik kan het denk ik zelf inmiddels aardig met elkaar vergelijken. Een dataseparatie-model heeft voor- en nadelen, maar die moet je genuanceerd zien, want véél accounts hoeft geen probleem te zijn en véél bestanden ook niet. Ieder heeft daarbij ook zijn smaak misschien wel ontwikkeld.

 

Onze projecten zijn zonder uitzondering in een multi-user-omgeving en waarbij er een beperkt aantal soorten users zijn. De klanten wisselen per dag hun eisen over de privileges die medewerkers in hun systemen hebben en willen dat het liefst zelf kunnen controleren en aanpassen. Als ontwikkelaar wordt van mij verwacht dat ik een zekere data-integriteit afdwing, waarbij een directeur wél bepaalde gegevens mag wijzigen en de ene manager mag dat ook, maar de andere weer niet en een gewone kantoormedewerker mag het alleen maar zien oid. Als je dit gaat proberen op te lossen door de FM-privilege-instellingen uitgebreid toe te passen, dan wordt zoiets al snel niet onderhoudbaar, laat staan overdraagbaar.

 

Ik werk eigenlijk alleen maar met een zeer beperkte set met 3 privilege-sets en 3 accounts: De "admin", de "user", de "kijker", waarbij de user en de kijker veel lijken op [data-entry only] en de [read-only], maar wel eigen privilege-sets zijn. Dat is gemakkelijk te repliceren naar andere bestanden als je meerdere bestanden hebt. Alle bestanden die geen deel uitmaken van de "interface" zijn voor iedereen die geen admin is gewoon "dicht" als dat nodig is en soms moet er wel iets "open" staan voor bijvoorbeeld onderhoud en dat kan je dan gewoon mogelijk maken/toevoegen.

 

Er zijn voor de gebruikers records aangemaakt en daaraan gekoppeld zijn er privilege-records voor ieder losse privilege, adhv die records wordt hun toegang geregeld met enkele standaard scripts, waar alleen maar enkele parameters worden heengestuurd. Dat lijkt complex, maar is peanuts tov privileges in alle bestanden en bij iedere tabel in te moeten stellen, die je dan ook nog eens onderhouden.

 

Over wat nou het voordeel is van separatie kan ik kort zijn: geen conversies meer. Okee soms moet je in de achterliggende model iets toevoegen en daar zijn uiteraard wel een paar aandachtspunten, maar dat komt beslist niet dagelijks voor. Het voordeel dat je een systeem platgooit, de interface uitwisselt en je start alles weer is voor veel bedrijven een positief argument. Tijdens de middagpauze geef je het hele bedrijf een aangepaste interface.

 

Mijn favoriete model is

  • Data (de CRM, ERP gegevens)
  • Constanten (keuzelijsten, gebruikers, privileges, instellingen)
  • Media
  • Koppelbestanden (boekhouding, website, mailing-deamon)
  • Uitvoer (dit zou ook in het inteface-bestand kunnen)
  • Overzichten (kan ook in interface)
  • Interface (eventueel voor iedere soort (i-device, desktop, server) een apart bestand)

Ik zeg niet dat dit eenvoudig is, maar een volledig geïntegreerd systeem is minstens net zo complex. Als je echter de moeite hebt gedaan om een systeem op deze manier op te zetten, dan pluk je daar op termijn beslist de vruchten van. Het argument dat je je data-model op meerdere plekken moet nabouwen is niet helemaal correct. Het grootste deel van je model heb je nodig voor weergave voor de gebruiker om de data te kunnen beoordelen en bewerken. In een data-bestand hoeft alleen het hoogst noodzakelijke te staan zoals een header-regel-relatie om bijvoorbeeld snel de regels bij een offerte te verwijderen, maar doe je daar niet aan dan is zo'n relatie ook niet nodig.

Link naar reactie
  • 0

Leuke discussie inmiddels.

Daar heb je niet veel aan. Je bent dan immers in beide bestanden als admin ingelogd. Waar is je beveiliging dan

Nee, alleen voor ontwikkeling natuurlijk, inloggen met de Optie-toets ingedrukt.

 

@Menno: bedoel je dat je een grote oplossing dus uit 5 tot 7 of meer fysieke bestanden opbouwt? Waarvan 1 primair databestand (met een paar tabellen) en een interface bestand met een heleboel scripts en layouts?

 

Eigenlijk een beetje FileMaker 6 /7 hybride oplossing?

 

Dat je media bijvoorbeeld in een apart fysiek bestand onderbrengt begrijp ik overigens heel goed: het geeft je ook nog eens de mogelijkheid om zo'n bestand op een andere server onder te brengen en ook zijn de opties voor backups en Remote Container velden dan wat groter.

 

Wel een vraag: hoe ziet de External Resources dialoog van al die bestanden er dan uit? Heeft het Mediabestand dan bijvoorbeeld ook een link met het databestand (op de manier zoals FileMaker 6 dat deed)? Of ontwerp je het allemaal zo dat de gegevens in de fysieke bestanden niet van elkaar afhankelijk zijn?

 

In mijn optiek is het namelijk absoluut uit den boze om referenties 'de andere kant' op te maken, dus NOOIT van de datafile naar de interface file. Bij mij is de lijst met External Resources van de datafile dus LEEG (tenzij er een ODBC source is, maar dat is een heel ander verhaal).

Ik zet het in hoofdletters omdat de voordelen van een gescheiden model meteen in rook opgaan als je hiermee gaat rommelen.

 

Zo'n security model met een beperkt aantal privilegesets heb ik ook ontwikkeld, en werkt waarschijnlijk op vergelijkbare wijze:

- gebruiker logt in en krijgt de privilegeset 'user'.

- het loginscript kijkt in een tabel welke privileges daarbij horen, dus in welke tabel iemand records mag bekijken enzovoorts.

- in de privilegeset kijkt FileMaker of een gebruiker een tabel wel of niet mag bekijken/editen en ook is dat op record-niveau te doen.

De beheerder komt dus nooit aan de privilegeset, dat doet alleen de ontwikkelaar (ik).

 

En dan heb ik op vergelijkbare wijze een privilegeset voor web-toegang, zodat webgebruikers alleen hun eigen informatie mogen raadplegen.

Best ingewikkeld, dat wel.

 

HE

aangepast door Gast
Link naar reactie
  • 0

@ HE: Correct, de relaties zijn one-way-only en het is inderdaad een hybryde oplossing. Het doel ervan is dat je alleen maakt wat je voor een specifiek doel nodig hebt. In mijn optiek hebben invoer, uitvoer en rapportage bijvoorbeeld alleen maar de data als gemeenschappelijke factor, maar zouden ze elkaar in de weg zitten en dus heb ik het uit elkaar gelaten.

Link naar reactie
  • 0

Heb je dan ook wel eens gedacht aan de mogelijkheid dat een gebruiker (met een laptop bijv.) de interface file lokaal heeft draaien?

 

Ongeveer zoals je met een FileMaker Go oplossing zou doen die deels stand-alone moet kunnen werken, maar dan helemaal zonder data uiteraard.

 

Het onderhoudsprobleem kun je namelijk tegenwoordig afvangen door de laatste versie van de interfacefile als Binary op te slaan en de gebruiker te laten downloaden wanneer dat nodig is. Ik heb er niet zoveel ervaring mee, maar met een URL zou dit redelijk probleemloos moeten kunnen toch? Net zoals je ook Plugins kunt distribueren, maar dan iets anders.

 

NB misschien zou dit forum een subtopic 'datamodelling' of 'architectuur' ofzo moeten hebben.

Link naar reactie
  • 0

Ben nog steeds van mening dat FileMaker zelf ook geen voorstander is van deze manier van werken en dat het onverstandig is.

Het kunnen leggen van koppelingen met andere bestanden is vanuit backwards comptabiliteit ontstaan. Volgens mij zijn er geen voorbeelden in de FileMaker training series te vinden van data en interface file. Er zijn ook geen voorbeelden van FileMaker starter themas of wat dan ook waarbij deze methode wordt toegepast. De verschillende interfaces zitten in 1 bestand.

 

Het zijn voornamelijk de ontwikkelaars die dit pad zijn gaan bewandelen omdat ze dan makkelijker updates kunnen uitvoeren. De klanten wil snel aanpassingen dan is het wel lekker als je geen data hoeft over te zetten. Je kan ook makkelijk een bug snel oplossen.

En omdat alle andere omgevingen mysql php of wat dan ook de data en logica gescheiden zit. FileMaker onderscheidt zich door dit niet te doen.

Je bouwt als het ware op een bruggetje wat filemaker heeft gemaakt voor compatibiliteit. Een voordeel is dat het tegenwoordig door zoveel ontwikkelaars wordt gedaan dat FileMaker wel betere ondersteuning hiervoor moet gaan aanbieden.

 

Onze favoriete werkwijze

- 1 bestand met alles erin. (ancher en buoy methode, eventueel bij een zeer grote hoeveelheid in 1 tabel deze splitsen.)

- Extra bestanden voor 'bijzondere koppelingen' (customphp/output die de gebruiker zelf moet kunnen aanpassen)

- Extra bestand voor iPad wat op de ipad lokaal draait zodat de snelheid optimaal is. (merk wel dat 4g en nieuwe ipads dit eigenlijk overbodig maken :-)

- 1 update bestand wat data van de oude versie in de nieuwe live inlaad.

 

Trouwens wat ook een argument is is dat alles steeds meer naar de cloud gaat en de server maar 125 files aankan. Doordat wij Azor op 1 file hebben gebouwd kunnen we heel wat klanten kwijt op 1 server.

 

Groet

 

WJ

Link naar reactie
  • 0
Ben nog steeds van mening dat FileMaker zelf ook geen voorstander is van deze manier van werken en dat het onverstandig is.

Het kunnen leggen van koppelingen met andere bestanden is vanuit backwards comptabiliteit ontstaan.

Hmm, dat geloof ik toch niet.

 

In de eerste plaats is FileMaker 7 e.v. helemaal niet backwards compatible. Je kunt alleen een bestand converteren van het oude formaat naar het nieuwe formaat, niet terug. Je kunt zelfs geen export naar een ouder formaat maken. FMI had er ook voor kunnen kiezen om alle tabellen van een FP5 oplossing in één fysieke 'wrapper' te trekken, maar dat hebben ze niet gedaan en met reden.

 

In de tweede plaats zijn de External Resources natuurlijk meer dan alleen een conversie van de oude koppelingen van FileMaker6. Dat is een logisch gevolg van de aanpak die FMI gevolgd heeft. Als FileMaker een 'single-file solution' had willen promoten (lees: afdwingen), hadden ze gewoon de external resources kunnen beperken tot ODBC bronnen. Er zal destijds heel wat discussie hierover geweest zijn bij FileMaker.

 

(wie nog een oude FM6 oplossing heeft moet die voor de grap eens converteren met FileMaker 11 en dan de External Resources openen. Je ziet dan de verwijzingen naar oude servers en harddisks staan waar de FM6 oplossing ooit op heeft gedraaid).

 

Volgens mij zijn er geen voorbeelden in de FileMaker training series te vinden van data en interface file. Er zijn ook geen voorbeelden van FileMaker starter themas of wat dan ook waarbij deze methode wordt toegepast. De verschillende interfaces zitten in 1 bestand.

 

Dat klopt, maar daar zijn wel redenen voor. In de eerste plaats is een 'gescheiden oplossing' voor simpele startersoplossingen niet echt iets om een beginnende gebruiker mee over de streep te trekken. En de training series is eveneens erg oplossingsgericht en ook daar geldt: welk probleem los je ermee op? Niet het soort problemen dat in de training series ter sprake komt. Het is gewoon te abstract.

Wat betreft die Starter oplossingen: wil iedereen die die dingen echt gebruikt even zijn vinger opsteken?

 

Ik heb een interessant White Paper uit 2004 (!) waarin de concepten van TOC's en bi-directionele relaties mooi wordt uitgediept, en waarin beschreven wordt hoe FileMaker in één klap een moderne architectuur kreeg.

 

NB het anchor-buoy model is nuttig en belangrijk, maar het is niet meer dan een 'best practice' om een datamodel te bouwen.

Trouwens wat ook een argument is is dat alles steeds meer naar de cloud gaat en de server maar 125 files aankan. Doordat wij Azor op 1 file hebben gebouwd kunnen we heel wat klanten kwijt op 1 server.

 

Ja, maar je gaat toch geen 125 klanten op één server bedienen. Welke server kan dat aan?

Overigens: waarom FMS maar 125 bestanden kan hosten is me een raadsel. Het aantal gelijktijdige gebruikers is onbeperkt en de server is toch 64 bits.

Ik zou me kunnen voorstellen dat je 'maar' 125 bestanden tegelijk kunt benaderen.

 

@Felix: ja, zoiets zou je wel willen, je zou het separation model ook door kunnen trekken en de scripts in een apart bestand onderbrengen. FIleMaker heeft dat (nog) niet gedaan, omdat de structuur heel nauw in elkaar grijpt met ID's.

 

HE

Link naar reactie

Doe mee aan dit gesprek

Je kunt dit nu plaatsen en later registreren. Indien je reeds een account hebt, log dan nu in om het bericht te plaatsen met je account.

Gast
Beantwoord deze vraag...

×   Geplakt als verrijkte tekst.   Plak in plaats daarvan als platte tekst

  Er zijn maximaal 75 emoji toegestaan.

×   Je link werd automatisch ingevoegd.   Tonen als normale link

×   Je vorige inhoud werd hersteld.   Leeg de tekstverwerker

×   Je kunt afbeeldingen niet direct plakken. Upload of voeg afbeeldingen vanaf een URL in

×
×
  • Nieuwe aanmaken...