[PHP/(My)SQL] voor dummies #109

quote:

Op dinsdag 11 juni 2013 10:24 schreef rekenwonder het volgende:

[..]

https://github.com/search?q=extension%3Aphp+mysql_query+%24_GET :-)

Wow, je zou toch verwachten dat ook PHP zelf hier een keer wat aan zou doen.

quote:

Op dinsdag 11 juni 2013 11:55 schreef Pakspul het volgende:

[..]

Wow, je zou toch verwachten dat ook PHP zelf hier een keer wat aan zou doen.

Doe maar een voorstel :-)

quote:

Op dinsdag 11 juni 2013 11:55 schreef Pakspul het volgende:

[..]

Wow, je zou toch verwachten dat ook PHP zelf hier een keer wat aan zou doen.

mysql_query() is al depricated.

quote:

Op dinsdag 11 juni 2013 13:18 schreef Tijn het volgende:

[..]

mysql_query() is al depricated.

mysqli_query() niet en die is net zo onveilig als je het op dezelfde manier gebruikt.

quote:

Op dinsdag 11 juni 2013 13:20 schreef mstx het volgende:
mysqli_query() niet en die is net zo onveilig als je het op dezelfde manier gebruikt.

PDO idem dito.

ach, het is maar voor een stom school opdrachtje.

echter heb ik wel weer iets gevonden waar ik niet uit kom >.<


Als ik mijn variabele($achternaam) met een waarde van cijfers vul doet die het wel. als ik hem met tekens vul doet die het niet. de type van het desbetreffende veld is char(20).

quote:

Op dinsdag 11 juni 2013 13:20 schreef mstx het volgende:

[..]

mysqli_query() niet en die is net zo onveilig als je het op dezelfde manier gebruikt.

alles is zo onveilig als de manier waar jij het op gebruikt...?

quote:

Op dinsdag 11 juni 2013 13:58 schreef mrjobby het volgende:
Als ik mijn variabele($achternaam) met een waarde van cijfers vul doet die het wel. als ik hem met tekens vul doet die het niet. de type van het desbetreffende veld is char(20).

Dat komt omdat je geen quotes gebruikt. Maar ook hier is PDO de oplossing :-)

quote:

Op dinsdag 11 juni 2013 14:01 schreef rekenwonder het volgende:

[..]

Dat komt omdat je geen quotes gebruikt. Maar ook hier is PDO de oplossing :-)

Ik ben niet bekend met PDO, wat houd dat ongeveer in?

PDO is de aanbevolen methode (zegt de gek) om queries in PHP af te vuren. Het gebruikt o.a. parameter binding (veilig) i.p.v. dat je strings opbouwt (onveilig).

http://php.net/manual/en/book.pdo.php

quote:

Op dinsdag 11 juni 2013 14:01 schreef mschol het volgende:

[..]

alles is zo onveilig als de manier waar jij het op gebruikt...?

Dat is correct. Alles is zo (on)veilig als dat je het zelf maakt.

quote:

Op dinsdag 11 juni 2013 14:08 schreef rekenwonder het volgende:
PDO is de aanbevolen methode (zegt de gek) om queries in PHP af te vuren. Het gebruikt o.a. parameter binding (veilig) i.p.v. dat je strings opbouwt (onveilig).

http://php.net/manual/en/book.pdo.php

of de spoedcursus:

1) maak verbinding met je DB: http://www.php.net/manual/en/pdo.connections.php
2) maak een statement van een query: http://www.php.net/manual/en/pdo.prepare.php
3) voer het statement uit: http://www.php.net/manual/en/pdostatement.execute.php
4) doe eventueel wat leuks met de results: http://www.php.net/manual/en/pdostatement.fetch.php

Mensen, wisten jullie dat als je InnoDB gebruikt voor je tabel/data je met een INSERT ... ON DUPLICATE KEY UPDATE het AUTO_INCREMENT veld ook automatisch veranderd? bij een update dan wel te verstaan want bij een INSERT is het normaal.

Nu gebruik ik zelf een tabel om regels toe te voegen maar ook om regels te updaten (iets wat vele malen vaker voorkomt dan de inserts) dus veranderd continue het AUTO_INCREMENT veld. Ik heb nu al 3,5miljoen regels en weet dat er zo'n 25 miljoen INSERT ON DUPLICATE KEY queries gedaan zijn, dus is het hoogste AUTO_INCREMEN veld niet 3,5mil maar 25.032.321 . Nu gebruik ik wel een BIGINT voor het veld maar toch... het zal sneller opraken dan dat ik echt 'unieke' records heb.

Maar er is een oplossing
http://dev.mysql.com/doc/(...)rement-handling.html

innodb_autoinc_lock_mode

Hebben jullie ervaring met deze optie? en eventuele performance? of zaken waar ik dan bij moet gaan opletten?

Dat is veranderd sinds versie 5.1, al een tijdje terug dus. Als je lock mode op 0 zou zetten dan heeft dat wel een negatieve impact op performance vanwege het wachten op auto increment locks.

