[PHP|MySQL] echo function() ...

[g4wx3]

Haaj haaj, ik heb een nieuw programmeer vraagstukje..

Vanaf heden wil ik mijn php functies in MySQL opslaan/beheren, uiteraard blijven de functies nodig om een connectie te maken in blijft mijn php script.
Maar hoe kan ik de andere functies vanuit de database terug in het script oproepen? (includen)

Ik heb ondekt dat ik een nieuw bestand kan maken en ze daar allemaal in te outputten, en dat bestand dan includen. Dat werkt maar dat vind ik niet zo efficiënt.

in de database kan ik mijn functies veel makkelijker kan beheren, doorzoeken ed. Nadeel is dat ik ze niet kan gebruiken

[ Voor 13% gewijzigd door g4wx3 op 01-02-2008 00:44 . Reden: leesbaarheid ]

[g4wx3]

HEBBES !!
eval( $script );

En als je het eenmaal weet is het simpel he :d
Superblij, nu ga ik er pas op los kunnen scripten zonder chaos

dankzij about.com weeral
http://php.about.com/od/phpfunctions/g/eval_php.htm

[krvabo]

Results 1 - 30 of about 550 for "eval is evil".

Leesvoer:
http://blogs.msdn.com/eri...ive/2003/11/01/53329.aspx
http://blogs.msdn.com/eri...ive/2003/11/04/53335.aspx

[rogierslag]

Een prachtquote van een goede PHP-ontwikkelaar

You're asking the wrong question if eval() is the answer

Lees de php.net comments over de veiligheid en snelheid van eval eens http://nl2.php.net/eval

[Johnny]

Na Microsoft in januari de prijs van het slechte idee per maand had gewonnen met hun meta-tag maak jij een gode kans om in februari te winnen.

Databases zijn voor data. Code is geen data. Als je functies wil sorteren moet je ze gewoone en logische naam geven, voorzien van commentaar, in een apart bestand steken, je kan ze zelf in klassen zetten als je dat leuk vindt.

In een database horen ze echt niet thuis, en ik zie ook niet in hoe het ooit overzichtelijk kan zijn als je code verspreid hebt in bestanden en in allerlei rijen in een database.

[f.v.b]

Hmm, interessante opmerking. Volgens mij is een harde schijf eigenlijk een heel erg domme database. Microsoft en Apple zijn druk bezig om er een steeds slimmere database van te maken zodat je met een zoekopdracht snel de relevante bestanden gevonden krijgt.

Er zijn redenen te bedenken waarom je ook je code in een database zou willen zetten. Het maken van een backup en het terugzetten ervan wordt een stuk eenvoudiger. Ook versioning en staging gaan denk ik eenvoudiger als alles in een database staat.

Toegegeven, de echte kracht van een database zul je niet gebruiken als je er je code inzet. Maar om het nu meteen een 'slecht idee' te noemen zonder aan te geven waarom. Of het er onoverzichtelijk op wordt, ligt helemaal aan jezelf.

Het enige nadeel dat ik kan bedenken is dat je niet meer met elke tekstverwerker de bestanden kunt bewerken. Maar als je dat probleem hebt opgelost dan is er volgens mij weinig op tegen.

[RobIII]

Waar hoort mijn topic?
WEB >> PRG

[AtleX]

f.v.b schreef op vrijdag 01 februari 2008 @ 11:07:
Hmm, interessante opmerking. Volgens mij is een harde schijf eigenlijk een heel erg domme database. Microsoft en Apple zijn druk bezig om er een steeds slimmere database van te maken zodat je met een zoekopdracht snel de relevante bestanden gevonden krijgt.

En Reiser, en JFS, en EXT, etc., etc. Harde schijven zijn niet dom, ze hebben gewoon geen weet van wat ze bevatten. Dat is de taak van het bestandssystem, en de FAT/MFT/geefhetbeestjeeennaam weet wel waar alle bestanden staan.

Er zijn redenen te bedenken waarom je ook je code in een database zou willen zetten. Het maken van een backup en het terugzetten ervan wordt een stuk eenvoudiger. Ook versioning en staging gaan denk ik eenvoudiger als alles in een database staat.

Tuurlijk, SVN is ook een database. Dat is leuk voor versioning. Zodra je deployed heb je die database niet meer nodig.

Backups maken van het bestandsysteem is ook altijd nog eenvoudiger. Je database hoeft er niet voor down en files van het ene bestandssysteem zijn over te zetten naar het andere.

Het enige nadeel dat ik kan bedenken is dat je niet meer met elke tekstverwerker de bestanden kunt bewerken. Maar als je dat probleem hebt opgelost dan is er volgens mij weinig op tegen.

