[alg] Settings opslaan in webomgeving

[Verwijderd]

Hallo

ik ben al een aantal keren tegen het zelfde "probleem" aangelopen.
Vaak moet/wil ik settings opslaan, die tussen door ingesteld of gewijzigd moeten worden. Of door mij of door de gebruiker.

Onder settings versta ik bijvoorbeeld:
- Een email adres waar het mailform heen mailt
- FTP gegevens, om webbased een ftp uit te lezen (vraag niet waarom )

Nu heb ik een aantal ideeen daar over en een paar daarvan gebruik ik nu ook.

Manieren die ik tot nu toe heb gebruikt:
Een php bestand: dit schrijf ik elke keer opnieuw, net als phpmyadmin dacht ik. Ik schrijf dan in het bestand weg iets van $config["setting_name"] = "value";
Ik vind dit opzicht redelijk werken. Ik schrijf het weg met de extensie php, dus het is ook niet van buiten af te lezen. Het enige nadeel is dat je schrijf rechten nodig hebt.

Een xml bestand: bij veel gegevens, die in variabele toestand voor kunnen komen gebruik ik dit. Ik vind het wel nogal wat overhead hebben, maar hier valt mee te leven/werken. Een nadeel vind ik dat je het xml-bestand moet beveiligen om het niet te laten downloaden, als er bepaalde gegevens in staan en hiervoor moet je ook schrijfrechten toe kennen.

Een database: dit vind ik zelf de minste oplossing. Ik gebruik het alleen als toch al gegevens uit de database moet halen voor een bepaald iets en dan kan er wel 1 of 2 settings bij worden opgeslagen. Maar als ze "los" opgeslagen moeten worden is het niet echt handig.

Maar ik wil graag weten hoe jullie met dit "probleem" omgaan en oplossen.

[Erkens]

Instellingen sla ik meestal op in een php file (als het PHP betreft natuurlijk) die ik, indien mogelijk, buiten de webroot zet.
Wat ik overigens wel bijna altijd doe is constanten (define) gebruiken hiervoor, dat werkt gewoon het makkelijkst.
En waarom moet je schrijfrechten hebben op die file? Vaak zijn dat dingen die bijna nooit veranderen

[Gomez12]

idd, gewoon een config file gebruiken voor de vaste instellingen ( base dir / servername / mysql server etc etc. ) ik blokkeer al mijn scripts trouwens als de config file writeable is. Want ik ben van het principe : je edit hem maar met een teksteditor en je upload hem maar via ftp. Eenmalige handeling die best handmatig mag gebeuren.

Enkel de algemene settings die nog wel eens kunnen veranderen die gooi ik wel in een dbase gewoon omdat ik alle veranderbare settings ( gebruiker of global of groep ) via een standaard set functies ophaal en wegschrijf dus om niet van mijn eigen standaard af te wijken ga ik voor dbase instellingen alhoewel flat-file waarschijnlijk sneller zou zijn voor global settings vind ik de snelheidswinst verwaarloosbaar tov de onderhoudbaarheidswinst.

[Swaptor]

Verwijderd schreef op donderdag 06 oktober 2005 @ 22:34:
Vaak moet/wil ik settings opslaan, die tussen door ingesteld of gewijzigd moeten worden. Of door mij of door de gebruiker.

Bedoelt TS dynamische variabelen die tijdens een sessie gebruikt worden (mag hopen van niet) of config-vars voor de betreffende app die voor iedereen hetzelfde zijn?
Bij het eerste is een .php die je dynamisch aanpast *heel* erg smerig, bij de tweede zou dit een goede oplossing zijn.

(ik dacht deze onduidelijkheid iig op te maken uit je opmerking over schrijfrechten)

[Verwijderd]

Verwijderd schreef op donderdag 06 oktober 2005 @ 22:34:
Hallo

ik ben al een aantal keren tegen het zelfde "probleem" aangelopen.
Vaak moet/wil ik settings opslaan, die tussen door ingesteld of gewijzigd moeten worden. Of door mij of door de gebruiker.