@Zoem; maar dat geld niet voor MyISAM en andere database formaten (voor zover ik weet).

Maar in mijn geval is het maar 1 script die de tabellen aanvult/update, verder heeft de rest alleen maar lees toegang! zal het dan nog wat uitmaken? ben echt bang dat ik met een jaartje door mijn bigint heen ben

quote:

Op dinsdag 11 juni 2013 21:29 schreef Chandler het volgende:
Mensen, wisten jullie dat als je InnoDB gebruikt voor je tabel/data je met een INSERT ... ON DUPLICATE KEY UPDATE het AUTO_INCREMENT veld ook automatisch veranderd? bij een update dan wel te verstaan want bij een INSERT is het normaal.

Nu gebruik ik zelf een tabel om regels toe te voegen maar ook om regels te updaten (iets wat vele malen vaker voorkomt dan de inserts) dus veranderd continue het AUTO_INCREMENT veld. Ik heb nu al 3,5miljoen regels en weet dat er zo'n 25 miljoen INSERT ON DUPLICATE KEY queries gedaan zijn, dus is het hoogste AUTO_INCREMEN veld niet 3,5mil maar 25.032.321 . Nu gebruik ik wel een BIGINT voor het veld maar toch... het zal sneller opraken dan dat ik echt 'unieke' records heb.

Maar er is een oplossing
http://dev.mysql.com/doc/(...)rement-handling.html

innodb_autoinc_lock_mode

Hebben jullie ervaring met deze optie? en eventuele performance? of zaken waar ik dan bij moet gaan opletten?

Wat stom! Het lijkt me juist dat je een UPDATE doet omdat.. bizar.

quote:

Op dinsdag 11 juni 2013 22:12 schreef Chandler het volgende:
@Zoem; maar dat geld niet voor MyISAM en andere database formaten (voor zover ik weet).

Juh, ik reageerde ook even specifiek op Inno.

quote:

Maar in mijn geval is het maar 1 script die de tabellen aanvult/update, verder heeft de rest alleen maar lees toegang! zal het dan nog wat uitmaken? ben echt bang dat ik met een jaartje door mijn bigint heen ben

Dan ben ik benieuwd om wat voor soort data het gaat. Je zit niet zomaar aan max bigint (2^64-1).

signed van -9.223.372.036.854.775.808 tot 9.223.372.036.854.775.807
unsigned van 0 tot 18.446.744.073.709.551.615

Dat is wel een stuk meer dan jouw 25 miljoen.

Ik vond het ook nogal apart maar goed...

@zoem; dan moet ik inderdaad nog even stevig mijn best doen...

quote:

Op woensdag 12 juni 2013 01:34 schreef Chandler het volgende:
Ik vond het ook nogal apart maar goed...

@zoem; dan moet ik inderdaad nog even stevig mijn best doen...

Ongeveer 290.000 jaar iedere seconde 1 miljoen inserts ... updates uitvoeren. En dan ga ik uit van een signed reeks (waar je alleen het positieve deel gebruikt).

quote:

Op dinsdag 11 juni 2013 00:57 schreef slacker_nl het volgende:

[..]

Daarom hebben ze (s)printf uitgevonden, als er iets lelijkers is dan "dit " . $is . " toch" . $echt_kut en foutgevoeliger dan: "Dit is $misschien toch wel beterder dan $stomme punten $overal moeten $zetten". En ik weet niet precies hoe het in PHP is, maar sprintf("%s is nog prettiger\n", $this->dit());

sprintf() werkt gewoon in php

quote:

Op maandag 10 juni 2013 12:35 schreef Tijn het volgende:
Ik denk dat de meeste PHP'ers geen certificering hebben.

Dat is correct

quote:

Op vrijdag 14 juni 2013 20:02 schreef Light het volgende:

[..]

Ongeveer 290.000 jaar iedere seconde 1 miljoen inserts ... updates uitvoeren. En dan ga ik uit van een signed reeks (waar je alleen het positieve deel gebruikt).

euh lol, dan kan ik inderdaad nog wel even doorgaan maar is het niet zo dat steeds het veranderen van id's (want een id kan wel 10.000 keer veranderen op deze manier) niet handig is voor het wegschrijven van de data? (steeds het verplaatsen van data?!)

quote:

Op vrijdag 14 juni 2013 20:40 schreef Chandler het volgende:

[..]

euh lol, dan kan ik inderdaad nog wel even doorgaan maar is het niet zo dat steeds het veranderen van id's (want een id kan wel 10.000 keer veranderen op deze manier) niet handig is voor het wegschrijven van de data? (steeds het verplaatsen van data?!)

Het lijkt me niet dat het id verandert. Als het record nog niet in de database is, wordt het toegevoegd. Als het al wel aanwezig is, moet het uniek zijn op basis van een andere key dan het id (anders heb je niets aan die INSERT .. ON DUPLICATE KEY UPDATE functionaliteit, er moet wel een duplicate key zijn).

quote:

