Posts by Tredgy

  • Komma niet laten meereken explode

    str_replace(); werkt ook op arrays.. ze worden floats en je kan er mee rekenen.

    PHP
    <?php
$array = array('50,50', '5', '3');
$postTotal = str_replace(',', '.', $array);
var_dump($postTotal);

    Bedoel je dit?

    -------------------------------------------------------------------------------------------------------------------------------------------------------

    Je kan eventueel ook het veld totaal een read-only maken dat word opgeteld door js door aantal * prijs te doen. Zo kan je ook user input mistakes verkomen.

    Je kan dan met JS zorgen dat wanneer aantal/prijs word aangepast door de user door (or $('#id').on('change', function(){}); in jQuery te gebruiken) om het totaal opnieuw te berekenen wanneer een van de velden word bijgewerkt.

  • Website omzetten naar mobiel

    Citaat van Puurhost

    Het makkelijkste is om gebruik te maken van bijvoorbeeld Bootstrap van Twitter. Hier kun je geheel je eigens site omheen bouwen (bekijk mijn site maar als voorbeeld), het is super simpel om te gebruiken en je hoeft het wiel niet opnieuw uit te vinden ;)

    Bootstrap is een goeie manier om dat inderdaad te doen. Puurhost.nl klopt alleen nog niet helemaal op de verschillende resoluties die ik getest heb (buttons,titels, sommigen dingen zijn nog off).

  • Som van alle getallen

    In dit geval is het te simpel om recursive te gebruiken, je zou ook gewoon een while loop kunnen gebruiken dat is voldoende.

    JavaScript
    function recursieveCijferSom ( input ) {
  while ( input.length > 1 ) input = (''+input).split('').reduce( (p,v) => p+~~v , 0 )+'';
  return input;
}


    of

    JavaScript
    function recursieveCijferSom ( input ) {
  do { input = (''+input).split('').reduce( (p,v) => p+~~v , 0 )+''; } while ( input.length > 1 );
  return input;
}

  • Beveiligings vraag

    Jij dus ook niet zul je bedoelen. Als jij als bedrijf dat niet ziet zitten om die om te zetten dat doe jij als bedrijf toch iets fout. Zijn gewoon kosten die je door kan berekenen. Die functies zijn wel deprecated waarom zouden ze anders in PHP7 verwijderd worden.

    Je kan hier nog wat kennis op spijkeren: Why not to use MySQL extension

    Volgens mij heeft TS trouwens genoeg tips gehad om de kwestie op te lossen.

    Als jij dat trouwens als bedrijf niet ziet zitten om dat te doen, mag je ze doorzetten naar mij dan verdien ik er zelf wel wat aan.

  • Beveiligings vraag

    Citaat van MiCa-

    Mee eens hoor ;) Maar client side code tonen / verbergen a.h.v. een variabele noem ik niet persee beveiligen. Je kan als het ware ook zelf de URL invoeren zonder dat je hem kan zien op de website.. Dus het blijft zeer belangerijk om server-side deze toepassingen te gaan beveiligen.

    Overigens zie ik nog heel veel projecten (waar ik help of verbeter) die de oude mysql fncties gebruiken, en ik denk niet dat al die projecten de enige zijn op het web..
    Het is inderdaad ten zeerste aangeraden om over te schakelen naar mysqli of PDO, maar voor heel grote projecten kan dit zeer lastig worden. Deze blijven dan dus ook draaien op een PHP versie die mysql_ nog ondersteunt. ;)

    Maar zowizo vroeg of laat zal het moeten, en dan zullen de meeste telaat zijn zoals gewoonlijk..

    Wat eigenlijk echt een slecht argument is, want die programmeurs (en jij) van die projecten weten donders goed dat die functies deprecated zijn dus ook aan vervanging toe zijn en dat is absoluut niet moeilijk om te doen.

    Zoals @FangorN zei:

    De volgende functies zijn deprecated en verwijderd uit PHP7.

  • Bewerken in Jquery / php dialog werkt niet?

    Citaat van FangorN

    Ik denk dat je het toch anders moet zien. Het antwoord op jouw eerste vraag is waarschijnlijk "nee", vaak is de standaard character encoding nog steeds latin1. Verder lijkt het mij ook onverstandig om uit te gaan van een default, het is veel beter om deze expliciet in te stellen (bijvoorbeeld bij de creatie van de tabel en bij het maken van een connectie).
    Dan misschien handig voor de beeldvorming wat een set_charset() functie doet. Dit moet je zien al een contract tussen jouw applicatie en de database. Dit contract bevat twee bepalingen:
    - jij zorgt ervoor dat alle data die je aanlevert in de overeengekomen character encoding is opgesteld
    - de database zorgt ervoor (of doet in ieder geval een oprechte poging) om alle data die zij teruggeeft aan te leveren in de overeengekomen character encoding

    Dit is dus de "taal" waarmee jullie met elkaar praten, maar dat zegt helemaal niets over welke character encoderingen de tabellen of de data daarin zou moeten hebben en met een set_charset() methode kun je dit ook niet afdwingen omdat dit al is vastlgelegd in de definities van de tabellen zelf.

    Indien jouw website UTF-8 is en jouw database enkel latin1 tabellen bevat kun je dus nog steeds set_charset('utf8') gebruiken: als je iets opvraagt vertaalt MySQL de latin1 data naar utf8 en als je data wegschrijft vertaal MySQL de UTF-8 data naar latin1 (maar dat laatste zal mogelijk niet altijd passen).

    Beschouw set_charset() dus als "de character encoding die je op jouw website wenst te gebruiken". Je moet er dan dus ook zorg voor dragen dat je, als je data wegschrijft naar een database, deze data aanlevert in de overeengekomen character encoding anders gaat het mis.

    Ahzo, dankjewel weer wat geleerd.

  • Bewerken in Jquery / php dialog werkt niet?

    Citaat van FangorN

    Enne, jQuery heeft een standaard functie genaamd serialize() waarmee je automatisch een URL-encoded string kunt bouwen.

    Jouw code gebruikt een langere en omslachtigere methode, en encodeert de waarden op dit moment ook helemaal niet... Als er dus gekke tekens in je data zitten die in de URL-encoded context een speciale betekenis hebben bestaat de kans dat de data-string verkeerd wordt uitgelezen aan de ontvangstkant, met onvolledige/corrupte data als gevolg.

    Ook is het altijd van belang dat al je character encoderingen in de pas lopen, vooral als je via AJAX data doorgeeft, klopt het dat al je data ook UTF-8 geëncodeerd is (en utf8 in MySQL)?

    Het bovenstaande kun je eenvoudig testen door eens wat exotische karakters te voeren aan de database via een AJAX-call, met hier en daar ook karakters als &, >, < en enkele en dubbele quotes. Als alles goed wordt weergegeven na opslaan en er ook weer goed uitziet als je deze data weer wilt gaan bewerken (pas dan heb je een volledig rondje gemaakt) dan heb je je werk goed gedaan. Anders... zet je een stevige pot koffie en los je dit alsnog op :).

    Gebruikt MySQL niet automatisch UTF8 codering? en anders mysqli_set_charset();

    Verder ga ik met hem akkoord.