Onder settings versta ik bijvoorbeeld:
- Een email adres waar het mailform heen mailt
- FTP gegevens, om webbased een ftp uit te lezen (vraag niet waarom )

Zulk soort data zet je bijna per default in je web.xml file. Hiervoor gebruikt je dan de <context-param> tag waarmee je eenvoudig een key & value kunt zetten. Deze kun je overal in je applicatie uitlezen waar je over een ServletContext beschikt via de simpele functie getInitParameter();

Dit is -de- standaard manier die eigenlijk iedereen gebruikt voor precies dit soort data. Zelf een source file gaan genereren, die dan weg schrijven en laten includen in weer een andere file kan natuurlijk wel, maar kwa style is dit toch wel bijzonder lelijk.

Iets geavanceerder kun je het doen door in web.xml de <listener> tag te gebruiken en dan een class op te geven die de ServletContextListener implementeerd. Deze class zal aangeroepen worden als je je web applicatie opstart. Via een static function en een static field zou je alle init parameters die je via <context-param> zette, naar een static Hashmap oid kunnen copieren. Op deze manier kun je echt overal in je code erbij (hoef je nog niet eens de ServletContext te hebben), en kun je eventueel op een lopende applicatie de waarden veranderen; hetzij door web.xml te veranderen (de context listeren pakt deze op) op door een web-based interface'je te bouwen met code die schrijft in de Hashmap van je listener class.

[T-MOB]

Het ligt er een beetje aan wat je bedoelt. Voor algemene instellingen van het script wat draait (database connectie etc.) gebruik ik een config file. Hierin gebruik ik net als Erkens constanten. De voordelen zijn dat alle instellingen bij elkaar staan, met een simpele texteditor te wijzigen zijn, een veelzeggende naam kunnen kijgen en nooit overhoop liggen met variabelnamen.
Waar het gaat om instellingen die gebruikers kunnen wijzigen gaat de voorkeur uit naar een database. De reden hiervoor is de schaalbaarheid, zelfs met 100.000+ gebruikers met verschillende instellingen werkt dit performant. De instellingen worden dan bij voorkeur in een duidelijk herkenbaar array geladen ($_USER ofzo).

Het nut van XML in deze context zie ik niet helemaal. Bij mijn beste weten is XML een standaard om gegevens tussen applicaties uit te wisselen. Wanneer je het gebruikt om constanten in je applicatie vast te stellen dan kun je beter direct de PHP syntax gebruiken (dat scheelt overhead). Gebruik je het omdat er relaties tussen bepaalde gegevens bestaat dan is een database een beter plan (schaalbaarheid en wss ook performance).

[Verwijderd]

T-MOB schreef op vrijdag 07 oktober 2005 @ 01:12:
Het nut van XML in deze context zie ik niet helemaal.

Beetje onzin om het zo te stellen. web.xml heb je toch gewoon al? Je kunt daar gewoon je constantes bijzetten?

Het voordeel van een dergelijke aanpak is dat elke developper weet dat de constantes van een web.applicatie in web.xml staan en daar dus het eerste zal gaan zoeken. Een voordeel boven de DB gebruiken is dat je constantes onderdeel zijn van je applicatie en via web.xml ook met je versie controlle systeem (bv CVS, subversion, VSS, etc) meegenomen wordt.

Include files gaan genereren lijkt me een beetje onzinnig! Namelijk: includes doe je in de VIEW layer. Dikwijls zijn het constantes die HELEMAAL NIKS met de view te maken hebben, maar business logic betreffen of om operationele zaken handelen (bv URL van de DB).

Deze wil je zeker niet je applicatie via de view layer binnen loodsen. Dat is vragen om onderhouds problemen, en je introduceerd mogelijkheden voor name clashes die absoluut niet hoeven!

[Erkens]

Verwijderd schreef op vrijdag 07 oktober 2005 @ 10:39:
Beetje onzin om het zo te stellen. web.xml heb je toch gewoon al? Je kunt daar gewoon je constantes bijzetten?

Niet elke webapplicatie omgeving heeft/gebruikt web.xml