Op vrijdag 14 juni 2013 20:04 schreef Light het volgende:

[..]

sprintf() werkt gewoon in php

Dat weet ik, maar ik wilde heel wat anders zeggen maar blergh ofzo. Ik wilde zeggen: In Perl kan je methods niet gebruiken in string interpolitie, dus dan moet je printf("bla %s", $this->iets()) doen ipv "bla $this->iets()" Maar dat zal in PHP ook vast zo zijn.

quote:

Op vrijdag 14 juni 2013 20:45 schreef Light het volgende:

[..]

Het lijkt me niet dat het id verandert. Als het record nog niet in de database is, wordt het toegevoegd. Als het al wel aanwezig is, moet het uniek zijn op basis van een andere key dan het id (anders heb je niets aan die INSERT .. ON DUPLICATE KEY UPDATE functionaliteit, er moet wel een duplicate key zijn).

Waarom zou de data elders worden weggeschreven worden als de key veranderd? Dat zal onder water wel gewoon een pointer zijn naar, dat veranderen maakt weinig verschil..

quote:

Op vrijdag 14 juni 2013 20:46 schreef slacker_nl het volgende:

[..]

Dat weet ik, maar ik wilde heel wat anders zeggen maar blergh ofzo. Ik wilde zeggen: In Perl kan je methods niet gebruiken in string interpolitie, dus dan moet je printf("bla %s", $this->iets()) doen ipv "bla $this->iets()" Maar dat zal in PHP ook vast zo zijn.

Ik betwijfel of "bla $this->iets()" in php werkt, maar volgens mij moet je dat ook helemaal niet willen gebruiken.

quote:

Op vrijdag 14 juni 2013 20:48 schreef slacker_nl het volgende:

[..]

Waarom zou de data elders worden weggeschreven worden als de key veranderd? Dat zal onder water wel gewoon een pointer zijn naar, dat veranderen maakt weinig verschil..

Voorbeeldje:

Als ik dan deze query uitvoer:


Dan wordt bij de eerste keer netjes een nieuw record aangemaakt met id 1. Als ik de query nog een keer uitvoer, wordt de auto-increment waarde van de tabel wel verhoogd maar het id van de rij verandert niet. Er wordt dan ook geen data verplaatst. Er wordt alleen het volgende nummer geclaimd van de auto-increment lijst en pas daarna wordt gekeken of het invoegen succesvol is. (Als een insert faalt en er staat geen on duplicate key update bij, wordt de auto-increment waarde alsnog wel met 1 verhoogd.)

quote:

Op vrijdag 14 juni 2013 20:57 schreef Light het volgende:

[..]

Ik betwijfel of "bla $this->iets()" in php werkt, maar volgens mij moet je dat ook helemaal niet willen gebruiken.

Dit is wat het doet:

quote:

Op vrijdag 14 juni 2013 21:14 schreef Light het volgende:

[..]

Voorbeeldje:
[ code verwijderd ]

Als ik dan deze query uitvoer:
[ code verwijderd ]

Dan wordt bij de eerste keer netjes een nieuw record aangemaakt met id 1. Als ik de query nog een keer uitvoer, wordt de auto-increment waarde van de tabel wel verhoogd maar het id van de rij verandert niet. Er wordt dan ook geen data verplaatst. Er wordt alleen het volgende nummer geclaimd van de auto-increment lijst en pas daarna wordt gekeken of het invoegen succesvol is. (Als een insert faalt en er staat geen on duplicate key update bij, wordt de auto-increment waarde alsnog wel met 1 verhoogd.)

Je zegt nu dat de id van het record niet veranderd, maar de sequence van de auto-increment wel wordt verhoogd?

Wat gebeurd er als je een rollback doet van die transactie?

quote:

Op vrijdag 14 juni 2013 21:24 schreef slacker_nl het volgende:

[..]

Je zegt nu dat de id van het record niet veranderd, maar de sequence van de auto-increment wel wordt verhoogd?

Dat zei ik de eerste keer ook. Of althans, dat bedoelde ik.

quote:

Wat gebeurd er als je een rollback doet van die transactie?

Ook dan verandert de sequence van de auto-increment. Eigenlijk ook wel logisch, het terugzetten van de sequence is heel lastig doordat je niet weet wat andere transacties in de tussentijd gedaan hebben.

quote:

Op vrijdag 14 juni 2013 21:28 schreef Light het volgende:

[..]

Dat zei ik de eerste keer ook. Of althans, dat bedoelde ik.

[..]

Ook dan verandert de sequence van de auto-increment. Eigenlijk ook wel logisch, het terugzetten van de sequence is heel lastig doordat je niet weet wat andere transacties in de tussentijd gedaan hebben.

Ahhh. Ik dacht de hele tijd dat men bedoelde dat het ID van de rij aangepast werd. Maar als het een sequence is snap ik het wel ja.

quote:

Op vrijdag 14 juni 2013 21:20 schreef slacker_nl het volgende:

[..]

Dit is wat het doet:
[ code verwijderd ]

