Posts by FangorN

    @Tieske *mede* ontwikkeld.


    Wie zegt dat hier niet allang sprake van is?


    Denk aan het schrijven van virussen en remedies hiervoor. Bedrijven die virusscanners verkopen varen hier wel bij.


    /tinfoilhat


    Iemand zijn talent kan op deze manier onderkend worden (als ook echt blijkt dat iemand echt het e.e.a. in zijn mars heeft), maar het was waarschijnlijk nooit de bedoeling van de (mede)maker (onduidelijk is trouwens zijn eigen aandeel in het proces van de creatie hiervan) geweest om gepakt te worden.


    Ook betreft het waarschijnlijk geen ingewikkelde grap waarbij gedupeerden op een zeker moment al hun geld weer terugkrijgen. Het gemaakte programma kon eigenlijk op geen goede manier gebruikt worden, het doel ervan was ook wel min of meer duidelijk.


    Toegegeven, hier is wel sprake van een dubbele moraal zoals in de reacties op het artikel op tweakers wordt aangehaald.


    Maar in zijn algemeenheid, zou jij iemand met een strafblad en een historie van (het schrijven van software voor het) in gijzeling nemen van persoonlijke gegevens voor eigen gewin in een positie plaatsen waarin dit weer kan gebeuren (binnen jouw eigen bedrijf)? Hell. No. Dit zou m.i. nogal naïef zijn, en daarnaast een beloning voor slecht gedrag.


    N.B. er staat nergens in het artikel dat de makers zelf gebruik maakten van het programma en mensen hebben afgeperst. Desalniettemin zou je een voorspelling kunnen doen wat er gebeurt als je zo'n programma te koop zet ...


    Daarnaast, 5 jaar voorwaardelijk, een taakstraf van 500 uur en 40k boete is nogal mild als je dit vergelijkt met zijn maat (die hij heeft verlinkt voor strafvermindering, mogelijk onder enige druk).


    Nee, het moreel kompas van dit individu wijst geenszins naar het noorden.

    @diestro die !important is niet eens nodig? En anders (en wellicht beter) zul je hetzelfde pad moeten gebruiken voor de hover stijl (dus ul:hover > li > a:hover) al staat dat misschien wat vreemd maar als het pad hetzelfde is als de andere default stijl dan hebben ze in ieder geval dezelfde prioriteit lijkt mij.

    @MOnkNL ik denk dat de topicstarter toch meer op zoek is naar een soort van callback of trigger, die (direct) als reactie op een e-mailbericht iets doet. Dus een soort van PUSH (zoals de naam van het topic suggereert :)).


    Dit is iets anders dan op gezette tijden controleren of er mail is (een soort van ping-constructie dus, wat een PULL is).

    Mogelijk weten ze het zo te draaien dat ze gezegd hebben dat ze nooit zomaar op eigen initiatief deze koppeling zullen leggen. Een beetje zoals bij Animal Farm dus.


    Strict genomen heb je nu een keuze. Of de illusie hiervan, want als ze het echt willen, doen ze het toch.

    Het enige wat in principe in jouw geval verschilt van het voorbeeld dat @Robin plaatste is de implementatie van het PHP-bestand dat aangeroepen wordt met een AJAX-call, het principe blijft verder hetzelfde.


    In plaats van dat je daar iets wegschrijft in je database onthoud je het op een andere manier, bijvoorbeeld via een cookie of -wellicht beter- een sessie. Je moet er gewoon op een of andere manier voor zorgen dat je een methode hebt waarmee je informatie over meerdere page-accesses kunt onthouden.


    Je hebt in principe alle puzzelstukjes om het op te lossen. Wil je (toch) dat we het voor je voorkauwen of onderneem je zelf een poging? :)

    Wil je dit doen met of zonder page refreshes?


    En hoe wil je onthouden wat is aangeklikt? En hoe lang wil je dit onthouden? Enkel de page refresh of langer?


    Als je zorgt dat de knoppen in een container zitten (div ofzo) zou je handig van jQuery gebruik kunnen maken in combinatie met selectors en de addClass() (voor het geklikte element) en removeClass() (voor het in 1x verwijderen van een knop-selectie) functies voor het afhandelen van het visuele aspect.

    We redeneren een beetje in cirkels, of we zijn in ieder geval hetzelfde keer op keer aan het herhalen.


    Een ding wat je niet moet doen is voortborduren op een niet al te sterk ontwerp.


    Die invoice_handler.js lijkt mij nogal wollig. Kun je de data van het formulier niet in 1x serialize()n? Vervolgens zijn alle velden arrays (amountoff, job, priceoff, totaal - engels en nederlands door elkaar? meh). Ik weet niet wat het effect is van een trim op een array...


    Long story short: het enige wat je hoeft te doen is:
    - bij het weergeven van prijzen een komma te gebruiken
    - bij het rekenen een punt te gebruiken


    En dit moet op een transparante en nette manier gebeuren, voor de rest moet je nergens aankomen en niets wijzigen want alles zit al in de goede structuur. Als je daarmee gaat rommelen raak je ver van de plek af waar je wilt zijn.


    Wat ik zou doen is wellicht het volgende: wanneer iemand een getal intypt met een komma erin, zou ik deze direct omzetten naar een punt middels JavaScript.


    OF NOG SIMPELER: splits de euro's en de centen en maak dit duidelijk in je formulier, dan hoef je hier helemaal niet meer over na te denken.
    <inputveld voor euro's> , <inputveld voor centen>


    KLAAR!

    Dit klinkt toch een beetje als maatwerk, plus de specificatie kan ook nog wel wat aangescherpt worden :).


    Bijvoorbeeld, wat omvat een tijdslot? Staan deze altijd vast? Zijn er uitzonderingen (zon- en feestdagen / winterstop / etc.)


    Kunnen er meerdere ploegen op een tijdslot ingepland worden? Of is dit per ploeg(type) verschillend? Of is dit wie het snelste is? Claimen zij hiermee ook een resource (ruimte of apparatuur) waardoor andere ploegen mogelijk niet terecht kunnen?


    En de personen (leden) zelf, kunnen zij uitkomen/invallen voor meerdere ploegen, of zijn deze allen aan precies één ploeg gekoppeld?


    Is er ook een sluiting van inschrijving voor een tijdslot, tot wanneer kan iemand zijn inschrijving terugtrekken of (wanneer) is deze "definitief" etc.


    Houd je ook bij wie ook daadwerkelijk is komen opdagen et cetera.


    En zo kan ik nog wel even verder :).

    Maar als die data in een array zit is er toch geen probleem? Pas als je alles op één hoop gooit in een string heb je dit probleem pas?


    Als je een array implode met een komma als "lijm" dan kun je in die string uiteraard geen onderscheid meer maken tussen een komma die al in de invoer zat of die geintroduceerd werd door middel van de "lijm".


    Ik snap ook niet hoe je in eerste instantie dit punt bereikt? Laat eens wat code zien?


    NB: string > array doe je door middel van een explode(), array > string via implode(). In je oorspronkelijke bericht heb je het over $prijs (dat een array bevat?) die je vervolgens weer explode? Ik kan dit niet helemaal plaatsen eerlijk gezegd :/.

    Euh, zowel in PHP en JavaScript is het decimaal scheidingsteken een punt, geen komma. Ik zou daarom dit getal ook niet in zijn geformatteerde formaat (met komma) opslaan, maar in zijn rauwe vorm (een punt) zodat je er out-of-the-box mee kunt rekenen. Volgens mij sla je dan twee vliegen in een klap.


    Vervolgens zul je iets moeten verzinnen om het bedrag weer te geven met euro-teken en komma, maar dat lijkt mij een stuk eenvoudiger.


    Je probleem blijft toch bestaan vrees ik, omdat in beschrijvingen iets soortgelijks kan gebeuren wanneer iemand hier een komma in zet. Het probleem is niet zozeer de komma, maar meer dat je data verder geen enkele betekenis heeft. Wat je ook zou kunnen doen is een ander scheidings teken kiezen zoals een staand streepje (een "pipe" | ) of iets dergelijks maar daar kleeft hetzelfde nadeel aan als iemand besluit dat karakter in zijn invoer te stoppen. Het eruitfilteren van dit karakter lijkt mij ook geen goede aanpak omdat dit "escape on input" is, oftewel, je stript iets op voorhand waarmee mogelijk een speciale betekenis van buiten dit systeem verloren gaat.


    Ik zou het eigenlijk gewoon anders aanpakken zodat je dit probleem nooit krijgt want wat je nu doet of gaat doen is toch min of meer het oorspronkelijke probleem in stand houden en hier omheen breien.


    Om te zien waar je precies "de mist ingaat" zal ik meer code moeten zien maar het klinkt toch een beetje alsof je jezelf klem hebt geprogrammeerd :).

    In welk formaat sla je deze data op? Waarschijnlijk heeft deze data verder geen betekenis? Het is gewoon een plak tekst?


    Heb je niet de beschikking over een database? Dat lijkt mij de beste oplossing. Of je gebruikt een ander formaat om je data gestructureerd op te slaan. Denk aan JSON, CSV, XML, noem het maar op?


    Ik denk dat het probleem voortkomt uit het feit dat je data verder geen betekenis heeft. Machines en hun programmatuur kunnen daar dan verder ook niet goed mee omgaan... zij kunnen simpelweg de verschillende betekenissen van een komma niet onderscheiden...

    Enne, de locatie van waar vandaan je deze service aanroept (of in de toekomst aan gaat roepen) is dezelfde locatie als waar deze service gehost wordt? Ik denk dat dat nogal uitmaakt voor de vraagstelling.


    Mogelijk moet je CORS (Cross-Origin Resource Sharing) support implementeren voor de webservice om "HTTP verbs" anders dan GET te ondersteunen om de cross-domain restricties te versoepelen.


    Ik zou verder niet weten hoe, ik quote ook maar een artikel wat toevallig naar boven kwam met < 5 minuten googlen :).


    Maar ja, als je cross-domain dingen wilt doen moet je meestal wat meer truuks uithalen.

    Je kunt dit natuurlijk nog uitbreiden met meer toeters en bellen als je dat leuk vindt.