Include files gaan genereren lijkt me een beetje onzinnig! Namelijk: includes doe je in de VIEW layer. Dikwijls zijn het constantes die HELEMAAL NIKS met de view te maken hebben, maar business logic betreffen of om operationele zaken handelen (bv URL van de DB).

Includes doe je juist in de logica om delen code te scheiden van elkaar.

Deze wil je zeker niet je applicatie via de view layer binnen loodsen. Dat is vragen om onderhouds problemen, en je introduceerd mogelijkheden voor name clashes die absoluut niet hoeven!

[Creepy]

Verwijderd schreef op vrijdag 07 oktober 2005 @ 01:02:
[...]

Er zijn ook mensen die web apps niet in Java schrijven
PHP bijv. heeft geen standaard manier om settings op te slaan voor een zelf geschreven webapp. Dit zul je dus zelf moeten doen. Er zijn wel frameworks die dit voor je kunnen afhandelen maar die worden vaak niet gebruikt.

bojo: Include files gaan genereren lijkt me een beetje onzinning. Een simpele php, ini of xml achtige file voldoet hier prima voor. Die schrijfrechten heb je toch nodig om uberhaupt wat op te kunnen slaan.

[Verwijderd]

Toch leuk om te zien dat er verschillend gedacht wordt.

Een aantal punten waar ik zo ook nog aan denk:

Bij het includes van een file met variabele erin kan het grandioos mis gaan. Als er een variabele verkeerd wordt weggeschreven (of zelfs een of andere hack bevat). Draait de hele appliactie in de soep, ipv een melding van dat de xml-file niet klopt.

Het punt waar ik ook nog mee zit is dat het veranderen van de settings vollidig op gebruikers-niveua ligt. Het wordt door de webapplicatie zelf weg geschreven en opgehaald. Het gaat dus niet direct om éénmalige settings, ze kunnen door de gebruiker veranderd worden, wat waarschijnlijk maar één keer gebeurt.

Een XML-file, buiten de web-root, lijkt me toch de meest "veilige" en flexibele oplossing. Zo zijn meerdere setting files in bestaande applicaties gemaakt.

[SPee]

Het ligt eraan voor welke oplossing je zou kunnen kiezen.
Het hangt ervan af welke technologie je gebruikt.

Java: web.xml of andere descriptors, propertie bestanden in je systeem of database
PHP: database, php bestand of lokaal bestand (text/xml)
Perl: lokaal bestand
.Net: Gerelateerd aan java

Volgens mij werkt de TS met gewone HTML of PHP.
Als je plain bestanden gebruikt, is het veiligst om ze buiten je web root te zetten (als dat kan). Met security is de kans groter dat het fout gaat. (Stel iemand upload een nieuwe versie en vergeet de rechten goed te zetten)

[Verwijderd]

Creepy schreef op vrijdag 07 oktober 2005 @ 11:04:
[...]
Er zijn ook mensen die web apps niet in Java schrijven

Dat is natuurlijk waar ja, sorry (oh, was tegen henk gericht, maar ik zei het zelfde dus ) Beter was geweest als ik geschreven had web.xml of vergelijkbare configuratie file. Heeft PHP dat echt niet? ASP.NET heeft wel iets vergelijkbaars als ik me niet vergis.

Een andere optie is idd de config file. Ik gebruik deze zelf om code mee te configureren die ook standalone (niet in een webomgeving) moet kunnen draaien. Het makkelijkste zijn dan de .properties files. Je hebt daarvoor een standaard class die Properties heet en daarmee laad je zo een file in.

Java:

Properties props = new Properties();
FileInputStream in = new FileInputStream("constants.props");
props.load(in);

Properies kun je dan benaderen zoals een hashmap. Werkt erg makkelijk. PHP en ASP.NET en eventueel andere webomgevingen zullen wel iets vergelijkbaars hebben denk ik.

[ Voor 6% gewijzigd door Verwijderd op 07-10-2005 11:32 ]

[mulder]

Horen settings die niet readonly zijn niet gewoon in je database?

[Creepy]

Don Facundo schreef op vrijdag 07 oktober 2005 @ 12:13:
Horen settings die niet readonly zijn niet gewoon in je database?