Het werkt wel als je
verandert in

Maar ik heb liever leesbaardere code.

Wat is de functie van de {} dan?

quote:

Op vrijdag 14 juni 2013 21:41 schreef slacker_nl het volgende:
Wat is de functie van de {} dan?

Nauwkeuriger aangeven welk stukje van de string als variabele moet worden geinterpreteerd.

In "$foobar" zoekt php naar een variabele $foobar, maar als je "{$foo}bar" of "${foo}bar" schrijft, zoekt php naar de variabele $foo en wordt bar niet als onderdeel van de variabelenaam gezien.

quote:

Op vrijdag 14 juni 2013 21:49 schreef Light het volgende:

[..]

Nauwkeuriger aangeven welk stukje van de string als variabele moet worden geinterpreteerd.

In "$foobar" zoekt php naar een variabele $foobar, maar als je "{$foo}bar" of "${foo}bar" schrijft, zoekt php naar de variabele $foo en wordt bar niet als onderdeel van de variabelenaam gezien.

Aahh, ja, dat ken ik, maar dat het ook op functies werkt.. apart. Dan zou print "{$foo}->bar() ook moeten werken??? Niet dus. Want Foo kan niet naar een string geconvert worden..

quote:

Op vrijdag 14 juni 2013 21:50 schreef slacker_nl het volgende:

[..]

Aahh, ja, dat ken ik, maar dat het ook op functies werkt.. apart. Dan zou print "{$foo}->bar() ook moeten werken??? Niet dus. Want Foo kan niet naar een string geconvert worden..

Hmm... "$foo->bar" werkt wel (als er een property bar bestaat) maar "$foo->bar()" werkt niet (als er een method bar bestaat). Dat klinkt wel onlogisch.

--edit--

--edit--

quote:

Op vrijdag 14 juni 2013 22:01 schreef Light het volgende:

[..]

Hmm... "$foo->bar" werkt wel (als er een property bar bestaat) maar "$foo->bar()" werkt niet (als er een method bar bestaat). Dat klinkt wel onlogisch.

Ik herhaal mijn woorden op irc: PHP is stom

quote:

Op vrijdag 14 juni 2013 22:12 schreef slacker_nl het volgende:

[..]

Ik herhaal mijn woorden op irc: PHP is stom

Nee hoor, mensen die de automatische string-expansion gebruiken zijn stom.

quote:

Op vrijdag 14 juni 2013 22:01 schreef Light het volgende:

[..]

Hmm... "$foo->bar" werkt wel (als er een property bar bestaat) maar "$foo->bar()" werkt niet (als er een method bar bestaat). Dat klinkt wel onlogisch.

http://nl1.php.net/manual(...)types.string.parsing

De "simple syntax" (dat is: zonder gebruik van {}) zoekt niet naar functieaanroepen.

quote:

Op zaterdag 15 juni 2013 10:45 schreef papernote het volgende:
Nee hoor, mensen die de automatische string-expansion gebruiken zijn stom.

Niks mis mee. Zolang het maar duidelijk is. En zonder . al die . stomme . punten . is.

quote:

Op zaterdag 15 juni 2013 10:52 schreef slacker_nl het volgende:

[..]

Niks mis mee. Zolang het maar duidelijk is. En zonder . al die . stomme . punten . is.

Eens dat de punten stom zijn. In elke andere taal die ik beheers zijn het plustekens en bijna altijd als ik terugswitch naar php doe ik het de eerste keer fout...

Maar ik vind het logischer qua taal dat je de variabele buiten de string zet.

quote:

Op zaterdag 15 juni 2013 10:52 schreef slacker_nl het volgende:

[..]

Niks mis mee. Zolang het maar duidelijk is. En zonder . al die . stomme . punten . is.

Zoals je hebt ontdekt zijn er soms wel wat dingen mis mee . En dan vind ik het duidelijker en consistenter om die syntax überhaupt nooit te gebruiken.


Ik prefereer de tweede optie. Helemaal als er HTML output bij komt kijken:

Derde optie:

quote:

Op zaterdag 15 juni 2013 10:56 schreef Maringo het volgende:

[..]

Eens dat de punten stom zijn. In elke andere taal die ik beheers zijn het plustekens en bijna altijd als ik terugswitch naar php doe ik het de eerste keer fout...

Maar ik vind het logischer qua taal dat je de variabele buiten de string zet.
[ code verwijderd ]

Ik vind dat een mindere optie, in dat geval zou ik gewoon (s)printf gebruiken. Als ik code review van mijn collega's krijgen ze het terug als het zo is opgebouwd.

Heeft iemand hier wel eens de i18n library gebruikt voor CodeIgniter?

Ik zit met het volgende lastige probleem:

Ik wil op basis van de url de taal van de pagina aanpassen, door middel van een afkorting van 2 letters:

www.domein.com/en/news/ => engels
www.domein.com/nl/nieuws/ => nederlands
....
You get the idea.

