DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Doe gewoon lekker "/^\w+$/" ben je meteen klaar.quote:Op donderdag 9 oktober 2014 16:27 schreef xaban06 het volgende:
Ik wil met preg_match checken op letters, cijfers en -. Dat doe ik met:
[ code verwijderd ]
Het werkt, maar klopt het ook?
Kom maar konijntje, doe maar wiebelen wiebelen...
En wat moet het precies matchen?quote:
Ik wil met preg_match checken op letters, cijfers en -. Dat doe ik met:
[ code verwijderd ]
Het werkt, maar klopt het ook?
Kom maar konijntje, doe maar wiebelen wiebelen...
Het moet altijd letters en cijfers bevatten, niet hoofdlettergevoelig. Er mag een - voorkomen, maar hoeft niet altijd. Buiten dit mag er niks anders in voorkomen.quote:
[..]
En wat moet het precies matchen?
ik zou nog wel even een \ voor die laatste - zitten. In principe is het zo geldig, maar bijvoorbeeld iets als /^[abcde-jklmn]+$/ matcht niet op a-, /^[abcde\-jklmn]+$/ wel.quote:
Ik wil met preg_match checken op letters, cijfers en -. Dat doe ik met:
[ code verwijderd ]
Het werkt, maar klopt het ook?
Nee, want dan heb je - niet.quote:
[..]
Doe gewoon lekker "/^\w+$/" ben je meteen klaar.
Volkorenbrood: "Geen quotes meer in jullie sigs gaarne."
Het klopt, maar ik zou het [\w-]+ doen, of [[:alnum:]-]+ en misschien zelfs: [\p{Alnum}-] (Unicode).quote:
Ik wil met preg_match checken op letters, cijfers en -. Dat doe ik met:
[ code verwijderd ]
Het werkt, maar klopt het ook?
In theory there is no difference between theory and practice. In practice there is.
quote:
[..]
Het probleem is dat je dan nog steeds vaak dit soort zaken krijgt:
[ code verwijderd ]
Heiden. Shell scriptjes zijn zo geniaal tof vet simpel. Ik zou echt geen PHP willen gebruiken daarvoor. Maar goed, ik schrijf in Perl, dan zit er ook een kronkel in je hoofd.quote:Op donderdag 9 oktober 2014 10:20 schreef KomtTijd... het volgende:
[..]als er iets aids is... Ik heb PHP op mijn router geïnstalleerd om niet te hoeven bashen.
In theory there is no difference between theory and practice. In practice there is.
Maar underscore zit toch ook in \w ?quote:
[..]
Het klopt, maar ik zou het [\w-]+ doen, of [[:alnum:]-]+ en misschien zelfs: [\p{Alnum}-] (Unicode).
Frameworks zijn handig, echter als je een framework zomaar gebruikt zonder de onderliggende basis te kennen is het vragen om problemen, zie je veel met JQuery, mensen zien vaak niet in dat je onderliggend gewoon DOM transformaties aan het doen bent, vandaar dat performance vaak dramatisch wordquote:
[..]
Met al die frameworks tegenwoordig zal dat wel meevallen toch?
Hoe dan ook: liever iemand die goede procedurele code schrijft, dan iemand die maar wat aanrommelt met objecten.
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
Een bijverschijnsel is dat je het 100x meldt?quote:
[..]
Heiden. Shell scriptjes zijn zo geniaal tof vet simpel. Ik zou echt geen PHP willen gebruiken daarvoor. Maar goed, ik schrijf in Perl, dan zit er ook een kronkel in je hoofd.
Ja. Maar daarom de POSIX alnum en/of unicode variant.quote:
[..]
Maar underscore zit toch ook in \w ?
En ik schrijf Perl.
In theory there is no difference between theory and practice. In practice there is.
Scheer je weg uit het PHP-topic.quote:
[..]
Heiden. Shell scriptjes zijn zo geniaal tof vet simpel. Ik zou echt geen PHP willen gebruiken daarvoor. Maar goed, ik schrijf in Perl, dan zit er ook een kronkel in je hoofd.
| 1 | number_format(100/$bar->foo, 1); |
Hij lijkt de decimalen te negeren van $bar->foo.
Als $bar->foo bijvoorbeeld 3.4 is krijg ik als resultaat 33.3, hij rond de 3.4 dus af naar 3 voordat hij rekent.
Hoe komt dat en hoe op te lossen?
/edit
Nevermind, opgelost. Moest er een string van maken
Code die hier staat geeft bij mij gewoon direct 29.4 hoor.quote:
[ code verwijderd ]
Hij lijkt de decimalen te negeren van $bar->foo.
Als $bar->foo bijvoorbeeld 3.4 is krijg ik als resultaat 33.3, hij rond de 3.4 dus af naar 3 voordat hij rekent.
Hoe komt dat en hoe op te lossen?
/edit
Nevermind, opgelost. Moest er een string van maken
Wel wel mogelijk is dat bij jou de typecasting wat nukkig deed. (100 zag hij dan als int, waardoor hij besloot om de (string??) van 3.4, ook te casten naar een int. wat 3 geeft. Oplossing daarvoor was dan om aan te geven dat 100 een float is door er 100f van te maken.
Het grote nadeel van de dynamische typecasting van php. Is gewoon alles defineren als int, float, string etc toch handiger
[ Bericht 8% gewijzigd door #ANONIEM op 10-10-2014 02:24:56 ]
Een van de weinige bedrijven waar nog het een en ander met Perl gedaan wordt, denk ik.quote:Op woensdag 8 oktober 2014 17:04 schreef slacker_nl het volgende:
[..]
Klopt. Op mijn werk is het Perl en JS (angular) wat de klok slaat.
Valt mee. Krijg geregeld aanbiedingen van head hunters/recruiters.quote:
[..]
Een van de weinige bedrijven waar nog het een en ander met Perl gedaan wordt, denk ik.
In theory there is no difference between theory and practice. In practice there is.
| 1 2 3 | <?php date_format(new DateTime($test->datum), 'd F Y'); ?> |
Wordt weergegeven als: 27 January 2014
Dit wil ik vertalen naar het Nederlands, dus: 27 januari 2014
Volgens mij moet dit met setlocale(LC_TIME, "nl_NL"); + strftime();
Ik kom er echter niet uit om strftime(); te gebruiken zonder een extra regel hoeven te gebruiken. Of ontkom ik daar niet aan?
[ Bericht 0% gewijzigd door xaban06 op 11-10-2014 07:38:13 ]
quote:
[ code verwijderd ]
Wordt weergegeven als: 27 January 2014
Dit wil ik vertalen naar het Nederlands, dus: 27 januari 2014
Volgens mij moet dit met setlocale(LC_TIME, "nl_NL"); + strftime();
Ik kom er echter niet uit om strftime(); te gebruiken zonder een extra regel hoeven te gebruiken. Of ontkom ik daar niet aan?
| 1 2 3 4 5 6 7 8 9 10 | date_default_timezone_set("Europe/Amsterdam"); # Ik zet alles om naar NL, jij alleen je tijd. Pick any. setlocale(LC_ALL, array( 'nl_NL.utf8', 'nl_NL@euro', 'nl_NL.iso885915@euro', 'nl_NL.iso88591', 'nl_NL', 'POSIX', )); |
| 1 2 | setlocale(LC_TIME, "de_DE"); //only necessary if the locale isn't already set $formatted_time = strftime("%a %e.%l.%Y", $mytime->getTimestamp()) |
[ Bericht 16% gewijzigd door slacker_nl op 11-10-2014 09:47:44 ]
In theory there is no difference between theory and practice. In practice there is.
Volgens mij ben ik onduidelijk geweest met mijn vraagquote:
Dit wordt in het Engels weergegeven:
| 1 2 3 | <?php date_format(new DateTime($test->datum), 'd F Y'); ?> |
Dat wil ik in het Nederlands, daarvoor moet ik functie strftime(); gebruiken, maar krijg het niet helemaal geimplementeerd. Of ik moet met extra regels en $vars werken.
Deze is beter: http://nl1.php.net/intldateformatter.setpattern
In theory there is no difference between theory and practice. In practice there is.
Dat zou ik die strtotime weglaten en gelijk $test->datum->getTimestamp doen.quote:
In theory there is no difference between theory and practice. In practice there is.
Mijn website wordt op het moment zo opgebouwd (index.php):
- include controller.php (deze checkt in de URI welke pagina geladen moet worden en slaat dit op als $show == "blog" of $show == "contact".)
- include "inc/header-html.php";
- if ($show == "blog") { include "inc/blog.php"; }
- if ($show == "contact") { include "inc/contact.php"; }
- include "inc/footer-html.php";
Het probleem hierbij is dat de <meta> en <title> altijd hetzelfde is, omdat ik in blog.php/contact.php pas weet welke data er getoond zal worden, terwijl de <meta>/<title> in "inc/header-html.php" zit.
Dit dacht ik op te lossen door mijn index.php aan te passen naar:
- include functions.php
- include controller.php (deze checkt in de URI welke pagina geladen moet worden en slaat dit op als $show == "blog" or $show == "contact")
- if ($show == "blog") { include "inc/blog.php"; }
- if ($show == "contact") { include "inc/contact.php"; }
Het verschil zit hem in dat de header-html.php wordt geladen in blog.php/contact.php.
functions.php:
En in blog.php/contact.php heb ik dan:
// hoop php script, waar ik dus ook gelijk <meta>/<title> definieer en onderaan heb ik dan:
showPage("blog-html.php");
De HTML wordt netjes opgebouwd, maar veel $vars/$objects worden genegeerd. Heeft dat te maken met de functie die ik gebruik? Kan je geen bestanden includen binnen een functie oid?
- include controller.php (deze checkt in de URI welke pagina geladen moet worden en slaat dit op als $show == "blog" of $show == "contact".)
- include "inc/header-html.php";
- if ($show == "blog") { include "inc/blog.php"; }
- if ($show == "contact") { include "inc/contact.php"; }
- include "inc/footer-html.php";
Het probleem hierbij is dat de <meta> en <title> altijd hetzelfde is, omdat ik in blog.php/contact.php pas weet welke data er getoond zal worden, terwijl de <meta>/<title> in "inc/header-html.php" zit.
Dit dacht ik op te lossen door mijn index.php aan te passen naar:
- include functions.php
- include controller.php (deze checkt in de URI welke pagina geladen moet worden en slaat dit op als $show == "blog" or $show == "contact")
- if ($show == "blog") { include "inc/blog.php"; }
- if ($show == "contact") { include "inc/contact.php"; }
Het verschil zit hem in dat de header-html.php wordt geladen in blog.php/contact.php.
functions.php:
| 1 2 3 4 5 6 7 8 9 10 11 | <?php function showPage($page) { $inc = "inc/"; include $inc .'header-html.php'; include $inc ."$page"; include $inc .'footer-html.php'; } ?> |
// hoop php script, waar ik dus ook gelijk <meta>/<title> definieer en onderaan heb ik dan:
showPage("blog-html.php");
De HTML wordt netjes opgebouwd, maar veel $vars/$objects worden genegeerd. Heeft dat te maken met de functie die ik gebruik? Kan je geen bestanden includen binnen een functie oid?
Zie http://php.net/manual/en/function.include.php en http://php.net/manual/en/language.variables.scope.php
Als je include aanroept, dan heb je in het geïncludeerde bestand de beschikking over de variablen die binnen scope vallen op de regel van de include. Dus in jouw geval: alle variabelen die binnen de functie showPage beschikbaar zijn. Daar vallen variabelen uit blog.php/contact.php waarschijnlijk niet onder.
Overigens kun je jouw probleem wellicht beter oplossen middels output buffering. Voorbeeld:
Als je include aanroept, dan heb je in het geïncludeerde bestand de beschikking over de variablen die binnen scope vallen op de regel van de include. Dus in jouw geval: alle variabelen die binnen de functie showPage beschikbaar zijn. Daar vallen variabelen uit blog.php/contact.php waarschijnlijk niet onder.
Overigens kun je jouw probleem wellicht beter oplossen middels output buffering. Voorbeeld:
| 1 2 3 4 5 6 7 8 9 | <?php ob_start(); include 'blog.php'; // Zet ook de meta/title objecten $content = ob_get_clean(); include 'header-html.php'; echo $content; include 'footer-html.php'; ?> |
Schuimpje... mijn liefste. Verlaat mij nimmer weer...
Als ik het goed begrijp alles wat tussen ob_start(); en ob_get_clean(); staat wordt niet verzonden, maar vastgehouden in een buffer? Tot dat je het zelf echo'd? Maar je kan de data die worden genereerd in je buffer wel gewoon gebruiken zonder te verzenden?quote:Op zondag 12 oktober 2014 13:54 schreef papernote het volgende:
Zie http://php.net/manual/en/function.include.php en http://php.net/manual/en/language.variables.scope.php
Als je include aanroept, dan heb je in het geïncludeerde bestand de beschikking over de variablen die binnen scope vallen op de regel van de include. Dus in jouw geval: alle variabelen die binnen de functie showPage beschikbaar zijn. Daar vallen variabelen uit blog.php/contact.php waarschijnlijk niet onder.
Overigens kun je jouw probleem wellicht beter oplossen middels output buffering. Voorbeeld:
[ code verwijderd ]
Ben een vrij rookie met php en nog nooit output buffering gebruikt.
Correct. Alle php-code tussen ob_start en ob_get_clean wordt uitgevoerd, maar de output wordt gebufferd (in het voorbeeld sla ik het op in $content).
Als je dus in blog.php iets doet als: $meta = "lalala"; $title = "lololo"; , dan kun je dat verderop gebruiken.
Als je dus in blog.php iets doet als: $meta = "lalala"; $title = "lololo"; , dan kun je dat verderop gebruiken.
Schuimpje... mijn liefste. Verlaat mij nimmer weer...
Maar om dit soort problemen te voorkomen hebben we toch templating engines?
In theory there is no difference between theory and practice. In practice there is.
Geen ervaring mee. Ik doe het in mijn vrije tijd en helaas te weinig tijd om het allemaal te leren.quote:
Maar om dit soort problemen te voorkomen hebben we toch templating engines?
Juist als je er weinig tijd in wil steken zou ik gebruik maken van bestaande systemen dan zelf iets in elkaar te gaan rommelen.quote:
[..]
Geen ervaring mee. Ik doe het in mijn vrije tijd en helaas te weinig tijd om het allemaal te leren.