Kan natuurlijk ook, maar ook de database naam, login en password willen ook nog wel eens instelbaar zijn. Dus je zult iets van een config file moeten hebben wat makkelijk is aan te passen.

[Janoz]

Verwijderd schreef op vrijdag 07 oktober 2005 @ 11:20:
Beter was geweest als ik geschreven had web.xml of vergelijkbare configuratie file. Heeft PHP dat echt niet? ASP.NET heeft wel iets vergelijkbaars als ik me niet vergis.

php heeft niet eens een applicatie scope. Enkel een page en een sessie scope. Er is vanuit de taal dus niet eens een mogelijkheid om vergelijkbare functionaliteit aan te bieden.

Daarnaast zijn php en asp.net sowieso niet vergelijkbaar. asp.net komt dichter bij java in de buurt.

[mulder]

Creepy schreef op vrijdag 07 oktober 2005 @ 12:36:
[...]
Kan natuurlijk ook, maar ook de database naam, login en password willen ook nog wel eens instelbaar zijn. Dus je zult iets van een config file moeten hebben wat makkelijk is aan te passen.

Dat zijn dan ook settings die je (ok.. meestal) niet wilt wegschrijven uit je webapp. Maar de meeste settings horen eigenlijk in de database imho.

[Erkens]

Don Facundo schreef op vrijdag 07 oktober 2005 @ 12:57:
Dat zijn dan ook settings die je (ok.. meestal) niet wilt wegschrijven uit je webapp. Maar de meeste settings horen eigenlijk in de database imho.

Ik zie niet in waarom ik (bijna) alle settings in de database moet duwen? Als deze toch bijna nooit veranderen?

[mulder]

Waarom dan nog settings? Dat zijn jou eerder genoemde constanten. Settings zijn zaken die je wilt instellen, waarom die op een andere manier opslaan?

[T-MOB]

Don Facundo schreef op vrijdag 07 oktober 2005 @ 13:09:
Waarom dan nog settings? Dat zijn jou eerder genoemde constanten. Settings zijn zaken die je wilt instellen, waarom die op een andere manier opslaan?

Jullie zijn het eens hoor, behalve over de definitie van een "setting". In de visie van Erkens (en in die van mij eigenlijk ook) zijn wat jij hier aanhaalt als constanten ook settings. Het zijn zaken die je - ook al is het maar 1 keer - wil instellen.

[mulder]

I know, probeerde beetje discussie uit te lokken, ik heb het idee dat er te veel zooi in settingsbestanden word gegooid (including by me) ipv in de database.

[Erkens]

Wat voor 'zooi' bedoel je dan?

[mulder]

Bijvoorbeeld email. Dit wil je volgens mij kunnen instellen in je app. Zeker als je applicatie meerdere klanten ondersteund.

[Erkens]

Volgens mij volg ik jou niet helemaal

Als ik een applicatie heb die meerdere klanten ondersteund dan heb ik in de directory structuur aparte gedeelte staan voor de applicatie (en de bijbehorende files) en een gedeelte specifiek per klant. In alle bij heb ik dan ook een config file waarbij de file van de klant de "defaults" van de applicatie (config) overschrijft.
Ik vind het nog steeds onzinnig om bijvoorbeeld een e-mail adres van een klant als setting in de database te zetten als deze nooit veranderd. (Ik neem aan dat je het reply-to adres bedoeld bij het verzenden van een mailtje)

[mulder]

Nou volgens mij stelt de klant zelf dat email-adres in, maar laat maar, dit word een heel andere discussie

[Verwijderd]

Over settings en configuratie, al mijn applicaties en websites bevatten (omdat we met een template-systeem werken is dit altijd hetzelfde) een configuratiefile met een .php extensie. Deze bevat niets anders dan veel definities (constanten) van variabele waarden, globale functies en soms wat classes die buiten het templatesysteem om werken.

Niets mis mee, en zoals iemand anders goed opmerkt: indien je settings wilt wijzigen lekker lokaal doen en het bestandje dan met je FTP-prog het wereldwijde web opsturen. Veiligheid voorop, toch?