Nu is het zo dat een aantal functies in mijn controllers afhankelijk zijn van de plaats in de url (uri->segment(3) geeft 12 bij www.domein.com/en/news/12). Het probleem is dat als een gebruiker de url www.domein.com/news/12 invoert uri->segment(3) ineens niet meer klopt. Wat kan ik daaraan doen, ofwel hoe maak ik uri->segment() dynamisch?


Hier volgen een aantal dingen die ik al geprobeerd heb:


Wat werkt:
www.domein.nl/news/12
www.domein.nl/nieuws/12

Wat werkt niet (uri->segment() geeft verkeerde stukje url terug):
www.domein.nl/en/news/12
www.domein.nl/nl/nieuws/12

[ Bericht 20% gewijzigd door pascal08 op 15-06-2013 14:22:01 ]

Als uri->segment(3) het derde stukje in je uri teruggeeft, werkt uri->segment(4) in dit geval dan niet? Omdat je uri nu een stukje langer is.

quote:

Op zaterdag 15 juni 2013 18:58 schreef Sitethief het volgende:
Als uri->segment(3) het derde stukje in je uri teruggeeft, werkt uri->segment(4) in dit geval dan niet? Omdat je uri nu een stukje langer is.

Klopt. Dus eigenlijk moet ik een functie maken die het juiste stukje url opzoekt.

Ik ken CI niet zo heel goed, maar ik neem aan dat er een soort router in zit. Met een route pattern zoals in ZF kun je urisegmenten labelen, zodat je niet afhankelijk bent van de volgorde.


Dit lijkt me de mooiste oplossing voor het probleem, maar ik weet niet in hoeverre CI dergelijke patterns toestaat en in hoeverre die gemapped worden richting je controllers.

De regex-patterns die in je post staan zijn onderhoudstechnisch niet zo ideaal. Bij elke nieuwe controller moet je het pattern aanpassen, waardoor het op de lange termijn een complexe regex kan worden.

[edit]
Hmm, CI ondersteunt deze constructie dus niet... dat valt me tegen Er zijn wel snippets in omloop om dit te bewerkstelligen. Er staan oa wat voorbeelden op StackOverflow.

[ Bericht 5% gewijzigd door zoem op 15-06-2013 19:43:31 ]

quote:

Op zaterdag 15 juni 2013 19:28 schreef zoem het volgende:
Ik ken CI niet zo heel goed, maar ik neem aan dat er een soort router in zit. Met een route pattern zoals in ZF kun je urisegmenten labelen, zodat je niet afhankelijk bent van de volgorde.
[ code verwijderd ]

Dit lijkt me de mooiste oplossing voor het probleem, maar ik weet niet in hoeverre CI dergelijke patterns toestaat en in hoeverre die gemapped worden richting je controllers.

De regex-patterns die in je post staan zijn onderhoudstechnisch niet zo ideaal. Bij elke nieuwe controller moet je het pattern aanpassen, waardoor het op de lange termijn een complexe regex kan worden.

Dit is inderdaad een veel mooiere oplossing.

Even een breakdown:

Als ik de URL www.domein.com/news/article/12 invoer, dan gaat de routing voor de functie met uri->segment() bij het renderen van de pagina, neem ik aan. In deze URL geeft uri->segment(1) "news", maar als ik de URL www.domein.com/en/news/article/12 invoer wordt uri->segment(1) ineens "en" en daar raken de functies in de war van.

Ik snap wel welke richting jij op wilt, maar hoe ik daarvan de juiste routes maak weet ik niet. Om het even simpel te houden:

www.domein.com/news/article/12 => *engels*
www.domein.com/en/news/article/12 => *engels*
www.domein.com/nl/nieuws/atrikel/12 => *nederlands*

Welke route moet ik hiervoor aanbrengen in mijn controller?

Ik weet te weinig van de controlflow van CI af om er een concreet antwoord op te geven.

De routepatterns die je nu hebt zouden al iets dynamischer kunnen:
Mooi is anders, maar scheelt het telkens herhalen van de talen bij alle routes.

Misschien heb je hier iets aan: https://github.com/EllisL(...)nationalization-i18n mbt tot het i18n probleem.

quote:

Op zaterdag 15 juni 2013 20:22 schreef zoem het volgende:
Ik weet te weinig van de controlflow van CI af om er een concreet antwoord op te geven.

De routepatterns die je nu hebt zouden al iets dynamischer kunnen:
[ code verwijderd ]

Mooi is anders, maar scheelt het telkens herhalen van de talen bij alle routes.

Misschien heb je hier iets aan: https://github.com/EllisL(...)nationalization-i18n mbt tot het i18n probleem.

Ik zal het zo eens proberen. Bedankt.

quote:

Op zaterdag 15 juni 2013 19:24 schreef pascal08 het volgende:

[..]

Klopt. Dus eigenlijk moet ik een functie maken die het juiste stukje url opzoekt.

Hoe kan het eigenlijk dat je zowel /news/article als /en/news/article kan krijgen? Lijkt mij dat er ergens anders iets niet goed zit dan.