Snelheid? Onderhoudbaarheid? Data != code? Je moet me toch eens uitleggen aan wat er zo goed is aan het halen van code die van een database gebruik maakt uit diezelfde database!

[ Voor 15% gewijzigd door AtleX op 01-02-2008 11:21 ]

[Voutloos]

f.v.b schreef op vrijdag 01 februari 2008 @ 11:07:
Maar om het nu meteen een 'slecht idee' te noemen zonder aan te geven waarom. Of het er onoverzichtelijk op wordt, ligt helemaal aan jezelf.

Het enige nadeel dat ik kan bedenken is dat je niet meer met elke tekstverwerker de bestanden kunt bewerken. Maar als je dat probleem hebt opgelost dan is er volgens mij weinig op tegen.

Voor het bewerken heb je in 5 minuten een interface gemaakt, dat is dus niet het echte probleem. Het zit hem meer in de andere 1001 nadelen. Deze discussie is vaker gevoerd en de punten van Johnny zijn ook al vaker gemaakt.

De vraag voor dit topic moet zijn: Beste g4wx3, waarom wil je in *(&%@##-naam je code in de database zetten?

[Kalentum]

Johnny schreef op vrijdag 01 februari 2008 @ 03:52:
Databases zijn voor data. Code is geen data.

Code is ook data. Een rijtje bytes die samen een 'record' vormen. Alleen het staat in een database genaamd 'filesystem'.

Als je functies wil sorteren moet je ze gewoone en logische naam geven, voorzien van commentaar, in een apart bestand steken, je kan ze zelf in klassen zetten als je dat leuk vindt.

In een database horen ze echt niet thuis, en ik zie ook niet in hoe het ooit overzichtelijk kan zijn als je code verspreid hebt in bestanden en in allerlei rijen in een database.

Nou als je een tabel 'objecten' hebt en een tabel 'methoden' met een object id daarin. En een tabel 'eigenschappen'
En in je SELECT statement laat je dus een complete class opbouwen.

Echt handig is het allemaal niet...

[Johnny]

rutgerw schreef op vrijdag 01 februari 2008 @ 12:11:
[...]
Code is ook data. Een rijtje bytes die samen een 'record' vormen. Alleen het staat in een database genaamd 'filesystem'.

En alle data is code omdat iedere byte een processorinstructie kan zijn.

[Kalentum]

Johnny schreef op vrijdag 01 februari 2008 @ 12:35:
[...]

En alle data is code omdat iedere byte een processorinstructie kan zijn.

Alle php-code is data. Niet alle data is php-code.

[Bosmonster]

Vanaf heden wil ik mijn php functies in MySQL opslaan/beheren, uiteraard blijven de functies nodig om een connectie te maken in blijft mijn php script.

Hiermee is al genoeg gezegd eigenlijk ook. Lekker centraal en het geeft precies aan waarom code niet thuishoort op een plek die bedoeld is voor data. Omdat je dus code nodig hebt om iets met de data te doen...

[ Voor 8% gewijzigd door Bosmonster op 01-02-2008 12:55 ]

[Bosmonster]

rutgerw schreef op vrijdag 01 februari 2008 @ 12:52:
[...]

Alle php-code is data. Niet alle data is php-code.

Even in kindertaal:

Alles is tekentjes. Daar gaat het niet om. Niet alle tekentjes zijn data. Het verschil code/data gaat om wat de tekentjes voorstellen. Bij code gaat het om uitvoerbare tekentjes. Bij data gaat het om tekentjes die een bepaalde inhoud vertegenwoordigen.

Uitvoerbare tekentjes wil je niet op een plek bedoeld voor contentuele tekentjes (data). Uitvoerbare tekentjes wil je in een bestand dat uitgevoerd kan worden. Tuurlijk kun je dat bestand eerst vullen ergens anders uit, maar je ziet dan zelf al dat je een extra onnodige slag maakt.

[ Voor 23% gewijzigd door Bosmonster op 01-02-2008 12:58 ]

[Voutloos]

rutgerw schreef op vrijdag 01 februari 2008 @ 12:52:
[...]


Alle php-code is data. Niet alle data is php-code.

Dat is Johnny zijn punt dus juist. Jij generaliseert dus door code op de grote hoop genaamd data te willen gooien.

[WouZz]

Ach, ik doe het ook altijd.

Gewoon

SQL:

SELECT php FROM mysite WHERE data = $id

die doet dan weer een

SQL:

SELECT forum FROM mysite WHERE data = $forumid

om extra snelheidswinst te behalen doe ik

SQL:

SELECT bytes FROM gzipped WHERE data = $byteid AND version = MAX(version)

om asynchone request te parsen doe ik een

SQL:

SELECT ajax FROM xmlhttprequest WHERE protocol= 'HTTP/1.1'

ben nu bezig met een tokenizer voor mn opcode die alles in XML formaat opslaat zodat ik alles alleen nog maar hoef te stylen met een door XSLT gegeneerde CSS die clientside gecached wordt in een cookie

[Bosmonster]

WouZz schreef op vrijdag 01 februari 2008 @ 13:12:
Ach, ik doe het ook altijd.

Gewoon

SQL:

SELECT php FROM mysite WHERE data = $id

die doet dan weer een

SQL:

SELECT forum FROM mysite WHERE data = $forumid

om extra snelheidswinst te behalen doe ik

SQL:

SELECT bytes FROM gzipped WHERE data = $byteid AND version = MAX(version)

om asynchone request te parsen doe ik een

SQL:

SELECT ajax FROM xmlhttprequest WHERE protocol= 'HTTP/1.1'

ben nu bezig met een tokenizer voor mn opcode die alles in XML formaat opslaat zodat ik alles alleen nog maar hoef te stylen met een door XSLT gegeneerde CSS die clientside gecached wordt in een cookie

Blij dat ik jouw code niet hoef te beheren. Een query die code ophaalt die weer een query uitvoert. En dan nog over de kolom 'data' die altijd maar een of andere id voorstelt (ipv daadwerkelijk data ).

[Voutloos]

Bos, de post van WouZz is puur grappig bedoelt.

hoop ik...

[Webgnome]

WouZz schreef op vrijdag 01 februari 2008 @ 13:12:
Ach, ik doe het ook altijd.

Gewoon

SQL:

SELECT php FROM mysite WHERE data = $id

die doet dan weer een

SQL:

SELECT forum FROM mysite WHERE data = $forumid

om extra snelheidswinst te behalen doe ik

SQL:

SELECT bytes FROM gzipped WHERE data = $byteid AND version = MAX(version)

om asynchone request te parsen doe ik een

SQL:

SELECT ajax FROM xmlhttprequest WHERE protocol= 'HTTP/1.1'

ben nu bezig met een tokenizer voor mn opcode die alles in XML formaat opslaat zodat ik alles alleen nog maar hoef te stylen met een door XSLT gegeneerde CSS die clientside gecached wordt in een cookie

Ik wil mij niet al teveel mengen in de discussie maar waarom DOE en/of WIL je dit?
Voutlooz. Ik hoop dat je gelijk hebt.

[WouZz]

Bosmonster schreef op vrijdag 01 februari 2008 @ 13:22:
[...]


Blij dat ik jouw code niet hoef te beheren. Een query die code ophaalt die weer een query uitvoert. En dan nog over de kolom 'data' die altijd maar een of andere id voorstelt (ipv daadwerkelijk data ).

Ja, om het makkelijker te maken heb ik een table relsolve met primary key id en foreign key var. Hier zet ik alle variabelen in met de regelnummers en client IP erbij zodat ik altijd na kan gaan waar ze vandaan komen en wat de waarde is. Best handig voor het optimaliseren van je code en je hebt geen refelction api meer nodig waardoor het zelfs op PHP3 draait. Voor de security set ik er ook een hash bij van de useragent, salt en microtime. Zo heb je voor iedere request dus je hele state in je database. Zo kan je later precies terugzien wat er gebeurd is op je site.

[Bosmonster]

WouZz schreef op vrijdag 01 februari 2008 @ 13:31:
[...]

Ja, om het makkelijker te maken heb ik een table relsolve met primary key id en foreign key var. Hier zet ik alle variabelen in met de regelnummers en client IP erbij zodat ik altijd na kan gaan waar ze vandaan komen en wat de waarde is. Best handig voor het optimaliseren van je code en je hebt geen refelction api meer nodig waardoor het zelfs op PHP3 draait. Voor de security set ik er ook een hash bij van de useragent, salt en microtime. Zo heb je voor iedere request dus je hele state in je database. Zo kan je later precies terugzien wat er gebeurd is op je site.

Voutloos schreef op vrijdag 01 februari 2008 @ 13:30:
Bos, de post van WouZz is puur grappig bedoelt.

hoop ik...

Volgens mij niet hoor

Of het is een hele goeie grappenmaker

[WouZz]

Even het laatste nieuws tussendoor. Microsoft biedt bijna 45 miljard dollar voor Yahoo

[mcdronkz]

Bosmonster schreef op vrijdag 01 februari 2008 @ 13:34:
[...]


[...]


Volgens mij niet hoor

Ben je echt zo naïef ?

[Bosmonster]

mcdronkz schreef op vrijdag 01 februari 2008 @ 13:38:
[...]

Ben je echt zo naïef ?

Nee goedgelovig

[--MeAngry--]

Kan me er iets bij voorstellen Bosmonster... Ik ken mensen die zoiets serieus zouden maken en het helemaal geweldig zouden vinden.

[Bosmonster]

--MeAngry-- schreef op vrijdag 01 februari 2008 @ 13:45:
Kan me er iets bij voorstellen Bosmonster... Ik ken mensen die zoiets serieus zouden maken en het helemaal geweldig zouden vinden.

Na de reacties van een aantal mensen in dit topic inderdaad...

Ik post hier ook niet zoveel meer, dus weet ook even niet meer welke user ik serieuzer moet nemen dan de ander

[Verwijderd]

WouZz schreef op vrijdag 01 februari 2008 @ 13:37:
Even het laatste nieuws tussendoor. Microsoft biedt bijna 45 miljard dollar voor Yahoo

En dit moet grappig zijn? Of wil je hiermee jezelf redden uit een eventuele discussie..."ja maar ik was niet serieus hoor".

Nouja, je doet maar .

[Swaptor]

Terug ontopic, en ik zou graag de TS zijn licht hierover zien schijnen: waarom wil je je php-code (of alleen de functienamen?) in een DB opslaan?

[leuk_he]

Johnny schreef op vrijdag 01 februari 2008 @ 03:52:
Databases zijn voor data. Code is geen data. Als je functies wil sorteren moet je ze gewoone en logische naam geven, voorzien van commentaar, in een apart bestand steken, je kan ze zelf in klassen zetten als je dat leuk vindt.

In een database horen ze echt niet thuis, en ik zie ook niet in hoe het ooit overzichtelijk kan zijn als je code verspreid hebt in bestanden en in allerlei rijen in een database.

Wellicht ben je dat gewend in php, maar code in databases is niet echt ongewoon:

http://www.digitalpropuls...ing/Triggers_in_MySQL_5_0

Of nog verder: webpaginas met plsql genereren.

http://employment.byron.c...sql-web-applications.html

Dit lijkt ver gezocht, maar als je database structuur erg vast zit aan je code structuur horen ze meer bij elkaar. Als je mapping van de tabbellen extra handelingen nodig heeft om van de userrepresenatite naar relationeel, dan kan het handig zijn dit in database functies te stoppen. (voorbeeld, kalender met allerlei status bits, GetNextActiveDay ... ) Ook vanuit performance kan het handig zijn dat de code in de DB zit(maar deze reden werkt niet voor topic starter), Als je voor veel kleine queries niet elke keer naar de database hoeft, dan scheelt dat veel netwerk verkeer.

Maar heb je het wel over een database die code kan uitvoeren.

[WouZz]

Verwijderd schreef op vrijdag 01 februari 2008 @ 13:51:
[...]

En dit moet grappig zijn? Of wil je hiermee jezelf redden uit een eventuele discussie..."ja maar ik was niet serieus hoor".

Nouja, je doet maar .

Laat ik het zo zeggen. Use the right tool for the right job. Het argument dat data data is en dus in een database past is natuurlijk makkelijk gemaakt, maar ik ga toch ook niet al mn DVD's in een BLOB stoppen of mn Windows DLL's in MySQL douwen omdat ik ze dan beter kan beheren?

Verder kan je natuurlijk wel zeggen dat je creatief met de gegeven middelen om kan gaan als je echt dingen wil doen die op een conventionele manier niet gedaan kunnen worden. Maar om nou te zeggen dat ik in PHP een Javascript compiler ga maken die daardoor serverside javascript ondersteund en zo multithreaded PHP applicaties kan maken gaat natuurlijk wat te ver.

[wjv]

Helemaal een gek idee is het niet om code in een database op te slaan. Voor sommige situaties kan het zeer nuttig zijn om versie beheer van je code uit je database te doen.

In ons project slaan wij objecten op in een (Oracle) database. Deze zijn gemaakt met een bepaalde combinatie van versies van (python) sources. Wij zouden graag volledig een koppeling willen leggen met deze python code en de objecten in de database. Waarom ? Omdat er aan deze objecten (grote) files gekoppeld zijn. Wij zouden graag deze files op een gegeven moment weg willen (kunnen) gooien wanneer ze bijvoorbeeld meer dan een jaar niet benaderd zijn. De files zijn geheel reproduceerbaar aan de hand van de source code (specifieke versie) en de objecten (parameters) in de database. Nu moeten we een koppeling tussen CVS en Oracle leggen om dit tot stand te brengen, mooier zou zijn als we vanuit Oracle versie control kunnen doen. Dan kunnen we een 'harde' link tussen elk object in de database en de bijbehorende code leggen.

Dit is natuurlijk een specifieke situatie, maar er zijn scenarios denkbaar waar opslag van de soruce code in je database een nuttige toevoeging is.

[Kalentum]

Bosmonster schreef op vrijdag 01 februari 2008 @ 12:56:
[...]
Alles is tekentjes. Daar gaat het niet om. Niet alle tekentjes zijn data. Het verschil code/data gaat om wat de tekentjes voorstellen. Bij code gaat het om uitvoerbare tekentjes. Bij data gaat het om tekentjes die een bepaalde inhoud vertegenwoordigen.

Uitvoerbare tekentjes wil je niet op een plek bedoeld voor contentuele tekentjes (data). Uitvoerbare tekentjes wil je in een bestand dat uitgevoerd kan worden. Tuurlijk kun je dat bestand eerst vullen ergens anders uit, maar je ziet dan zelf al dat je een extra onnodige slag maakt.

PHP code is niet uitvoerbaar. Het is geen binaire data ofzo. Voor een mens is het gewoon een stukje tekst. Of je het nou in database A of database B opslaat. De ene database (mysql) heeft natuurlijk meer overhead dan de andere (filesystem) dus misschien is het beter om voor het filesystem te gaan... maar conceptueel maakt het geen donder uit.

[WouZz]

leuk_he schreef op vrijdag 01 februari 2008 @ 13:54:
[...]


Wellicht ben je dat gewend in php, maar code in databases is niet echt ongewoon:

http://www.digitalpropuls...ing/Triggers_in_MySQL_5_0

Of nog verder: webpaginas met plsql genereren.

http://employment.byron.c...sql-web-applications.html

Dit lijkt ver gezocht, maar als je database structuur erg vast zit aan je code structuur horen ze meer bij elkaar. Als je mapping van de tabbellen extra handelingen nodig heeft om van de userrepresenatite naar relationeel, dan kan het handig zijn dit in database functies te stoppen. (voorbeeld, kalender met allerlei status bits, GetNextActiveDay ... ) Ook vanuit performance kan het handig zijn dat de code in de DB zit(maar deze reden werkt niet voor topic starter), Als je voor veel kleine queries niet elke keer naar de database hoeft, dan scheelt dat veel netwerk verkeer.

Maar heb je het wel over een database die code kan uitvoeren.

Code in je database is het verplaatsen van applicatie logica naar je RDBMS. PHP in je database stoppen om vervolgens te evalueren is naar mijn idee een groot gebrek aan inzicht (of een overschot daaraan). Het beheer van grote hoeveelheden code doe je door alles op een logische manier te bundelen, te organiseren en te laden wanneer dat nodig is met behulp van include.

[Verwijderd]

rutgerw schreef op vrijdag 01 februari 2008 @ 14:01:
[...]


PHP code is niet uitvoerbaar. Het is geen binaire data ofzo. Voor een mens is het gewoon een stukje tekst. Of je het nou in database A of database B opslaat. De ene database (mysql) heeft natuurlijk meer overhead dan de andere (filesystem) dus misschien is het beter om voor het filesystem te gaan... maar conceptueel maakt het geen donder uit.

PHP code is in zoverre niet uitvoerbaar omdat het niet gecompiled wordt naar machinecode (uiteindelijk wel door php.exe, maar dat gebeurt on the fly)...maar er blijft nog steeds een wezenlijk verschil bestaan tussen gegevens (welke je in een database wilt stoppen om er informatie van te maken) en PHP code.

[ Voor 51% gewijzigd door Verwijderd op 01-02-2008 14:11 ]

[Janoz]

rutgerw schreef op vrijdag 01 februari 2008 @ 14:01:
PHP code is niet uitvoerbaar...

Ik neem aan dat je zelf ook wel ziet wat voor enorm vreemd statement je hier maakt. Of het binair is of leesbaar door mensen is helemaal geen criterium voor of iets uitvoerbaar is. In de context van een php website is de php code gewoon uitvoerbaar.

[ Voor 9% gewijzigd door Janoz op 01-02-2008 14:15 ]

[Kalentum]

WouZz schreef op vrijdag 01 februari 2008 @ 14:04:
[...]
Code in je database is het verplaatsen van applicatie logica naar je RDBMS.

Wat is het principiele verschil tussen:

PHP:

require_once('nieuws.php');

en

code:

SELECT code FROM modules WHERE id = 'nieuws';

Je database weet dan nog steeds niets van je applicatie en hecht daar geen enkele waarde aan. Het RDBMS wordt niet 'uitgebreid' met applicatie logica.

[Voutloos]

rutgerw schreef op vrijdag 01 februari 2008 @ 14:01:
PHP code is niet uitvoerbaar. Het is geen binaire data ofzo. Voor een mens is het gewoon een stukje tekst. Of je het nou in database A of database B opslaat. De ene database (mysql) heeft natuurlijk meer overhead dan de andere (filesystem) dus misschien is het beter om voor het filesystem te gaan... maar conceptueel maakt het geen donder uit.

• Iedereen in dit topic weet dat PHP nog geinterpreteerd moet worden
• 'gewoon een stukje tekst' is wederom een generalisatie
• Een db heeft niet per se meer overhead dan een fs, je hebt enkel meer overhead als je zelf willens en wetens dingen op de onlogische plek opslaat
• Dat je het op een onlogische plek opslaat betekent dat je concept toch niet helemaal lekker is. Eea is ook al duidelijk aan de hand van de opmerking 'uiteraard blijven de functies nodig om een connectie te maken in mijn php script'.

rutgerw schreef op vrijdag 01 februari 2008 @ 14:12:
Wat is het principiele verschil tussen:

PHP:

require_once('nieuws.php');

en

code:

SELECT code FROM modules WHERE id = 'nieuws';

Je database weet dan nog steeds niets van je applicatie en hecht daar geen enkele waarde aan. Het RDBMS wordt niet 'uitgebreid' met applicatie logica.

Het verschil is dat de 1e methode een standaard PHP constructie voor het uitvoeren van code is en het 2e een ranzige, onnatuurlijke hack en daar kan je echt heel veel principes tegenaan gooien.

We snappen allemaal dat je code ergens anders vandaan kan toveren en laten uitvoeren. Dat betekent nog niet dat je het dan maar moet doen. Je wijkt af van de normale constructie, dus daar moet je een goede reden voor hebben. Vandaar, zoals ik eerder zei, is de enige vraag in dit topic: "Wáárom moet het nou allemaal per se in de db?".

[krvabo]

Voutloos schreef op vrijdag 01 februari 2008 @ 14:22:
[...]
We snappen allemaal dat je code ergens anders vandaan kan toveren en laten uitvoeren. Dat betekent nog niet dat je het dan maar moet doen. Je wijkt af van de normale constructie, dus daar moet je een goede reden voor hebben.

Inderdaad.
Je zou bijvoorbeeld al je code in een zip kunnen zetten. Dan kun je met php de dir doorlopen op de zip met het hoogste versienummer! Of de zip op een andere server zetten, met fgets ophalen, uitpakken en uitvoeren!

ALS je het al uit je databaseserver zou willen halen zou ik dus wel alles eerst naar een bestand schrijven, en dan uitvoeren. Dit kan je ook zo maken dat de data wordt weggeschreven door een apart phpbestand wat je alleen aanroept als er iets is veranderd. Dit kan je natuurlijk ook wel automatisch doen met een timestamp met de laatste verandering.. maargoed.
Blijft het feit dat je geen eval moet gebruiken.

[Confusion]

g4wx3 schreef op vrijdag 01 februari 2008 @ 00:40:
Vanaf heden wil ik mijn php functies in MySQL opslaan/beheren

Even de ondergesneeuwde vraag van Voutloos herhalend: waarom wil je dat? Welk probleem probeer je daar mee op te lossen?

[Verwijderd]

Voutloos schreef op vrijdag 01 februari 2008 @ 14:22:
We snappen allemaal dat je code ergens anders vandaan kan toveren en laten uitvoeren. Dat betekent nog niet dat je het dan maar moet doen. Je wijkt af van de normale constructie, dus daar moet je een goede reden voor hebben. Vandaar, zoals ik eerder zei, is de enige vraag in dit topic: "Wáárom moet het nou allemaal per se in de db?".

Waarom moet je het nu persee een db noemen? Het is gewoon een data source. Of dat nu vanaf het filesystem komt, een database of wellicht over het netwerk maakt helemaal niets uit. De enige echte misser is binnen deze context wellicht dat 'require_once' niet makkelijk genoeg aan te passen is wat betreft de datasource, daardoor is je enige optie af te wijken van de 'normale contructie'.

[FragFrog]

WouZz schreef op vrijdag 01 februari 2008 @ 14:04:
Het beheer van grote hoeveelheden code doe je door alles op een logische manier te bundelen, te organiseren en te laden wanneer dat nodig is met behulp van include.

Nee, met behulp van autoload

Bosmonster schreef op vrijdag 01 februari 2008 @ 13:34:
Volgens mij niet hoor

Of het is een hele goeie grappenmaker

ben nu bezig met een tokenizer voor mn opcode die alles in XML formaat opslaat zodat ik alles alleen nog maar hoef te stylen met een door XSLT gegeneerde CSS die clientside gecached wordt in een cookie

'k weet niet hoor.. Vooral die laatste zin is toch echt wel een dead giveaway. Ik bedoel, er is toch niemand die dat serieus doet. Right?

[ Voor 44% gewijzigd door FragFrog op 02-02-2008 01:20 ]

[SchizoDuckie]

FragFrog schreef op zaterdag 02 februari 2008 @ 01:17:
[...]

<quote zeer enge zin>

'k weet niet hoor.. Vooral die laatste zin is toch echt wel een dead giveaway. Ik bedoel, er is toch niemand die dat serieus doet. Right?

^2 Ik hoop dat ie dat wel open source maakt want wie wil er nou niet opcode in xml die door xsl gegenereerde css in een cookie opslaat

[Verwijderd]

krvabo schreef op vrijdag 01 februari 2008 @ 15:32:
Je zou bijvoorbeeld al je code in een zip kunnen zetten.

Bij java is dat heel gebruikelijk: .jar en .war files zijn gewoon zipjes.
Maar 't verschil is dat 't onderdeel is van 't framework, en je geen extra handelingen nodig hebt om je assemblies te benaderen. Als requireonce, etc. standaard ook andere datasources dan 't filesystem zou ondersteunen, zou er niks aan de hand zijn, maar dat is op dit moment nou eenmaal nog niet zo...

[b19a]

Verwijderd schreef op zaterdag 02 februari 2008 @ 03:01:
[...]
Bij java is dat heel gebruikelijk: .jar en .war files zijn gewoon zipjes.
Maar 't verschil is dat 't onderdeel is van 't framework, en je geen extra handelingen nodig hebt om je assemblies te benaderen. Als requireonce, etc. standaard ook andere datasources dan 't filesystem zou ondersteunen, zou er niks aan de hand zijn, maar dat is op dit moment nou eenmaal nog niet zo...

PHP kent dit ook al: http://nl2.php.net/phar (Phar). Ik heb er nog niet mee geexperimenteerd, maar het lijkt wel aardig!

FragFrog schreef op zaterdag 02 februari 2008 @ 01:17:
[...]

Nee, met behulp van autoload

Ik heb gister een framework omgebouwd naar __autoload, wat een plezier geeft dat zeg! Kan het zeker aanraden .

[mocean]

Kwam ineens op een idee. Met stream_wrapper_register kan je ook je eigen protocol handler maken (voor SQL), als dat werkt kan je volgens mij dit doen:

include("sql://SELECT code FROM database WHERE id=nieuws");

[Kalentum]

Janoz schreef op vrijdag 01 februari 2008 @ 14:10:
[...]

Ik neem aan dat je zelf ook wel ziet wat voor enorm vreemd statement je hier maakt.

Sorry, het kan een beetje schokkend overkomen. Maar het is echt zo. Een file met php code daarin is niet uitvoerbaar. Daar komt nog echt een PHP interpreter bij kijken die de voor mensen leesbare code om moet zetten naar iets dat een processor begrijpt. Dus die PHP interpreter is uitvoerbaar. Onder Linux hoeft een PHP bestand niet eens de executable vlag te hebben.

Of het binair is of leesbaar door mensen is helemaal geen criterium voor of iets uitvoerbaar is.

Waar het om gaat is de redenen die TS heeft om code in een database op te slaan. Hij heeft niet tevreden met zijn huidige database (filesystem) en zoekt dus meerwaarde en denkt dat een rdbms hem dat kan geven.

Een uitvoerbaar bestand in een database opslaan geeft geen meerwaarde. Een tekst opslaan in een database (waar tekst een nieuwberichtje kan zijn, een stukkie PHP code enz enz) heeft wel meerwaarde. je kan er meer metadata aan hangen dan een filesystem heeft. Sorteren, doorzoeken, allemaal makkelijker met een database dan met een file system. Misschien dat TS wel dat soort dingen wou doen met zijn 'ik wil mijn code in de database'-vraag. Maar dat weten we dus nog niet.

[Voutloos]

rutgerw schreef op zaterdag 02 februari 2008 @ 10:09:
.. Maar dat weten we dus nog niet.

En kunnen we maar beter wachten op de motivatie van de ts, ipv in het wildeweg blaten. Dat het kan weet iedereen.

[iH8]

je db-class in een db? het gegeven lijkt me superonhandig omdat je sommige classes / methods niet op kunt slaan in de db. dan heb je dus het ene op je FS staan en het ander in je DB. overzichtelijker wordt het er niet op.

[djiwie]

Verwijderd schreef op vrijdag 01 februari 2008 @ 15:45:
Het is gewoon een data source. Of dat nu vanaf het filesystem komt, een database of wellicht over het netwerk maakt helemaal niets uit.

Ik ben het met Mark eens. Of het handig is of niet om je code te splitsen naar een bestand die je functies ophaalt uit de database en naar een database met de rest van je code is een tweede, maar dat is een afweging die TS zelf maar moet maken.

Ik heb zelf ook wel eens code in een database gezet voor een project, maar dat waren codes om de MRZ-regels van identiteitsbewijzen te controleren. Alle logica zat in de applicatie zelf en de specifieke controleregels voor elk soort identiteitsbewijs (en per land enzo) zaten in de database, zodat die makkelijk uitgebreid konden worden. Dat was overigens geen PHP-code, maar een intern taaltje die specifiek voor die toepassing gemaakt is. Werkt prima
Alhoewel het natuurlijk niet helemaal vergelijkbaar is met wat de TS wil geloof ik

[eamelink]

Voutloos schreef op vrijdag 01 februari 2008 @ 14:22:
Je wijkt af van de normale constructie, dus daar moet je een goede reden voor hebben.

Van wie moet dat? PHP lijkt me nou niet echt de taal waar je van kan zeggen dat die zo geniaal is opgebouwd dat het een stommiteit is om dingen anders te doen dan de makers in gedachten hadden .

Daar komt nog bij; dit is prima op een standaard manier te implementeren met autoload, waardoor het dus niet eens afwijkt van 'de normale constructie'

Vandaar, zoals ik eerder zei, is de enige vraag in dit topic: "Wáárom moet het nou allemaal per se in de db?".

Daar zijn redenen genoeg voor te verzinnen, je kunt van stukken code allerlei versies bijhouden, ownerships, benodigde rechten, wat voor metadata dan ook . Dat de meesten van ons uit de voeten kunnen met een archaische boomstructuur om bestanden op te slaan betekent niet dat iedereen dat zou moeten doen natuurlijk

iH8 schreef op zaterdag 02 februari 2008 @ 10:23:
je db-class in een db? het gegeven lijkt me superonhandig omdat je sommige classes / methods niet op kunt slaan in de db. dan heb je dus het ene op je FS staan en het ander in je DB. overzichtelijker wordt het er niet op.

Je DB-class kan toch ook gewoon in de DB? Ik zie het probleem niet echt. Helemaal aan het begin van de executie van je applicatie doe je even een low-level aanroep naar de database om die class te laden, en vervolgens kun je hem gebruiken .

[ Voor 22% gewijzigd door eamelink op 02-02-2008 11:17 ]

[WouZz]

Ok, feit is gewoon dat je alles wel in je database (of datasource whatever) kan stoppen. Om mijn creative geest nog maar even wat ruimte te geven.. Ik zie de volgende voordelen:

• Schaalbaarheid: mocht je niet over een NFS share beschikken, dan kan je meerdere webservers over dezelde source laten beschikken icm met een dedicated database server. Desondanks zit je wel met de low level bootstrap, want ergens heb je gewoon PHP in files nodig om de database connectie te openen (en die gesynced moeten zijn).
• Version control: je kan meerdere (legacy) versies ondersteunen door dynamisch een bepaalde revision te laden. De vraag is of je niet juist alleen de laatste versie wil draaien, maar goed. Misschien een idee voor de IE8/9/10 implementatie..?
• Namespace support: dynamisch verschillende interface implementaties ondersteunen: import('client.core.web'), import('client.core.ws').
• Security: verschillende databaseusers met verschillende rechten. Als we dat permissie systeem al hebben, waarom niet gebruiken dan?
• Backups: mysqldump en je bent klaar, geen gezeik met FTP/tar enz.

Zo, mooi lijstje toch? Punt is alleen dat alle bovenstaande punten ook op de conventionele manier ook op te lossen zijn, en waarschijnlijk met meer mogelijkheden. Misschien moeten we de vraag dus omdraaien, wat is de reden om niet voor een filebased oplossing te gaan?

[FragFrog]

eamelink schreef op zaterdag 02 februari 2008 @ 11:15:
Daar komt nog bij; dit is prima op een standaard manier te implementeren met autoload, waardoor het dus niet eens afwijkt van 'de normale constructie'

Voor de normale constructie hoef je geen eval() te gebruiken. Eval() is een stuk langzamer dan normale code en het alternatief is code eerst wegschrijven in files en die includen wat nauwelijks beter is.

De enige goede reden om een database te gebruiken voor code is de mogelijkheid relaties en mappings te maken tussen code, maar dat weegt lang niet op tegen de nadelen - helemaal niet omdat je dat ook prima op andere manieren kan doen. Zo heb ik zelf al eens een systeem geschreven dat parent/child relaties tussen classes opslaat in een XML tree die simpelweg met xpath doorlopen kan worden bij een pagerequest

[mocean]

misschien ook een oplossing, voor functies (kwam dit in een ander topic tegen), kijk eens naar
create_function