[edeboeck]

Ik heb de indruk dat er hier wat naast elkaar gediscussieerd wordt (al is dit maar een indruk natuurlijk ) ... deels veroorzaakt door een stuk onduidelijkheid in TS.

Als de settings per gebruiker worden opgeslagen, lijkt gebruik van DB me de enige écht goeie oplossing (schaalbaarheid, onderhoud).

Als de settings op applicatie-niveau worden opgeslagen, lijkt het gebruik van afgeschermde files me de beste mogelijkheid.

PS: let op de "lijkt me"

[Erkens]

Don Facundo schreef op vrijdag 07 oktober 2005 @ 14:25:
Nou volgens mij stelt de klant zelf dat email-adres in, maar laat maar, dit word een heel andere discussie

Ja, maar daarna is het gewoon een readonly adres, iets wat nooit veranderd, beetje onzinnig om dergelijke settings in een database te zetten. Zelf een file inlezen is bijna altijd sneller dan het door de sql molen heen te gooien.
Ook het veranderen is makkelijker met een losse file, hoef je geen SQL query's te bedenken als het toch een keertje veranderd moet worden.

edeboeck schreef op vrijdag 07 oktober 2005 @ 14:36:
Ik heb de indruk dat er hier wat naast elkaar gediscussieerd wordt (al is dit maar een indruk natuurlijk ) ...

ik denk het ook

Als de settings per gebruiker worden opgeslagen, lijkt gebruik van DB me de enige écht goeie oplossing (schaalbaarheid, onderhoud).

Wie bedoel je met een gebruiker?

Als de settings op applicatie-niveau worden opgeslagen, lijkt het gebruik van afgeschermde files me de beste mogelijkheid.

Je hebt ook nog verschil in settings op applicatie niveau, namelijk algemene settings en settings per gebruiker (lees: klant)

[ Voor 38% gewijzigd door Erkens op 07-10-2005 14:44 ]

[Janoz]

Dat ligt er vervolgens weer aan hoe je je applicatie inzet. Zet je per klant een apparte applicatie neer of gebruik je 1 applicatie voor alle klanten.

Ikzelf gebruik gewoon propertie bestanden. Ik sla ze iig niet op in de web.xml omdat deze al zo vol is. Bijkomend voordeel is dat ik in mijn buildscript keurig aan kan geven welke properties er gebruikt moeten worden. Hierdoor kan ik een onderscheid maken tussen de test omgeving en de productie omgeving.

Instellingen aanpassen gebeurt eigenlijk altijd vanuit het versie beheer en nooit online. Ikzelf hou de fylosofie aan dat hetgeen op productie staat altijd compleet weggegooid kan worden zonder problemen. De versie uit het versiebeheer (cvs) is altijd lijdend.

Stel je hebt een HD crash van de server, of die server geeft de pijp aan maarten, dan kun je binnen notime een nieuwe server plaatsen en hierop alle applicaties deployen. Backup van de database terug zetten en de boel kan weer online. Downtime tot een minimum beperkt en SLA scores zijn eventueel nog te halen.

[CubicQ]

Een andere mogelijkheid is nog om een naming of een directory service te gebruiken voor de settings. Bij Java kan je met behulp van JNDI die settings vanuit je applicatie server waarin je de settings in definieert inlezen. Bij .NET is het vast en zeker ook wel mogelijk om de settings vanuit AD in te lezen.

Wij gebruiken eigenlijk ook altijd property bestanden. Maar bij externe projecten heb ik ook wel dit soort settings mbt JNDI uitgelezen en ben ik ook wel de web.xml manier tegengekomen.

[Annie]

Erkens schreef op vrijdag 07 oktober 2005 @ 14:42:
Ja, maar daarna is het gewoon een readonly adres, iets wat nooit veranderd, beetje onzinnig om dergelijke settings in een database te zetten. Zelf een file inlezen is bijna altijd sneller dan het door de sql molen heen te gooien.

Ik geloof niet echt dat je die snelheidswinst gaat merken in een gemiddelde applicatie.
En waarom zou data die toch nooit meer wijzigt ineens niet meer in een database mogen? Ik volg je redenatie niet helemaal.