En anders misschien beter om /news/article door te verwijzen naar /en/news/article om zo de consistentie van je urls te behouden.

quote:

Op zaterdag 15 juni 2013 21:13 schreef Maringo het volgende:

[..]

Hoe kan het eigenlijk dat je zowel /news/article als /en/news/article kan krijgen? Lijkt mij dat er ergens anders iets niet goed zit dan.

En anders misschien beter om /news/article door te verwijzen naar /en/news/article om zo de consistentie van je urls te behouden.

Ik heb nog eens goed nagedacht over jullie tips.

Als ik alles laat routen naar een url met de taal voorop, dan blijft uri->segment afhankelijk van wat de gebruiker intypt. Ik zou dus iets moeten doen met redirect of het rewriten van url in .htaccess denk ik. Mijn ervaring met dit soort dingen is nog zeer gering, maar dit lijkt me toch een probleem dat veel developers tegenkomen. Hoe pakken jullie dit aan?

EDIT:

Ik kom er net achter dat uri->segment niet per se nodig is om informatie uit de url te gebruiken voor de functie. Je kunt gewoon een functieparameters instellen die de informatie uit de url haalt. Nu wordt alles een heel stuk makkelijker. Ik ga weer ff verder knoeien.

[ Bericht 18% gewijzigd door pascal08 op 16-06-2013 19:30:23 ]

Previously...

Gisteren ben ik zover gekomen dat ik de taal in de URL werkend heb gekregen. Alle links werden dynamisch opgebouwd met behulp van de ingestelde taal in de config-file van CodeIgniter. Echter liep ik al gelijk tegen het probleem aan dat URL's van ajax requests ook werden veranderd, waardoor URL's niet meer klopten en ik kwam er al snel achter dat dit waarschijnlijk niet de juiste oplossing was.

Ik probeer zoveel mogelijk te lezen over de mogelijkheden van CodeIgniter, maar ik loop toch een beetje vast, omdat ik in grote lijnen niet precies weet wat ik moet doen.

Hoe ik denk dat het zit:

Er zijn 4 mogelijkheden om een taalvoorkeur te kunnen bepalen, namelijk d.m.v:

1. een cookie
2. een sessievariabele
3. de browsertaal
4. een database

Optie 1, 2 en 4 vereisen dat de gebruiker op de site is, of al eens is geweest.
De browsertaal is de enige manier om een voorkeur te kunnen bepalen zonder dat de gebruiker de site al eens heeft gezocht.

Het volgende voor mij een beetje onduidelijk:

Een cookie blijft voor een ingesteld periode op de computer van de gebruiker. Een sessie verloopt (zo heb ik het althans ingesteld) op het moment dat de gebruiker zijn/haar browser sluit. En de database is vanzelfsprekend altijd toegankelijk voor CI. Deze 3 opties zijn dus volgens mij allemaal geschikt om voor CI te bepalen welke taal er ingesteld moet worden.

Ik heb heel wat gegoogeld naar i18n scripts, maar bijna alle scripts gebruiken $config['language'] om de taal in op te slaan en uit te lezen. Mij is het nu onduidelijk wat $config['language'] precies is en wat het doet. Waar wordt deze instelling opgeslagen? Op de computer van de gebruiker, in een geheime database? Ik weet het echt niet.

Wat ik wil bereiken:

Ik wil hetzelfde als YouTube. Is er geen informatie in de vorm van een stukje URL, een sessievariabele, een cookie of wat dan ook? Dan wordt de browsertaal gebruikt.

Bezoekt de gebruiker de site via een URL die een taalvoorkeur bevat? Sla de taal op als sessievariabele (of in een cookie).

Stelt de gebruiker een andere taal in, maar is hij/zij niet ingelogd? Sla de taal op in een cookie.

Is de gebruiker ingelogd en stelt hij/zij een andere taal in? Sla de taal op in de database.

Wat nu nog onduidelijk is:

Hoe gaan de Google-bots hiermee om? Ik kwam namelijk door het googlen naar "browsertaal" erachter dat die bots logischerwijs geen browser gebruiken en dus ook geen browsertaalvoorkeur hebben. Moet ik dus nog een extra scenario toevoegen waarbij er dus helemaal geen informatie is en er wordt teruggevallen op een standaard taal?

Conclusie:

Op deze manier heb ik volgens mij alle mogelijke scenario's gedekt en hoeven de URL's niet per se informatie over de taal te bevatten. Wat ik nu moet doen is de core van CodeIgniter uitbreiden met een class die dus elke keer de juiste vertalingen ophaalt op basis van de taal die de gebruiker heeft ingesteld of de browsertaal.

PS: Ik hoop dat ik deze post zo overzichtelijk mogelijk heb gehouden. Er zitten een hele hoop vragen in verwerkt waar ik waarschijnlijk onmogelijk allemaal antwoord op kan krijgen. De belangrijkste vraag is in ieder geval welke volgorde ik moet aanhouden in het bepalen van de taal (als dit aan de orde is).