Ook het veranderen is makkelijker met een losse file, hoef je geen SQL query's te bedenken als het toch een keertje veranderd moet worden.

Define 'makkelijker'. Als je niet de beschikking hebt over een taal-eigen manier om configuratiebestanden in te lezen, dan moet je toch ook aan de slag met de filesystem functies en/of xml-parsers? En om configsettings uit de database te halen, heb je zo een simpele class gebouwd. Hoef je nooit meer met sql aan de gang.


Anyway, als je settings hebt die vanuit de applicatie moeten kunnen worden gewijzigd, dan gaat - wat mij betreft - de discussie alleen over de daadwerkelijke plek van opslag. En laat die discussie nu gewoon lood om oud ijzer zijn. Elke opslag methode heeft dan zo zijn voor- en nadelen.
Kies gewoon de oplossing die het best 'past' bij je applicatie en waar je je zelf lekker bij voelt. Lekker belangrijk allemaal

Overigens zou ik in 9 van de 10 gevallen bij een multi-user omgeving (personalisatie) kiezen voor settings in de database. Om telkens tekstbestandjes op naam van de gebruiker weg te schrijven is voor mij te veel hassle.

[Erkens]

Annie schreef op vrijdag 07 oktober 2005 @ 15:11:
Ik geloof niet echt dat je die snelheidswinst gaat merken in een gemiddelde applicatie.
En waarom zou data die toch nooit meer wijzigt ineens niet meer in een database mogen? Ik volg je redenatie niet helemaal.

Wat is het nut om die in een database te hebben? Dergelijke settings wil je bijvoorbeeld ook hebben om een foutmelding te kunnen genereren op het moment dat je database server het nodig vind om dood te gaan. (sowieso moet je ergens je database authentication tokens kwijt, waar? )

Define 'makkelijker'. Als je niet de beschikking hebt over een taal-eigen manier om configuratiebestanden in te lezen, dan moet je toch ook aan de slag met de filesystem functies en/of xml-parsers? En om configsettings uit de database te halen, heb je zo een simpele class gebouwd. Hoef je nooit meer met sql aan de gang.

Het gaat me niet om het uitlezen, maar om het incidenteel veranderen van een setting

Anyway, als je settings hebt die vanuit de applicatie moeten kunnen worden gewijzigd, dan gaat - wat mij betreft - de discussie alleen over de daadwerkelijke plek van opslag. En laat die discussie nu gewoon lood om oud ijzer zijn. Elke opslag methode heeft dan zo zijn voor- en nadelen.
Kies gewoon de oplossing die het best 'past' bij je applicatie en waar je je zelf lekker bij voelt. Lekker belangrijk allemaal

Het ging er toch om waar je "het beste" je settings kon achterlaten

Overigens zou ik in 9 van de 10 gevallen bij een multi-user omgeving (personalisatie) kiezen voor settings in de database. Om telkens tekstbestandjes op naam van de gebruiker weg te schrijven is voor mij te veel hassle.

Dat is wat anders, nu heb je het over de vele gebruikers van de webapplicatie, dan is het idd nuttig om dit in de database te zetten, bij alle andere userinformation

[The Eagle]

Ik werk zelf met PeopleSoft, en daar zie je dit ook heel sterk terug. Wat heeft men gedaan: gewoon een (aantal) extra tabellen in de DB opgenomen, waar generieke settings en user-specifieke settings worden opgeslagen. Wanneer er iets dergelijks gedaan moet worden als de TS aangeeft, wordt simpelweg de query die de standaard gegevens ophaalt uit de DB, gejoined met de user-settings view / table. Voeg daarbij toe een security-view en je komt al een heel eind.
Kwestie van je SQL goed programmeren

[Janoz]

Nadeel van die settings in de DB is (naast dat je pas bij de settings kunt wanneer je daadwerkelijk een db verbinding hebt) dat je niet simpel even kunt kijken wat de settings zijn. Natuurlijk kun je wel je database manager opstarten en een complete query loslaten, maar dat kost wel even tijd (vaak heb je ook te maken met tabellen met id's erin die gejoined moeten worden met een andere tabel voordat het human readable is). Vaak is het makkelijker om even een bestandje te catten (eventueel met grep)/ in notepad te slepen om te zien wat een specifieke setting is.

[edeboeck]

Janoz schreef op vrijdag 07 oktober 2005 @ 15:40:
Nadeel van die settings in de DB is (naast dat je pas bij de settings kunt wanneer je daadwerkelijk een db verbinding hebt) dat je niet simpel even kunt kijken wat de settings zijn. Natuurlijk kun je wel je database manager opstarten en een complete query loslaten, maar dat kost wel even tijd (vaak heb je ook te maken met tabellen met id's erin die gejoined moeten worden met een andere tabel voordat het human readable is). Vaak is het makkelijker om even een bestandje te catten (eventueel met grep)/ in notepad te slepen om te zien wat een specifieke setting is.

Daarin heb je wel gelijk, maar dit lijkt me niet de goede redenering om op basis daarvan te kiezen voor bestanden.

Als ik TS goed heb begrepen zijn er 2 soorten instellingen:
* (1) door gebruiker: de bezoeker van de site kan een aantal instellingen voor zichzelf doen
* (2) door admin: TS past zelf een aantal zaken aan

(1): Hiervoor lijkt me de enige goede oplossing het gebruik van een DB. Je kan bv een aparte settings-tabel maken met daarin een veld voor gebruikers-id en per setting een apart veld (als alle settings op voorhand vastliggen). Liggen de settings niet op voorhand vast lijkt de combo gebruikers-id met name/value pair me het meest logisch.
vb:

code:

UserID | Setting | Value
-------|---------|-----------------
a@b.c  | login   | <loginname>
a@b.c  | pwd     | <password>
k@l.m  | login   | <loginname>
a@b.c  | ftp     | <ftp-url>
k@l.m  | pwd     | <password>

... etc ...

(2) hiervoor kan je idd een bestandje gebruiken, hoewel je aan de andere kant kan redeneren: "heb nu toch al een db, dus waarom niet erbij" ... in dat geval blijft natuurlijk wel het feit dat je naam/login/pwd van je db nog steeds ergens in een bestand moet opslaan ... kan je er ook de rest bij zetten


Voor het handig bekijken/editten van de settings als admin, hoef je dan maar ff een afgeschermde pagina te schrijven dat alle settings toont en aanpast indien gewenst. Niet zo moeilijk lijkt me ...

just my 2 cents

offtopic:
edeboeck zijn frank valt dat hij mss beïnvloed is door een vorig leven waarin DBs een heel grote rol speelden DBA=De Betere Alien?

[ Voor 2% gewijzigd door edeboeck op 10-10-2005 10:58 . Reden: typo ]

[Janoz]

Dat soort settings is meer het gebruik van de applicatie. Aangezien ze onderdeel zijn van het functioneel ontwerp van de applicatie horen die ook in de applicatie. Ik heb het meer over andere settings. Dingen als:
Log level
Database verbinding
Locaties van bepaalde bestanden
Mailserver gegevens

Dit zijn meer dingen die niet direct bij de functionele specificaties van de applicatie horen, maar meer bij de functionele eisen die aan de omgeving waarin de applicatie draait worden gesteld. Een voordeel van het werken met een bestandje is dat heel makkelijk een onderscheid kan worden gemaakt tussen een test deploy en een productie deploy (gewoon een ander bestandje).

[Hydra]

Annie schreef op vrijdag 07 oktober 2005 @ 15:11:
Ik geloof niet echt dat je die snelheidswinst gaat merken in een gemiddelde applicatie.
En waarom zou data die toch nooit meer wijzigt ineens niet meer in een database mogen? Ik volg je redenatie niet helemaal.

Inderdaad. Toen ik nog in PHP werkte had ik een config.php met alleen een paar regels daarin, hostname, poort, dbnaam en user/passwords voor de DB. De rest van de settings staan allemaal in de DB, ook omdat ik dat gewoon handiger vindt, en dan makkelijk een generieke settings editor kan maken.