quote:

Op maandag 17 juni 2013 17:22 schreef pascal08 het volgende:
Previously...

Gisteren ben ik zover gekomen dat ik de taal in de URL werkend heb gekregen. Alle links werden dynamisch opgebouwd met behulp van de ingestelde taal in de config-file van CodeIgniter. Echter liep ik al gelijk tegen het probleem aan dat URL's van ajax requests ook werden veranderd, waardoor URL's niet meer klopten en ik kwam er al snel achter dat dit waarschijnlijk niet de juiste oplossing was.

Ik probeer zoveel mogelijk te lezen over de mogelijkheden van CodeIgniter, maar ik loop toch een beetje vast, omdat ik in grote lijnen niet precies weet wat ik moet doen.

Hoe ik denk dat het zit:

Er zijn 4 mogelijkheden om een taalvoorkeur te kunnen bepalen, namelijk d.m.v:

1. een cookie
2. een sessievariabele
3. de browsertaal
4. een database

Optie 1, 2 en 4 vereisen dat de gebruiker op de site is, of al eens is geweest.
De browsertaal is de enige manier om een voorkeur te kunnen bepalen zonder dat de gebruiker de site al eens heeft gezocht.

Het volgende voor mij een beetje onduidelijk:

Een cookie blijft voor een ingesteld periode op de computer van de gebruiker. Een sessie verloopt (zo heb ik het althans ingesteld) op het moment dat de gebruiker zijn/haar browser sluit. En de database is vanzelfsprekend altijd toegankelijk voor CI. Deze 3 opties zijn dus volgens mij allemaal geschikt om voor CI te bepalen welke taal er ingesteld moet worden.

Ik heb heel wat gegoogeld naar i18n scripts, maar bijna alle scripts gebruiken $config['language'] om de taal in op te slaan en uit te lezen. Mij is het nu onduidelijk wat $config['language'] precies is en wat het doet. Waar wordt deze instelling opgeslagen? Op de computer van de gebruiker, in een geheime database? Ik weet het echt niet.

Wat ik wil bereiken:

Ik wil hetzelfde als YouTube. Is er geen informatie in de vorm van een stukje URL, een sessievariabele, een cookie of wat dan ook? Dan wordt de browsertaal gebruikt.

Bezoekt de gebruiker de site via een URL die een taalvoorkeur bevat? Sla de taal op als sessievariabele (of in een cookie).

Stelt de gebruiker een andere taal in, maar is hij/zij niet ingelogd? Sla de taal op in een cookie.

Is de gebruiker ingelogd en stelt hij/zij een andere taal in? Sla de taal op in de database.

Wat nu nog onduidelijk is:

Hoe gaan de Google-bots hiermee om? Ik kwam namelijk door het googlen naar "browsertaal" erachter dat die bots logischerwijs geen browser gebruiken en dus ook geen browsertaalvoorkeur hebben. Moet ik dus nog een extra scenario toevoegen waarbij er dus helemaal geen informatie is en er wordt teruggevallen op een standaard taal?

Conclusie:

Op deze manier heb ik volgens mij alle mogelijke scenario's gedekt en hoeven de URL's niet per se informatie over de taal te bevatten. Wat ik nu moet doen is de core van CodeIgniter uitbreiden met een class die dus elke keer de juiste vertalingen ophaalt op basis van de taal die de gebruiker heeft ingesteld of de browsertaal.

PS: Ik hoop dat ik deze post zo overzichtelijk mogelijk heb gehouden. Er zitten een hele hoop vragen in verwerkt waar ik waarschijnlijk onmogelijk allemaal antwoord op kan krijgen. De belangrijkste vraag is in ieder geval welke volgorde ik moet aanhouden in het bepalen van de taal (als dit aan de orde is).

Youtube bekijkt uit welk je land komt dmv IP-adres geloof ik. Via meta-tags kan je aangeven welke taal de GoogleBots moeten gebruiken.

Ik heb een functie die een mysql resultat teruggeeft in een array.

Deze array is als volgt opgebouwd (1 item op dit moment)


Wanneer ik hem probeer te echoën mbt een foreach krijg ik de volgende output:


Ik loop eroverheen met een foreach:


Dit is alleen wanneer ik 1 item heb in de array (alsof hij alleen de eerste tekens laat zien), wanneer er meer items zijn werkt het probleemloos. Kijk ik ergens overheen?

Echo $output. Bij elke loop heeft $output namelijk een ander element uit je array. Dit komt omdat het een platte array is, en niet multidimensionaal.

print_r $res en dat soort grappen, tot hoever ben je zelf al gekomen met debuggen?

Pleur error_reporting(E_ALL); ook eens aan, want $res moet een array zijn waarin arrays zitten met daarin de id => 95, etc.

print_r($output); zou nu de volgende dingen moeten weer geven: 95, nieuwsbericht 1!, eorighreg, nieuwsbericht-1, etc

[ Bericht 61% gewijzigd door Pakspul op 18-06-2013 11:46:07 ]

quote:

Op dinsdag 18 juni 2013 11:40 schreef Pakspul het volgende:
print_r $res en dat soort grappen, tot hoever ben je zelf al gekomen met debuggen?

Pleur error_reporting(E_ALL); ook eens aan, want $res moet een array zijn waarin arrays zitten met daarin de id => 95, etc.

print_r($output); zou nu de volgende dingen moeten weer geven: 95, nieuwsbericht 1!, eorighreg, nieuwsbericht-1, etc

print_r $res geeft wel gewoon dit


Print_r $output zoals op de manier die jij beschrijft. De array bevat 1 item met de juiste dingen die ik wil, het gaan alleen mis in de loop. Die error_reporting(E_ALL) staat aan, de errorlog blijft leeg, dus zijn er geen fouten neem ik aan? Alleen een verkeerde manier van loopen denk ik?

quote:

Op dinsdag 18 juni 2013 13:01 schreef boskameel het volgende:

[..]

print_r $res geeft wel gewoon dit
[ code verwijderd ]

Print_r $output zoals op de manier die jij beschrijft. De array bevat 1 item met de juiste dingen die ik wil, het gaan alleen mis in de loop. Die error_reporting(E_ALL) staat aan, de errorlog blijft leeg, dus zijn er geen fouten neem ik aan? Alleen een verkeerde manier van loopen denk ik?

In dit geval kun je direct echo $res['titel'] doen. Je hebt een foreach nodig als deze item nog in een array zit.

bijvoorbeeld.

Stijlvraagje, eigenlijk taalonafhankelijk. Stel, je hebt een array van 5 groot en je hebt een getal dX die van -1 t/m 5 loopt. -1 moet 4 worden, 5 wordt 0, zodat het een cirkelarray is.

Heeft de gemiddelde programmeur voorkeur tussen deze 2 oplossingen: of

Nogmaals, het gaat om de stijl.

Stukje php-weirdness.

Ik ben wel benieuwd watvoor MySQL-functie je gemaakt hebt dat'ie inconsistent is in de opbouw van de output.

quote:

Op dinsdag 18 juni 2013 13:01 schreef boskameel het volgende:

[..]

print_r $res geeft wel gewoon dit
[ code verwijderd ]

Print_r $output zoals op de manier die jij beschrijft. De array bevat 1 item met de juiste dingen die ik wil, het gaan alleen mis in de loop. Die error_reporting(E_ALL) staat aan, de errorlog blijft leeg, dus zijn er geen fouten neem ik aan? Alleen een verkeerde manier van loopen denk ik?

Geef de gehele php code es vanaf het aanmaken van de query tot en met het uitvoeren van de result set.

Ik gok dat het te maken heeft dat je de array niet declareert. Waardoor die denkt dat het een string is en dus alleen de eerste letter teruggeeft.

quote:

Op dinsdag 18 juni 2013 13:01 schreef boskameel het volgende:
nt_r $res geeft wel gewoon dit

Als $res een 1-dimensionale array teruggeeft zal een foreach loopen over de elementen in die array, de index ['titel'] is er dan niet.

quote:

Op dinsdag 18 juni 2013 13:13 schreef KomtTijd... het volgende:
Stukje php-weirdness.
[ code verwijderd ]

Ik ben wel benieuwd watvoor MySQL-functie je gemaakt hebt dat'ie inconsistent is in de opbouw van de output.

Die laatste levert waarschijnlijk ook een notice op. Maar die wordt standaard genegeerd.

quote:

Op dinsdag 18 juni 2013 13:13 schreef KomtTijd... het volgende:
Stukje php-weirdness.
[ code verwijderd ]

Mijn vermoeden bleek niet te kloppen:

Nog ZF2 gebruikers hier eigenlijk?

quote:

Op dinsdag 18 juni 2013 13:13 schreef KomtTijd... het volgende:
Stukje php-weirdness.
[ code verwijderd ]

Ik ben wel benieuwd watvoor MySQL-functie je gemaakt hebt dat'ie inconsistent is in de opbouw van de output.

Hoewel de uitkomst raar lijkt, is het gedocumenteerd gedrag:

quote:

String conversion to numbers

When a string is evaluated in a numeric context, the resulting value and type are determined as follows.

If the string does not contain any of the characters '.', 'e', or 'E' and the numeric value fits into integer type limits (as defined by PHP_INT_MAX), the string will be evaluated as an integer. In all other cases it will be evaluated as a float.

The value is given by the initial portion of the string. If the string starts with valid numeric data, this will be the value used. Otherwise, the value will be 0 (zero).

Positie 0 bevat dus het karakter 'b'.

Even teruggelezen: dit is dus ook precies waarom boskameel telkens de eerste letter te zien krijgt. Zoals anderen al aangaven wordt de foreach losgelaten op een platte (ééndimensionale) array en niet op een tweedimensionale array.

[ Bericht 3% gewijzigd door zoem op 18-06-2013 21:45:29 ]