Beiträge von cottton

    Zum Video:
    "traurig" - ist das erste, was mir in den Kopf kam.

    Website und Video ist grau in grau.
    Die Hintergrundmusik vermittelt den Eindruck einer Mischung aus Singlebörse und Cocktailbar :D
    Das (text to speech) gesprochene klingt nach "mit dem Headset aufgenommen" =)
    Und auch wenn Youtube groß ist, macht es keinen so guten Eindruck, wenn das Video im Youtubeplayer abgespielt wird.

    Keine Vorwürfe, alles nur Tipps =)

    Als erstes würde ich das Video selbst hosten - auf den Server hinterlegen und per HTML5 player abspielen.
    Dann das Design ändern. Ich meine nicht den Aufbau - eher die Farben.
    Anhand der fertigen, ansprechenden Seite kann man dann ein passendes Video erstellen.

    Der Inhalt sollte dann gesprochen sein (kein text to speech) und sich durch Text ergänzen.
    Denn wenn da schon ein Video ist - warum sollte es nur Text anzeigen, wo der doch auch auf der Seite stehen könnte =)
    Bei der Hintergrundmusik muss man "probieren".

    So, und jetzt gibt mal was für frischen Fasching im Kopf!
    =)

    Was is das:
    Eine Klasse "CallBack" als Hauptklasse, welche die Functionen für eine Callback-Funktion bereit stellt.
    Eine Andere Klasse kann also sich selbst um diese Klasse (und ihre Methoden) erweitern.

    Sinn dahinter:
    dynamisches arbeiten mit Klassen (weniger stumpfe Skriptabläufe).
    Die "Eine" Klasse fragt einfach bei der "Anderen" nach, ob sie denn schon bereit ist.
    Ist das nicht der Fall, wird diese "Eine" Klasse zurückgerufen, sobald die "Andere" Klasse ihr "ok" gibt (also bereit ist).
    Momentan nur mit/für static Methoden getestet/gedacht. Bin zwar grad nicht wirklich frisch, aber sollte überall laufen.

    Hier das Bsp/der Code (sieht schlimm aus, aber ist es eigtl gar nicht =)

    EDIT: Methoden der Klasse "CallBack" mit "final" versehen. Dadurch ist es einer Kindklasse nicht möglich diese zu überschreiben.
    Ohne dem Zusatz "final" könnte man in einer Kindklasse auch eine Methode execRegistered() erstellen.
    Bei einem "versehentlichen" Aufrufen per self::execRegistered(); (also self andstatt parent) würde man die eigene Methode anstoßen.
    Mit "final" ist es also einer Kindklasse nicht mehr möglich eine Methode mit diesen Namen zu erstellen.

    Zitat

    Fatal error: Cannot override final method CallBack::execRegistered() in ...

    falls es mal jemand braucht:


    sehr einfach (eigtl), aber nützlich.
    Hätte mir bei PHP ein 3ten parameter für implode() gewünscht.
    Also implode('trenner',$array,true) -- wobei true dann halt die keys beachtet/sortiert.

    Ersteres versteh ich net ganz.
    Willst Du die config gesondert ablegen?
    Dann müsste das file zuerst eingebunden werden, oder im alert File evtl ne Prüfung, ob die config schon geladen wurde/existiert.
    zB


    zum 2.; einzigste was mir einfällt

    JavaScript
    var s = box[i]["elem"].style;
        s.top = "-200px";
        s.opacity = 0;
        s.lineheight = "0px";
        s.padding = 0;
        s.minHeight = "0px";
        s.maxHeight = "0px";

    Du meinst wenn 2 boxen auf sind, und eine davon ausgeblendet wird => dass die übrige nach oben "flutscht"?

    Hmm, ... liegt ja daran, dass das element nicht mehr nach oben verschwindet, sondern nur noch opacity auf 0 geht und dann aus dem DOM gelöscht wird.
    Dann müsstest Du evtl die Höhe der auszublendenen box verringern. Also height:0px. Mit transition dürfte das animiert werden und flutscht nicht mehr :D

    sowas gefällt mir =)
    sorry, hab mich bissl verspielt, aber macht echt spass :D
    => http://jsfiddle.net/6mhHL/1/

    der (mMn) Grund warum da was durcheinander gekommen ist, ist, weil Du mit setTimeout i als String gegeben hast.
    Dadurch wurde immer das aktuelle i genutzt, das ja schon wieder durch ein neues alert hochgezählt sein konnte.
    Durch setTimeout(function ... kannst Du das "echte"(?) i übergeben.

    Tipp: immer debug function schreiben/nutzen und wenn Du Werte, also wie zB Timeoutzeit, nutzt dann immer oben in ner config definieren. Das macht das ändern/anpassen sehr viel einfacher.

    Will mal hier nen thread starten, bei dem es einfach nur darum geht darüber zu Diskutieren,
    ob man was richtig verstanden hat, oder halt nicht.
    Gerade bei OOP in Sachen Vererbung kann man schnell mal den Überblick verlieren.

    Hier mal interessant, dass Konstanten (auch Funktionen und Eigenschaften) geerbt werden können,
    aber dennoch jede Klasse seine eigene Variante mit dem exakt gleichen Namen haben kann:


    Jemand btw ne Idee, wie man aus der dritten Klasse die Konstante der Ersten ansprechen könnte?
    Also Ohne den Namen (Mensch::) dabei zu nutzen?

    Wer endlich der Weiterleitungs-Wut bei abgesendeten Formularen entkommen will:
    (ich hab nie verstanden, warum das so Weiterleiten weit verbreitet ist)

    Was passiert hier?
    Steht in den comments.
    Kurz: es ist (bei richtiger Anwendung) nicht möglich per F5 eine Form mehr als einmal anzusenden.
    Keine "noobigen" Weiterleitungen mehr.
    Ist immernoch ausbaufähig

    Es gibt wohl einen Bug in php @PDO::beginTransaction() and PDO::commit()
    ist aber noch nicht offiziell.

    Wenn ihr PDO::beginTransaction() and PDO::commit() nutzt
    dann schreibt keine Kommentare (-- comment ...) nach dem ; (Semikolon) der SQL-Query.

    Multi-Queries sind wohl nicht erlaubt/vorgesehen bei PDO.
    Heißt: "INSERT INTO ...; INSERT INTO ...; INSERT INTO ...;" darf/geht nicht.
    Es wird sicherlich mit ner regexp der übergebene String behandelt und dabei geht "was durcheinander".
    Denn auch Kommentare nach dem ; (Semikolon) sorgen dafür, dass die Daten nicht beim Sql-Server ankommen.


    Der Bugreport: https://bugs.php.net/bug.php?id=66621

    Also Kommentare immer schön in der Query schreiben. Nicht nach dem ;
    =)

    Kommt auf die Umstände an.
    Wenn Du 100% sicher sein kannst, dass alle Array-Keys auch als Datenbankspalte existieren,
    dann könntest Du:
    1. das Array nutzen, um die Query dynamisch zu erstellen
    oder
    2. das Array in eine fest geschriebene Query als Parameter-Array reinschicken (->execute([parameter]))

    zu 1. dynamisch (allerdings mit whitelist! denn wir wollen keine injections =)

    zu 2.
    Du bekommst beim laden (SELECT ...) die Spalten als Array-Keys.
    Dadurch müssen beim speichern (UPDATE...) die Keys auch wieder als Spalte funktionieren, WENN das Array nicht manipuliert wird(/werden kann).
    Irgendwo hast Du dann eine Funktion/Methode mit der fest geschriebenen Query stehen, und schickst das Array wieder als Parameter rein.

    Zwecks bots:
    ich vermute, dass bots generell keine selbstgeschriebenen Logins angehen. Dabei kommt es wohl auf die Form und die url an.
    Ich bin seit Jahren mit unserer Seite im Netz und habe nicht einen bot erlebt (nutze kein captcha o.ä.).
    Ein bot muss ja geschrieben werden (logisch). Und die werden sicherlich relativ dynamisch auf die bekanntesten Loginsysteme (wie zB hier das Burning Board) geschrieben.

    Igendwie kommt mir hier was komisch vor.
    Du fragst nach insert oder update, hast aber Tabellen mit foreign keys (fk?) und joinst an Tabellen ran, was ja schon in Sachen SQL fortgeschritten ist?
    Kein Vorwurf, nur ungewöhnlich.

    Zum Thema:
    Wenn der Datensatz, also der Benutzer, schon existiert, dann UPDATE SET ... .
    Wenn er noch nicht existiert, dann INSERT INTO ... .

    Um nicht vorher prüfen zu müssen, ob der Benutzer schon existiert, kannst Du auch


    Vorraussetzung für ON DUPLICATE KEY UPDATE ist, dass die idkunde einzigartig ist. Also vom INDEX typ UNIQUE, oder PRIMARY KEY (= unique).

    ON DUPLICATE KEY UPDATE heißt:
    wenn ein Schlüssel schon existiert, dann update ...

    ... ich sehe gerade The Scout hat ja auch schon was geschrieben :D
    ... bin bissl langsam heute :p

    Das ursprüngliche "Undifined index..." kam wohl als Du den Submitbutton geprüft hast:

    PHP
    if ($_POST["submit"] == "registrieren") {
    
    
    
    
    }


    Zur erklärung - da ich denke Du weißt nicht woher/warum die Meldung kommt:
    wird die Seite frisch aufgerufen, also kein Submitbutton abgesendet,
    dann ist $_POST["submit"] nicht gesetzt - also nicht definiert (undefined index "submit").
    Beim ersten Absenden des Formulars über den Submitbutton ist $_POST["submit"] gesetzt.

    $_POST[...] ist (sehr) einfach gesagt das, was vom Browser kommt.

    Wie prüft man, ob etwas gesetzt ist: mit isset()

    PHP
    if (isset($_POST["submit"]) and $_POST["submit"] == "registrieren")


    wobei

    PHP
    if (isset($_POST["submit"]))


    auch schon reicht, da man beim Submitbutton egtl nur wissen will, ob er gedrückt wurde, oder nicht.

    samma, was geht denn jetz ab: *ratter ratter* *tuuut*
    evtl noch *möööpmöööp*
    :D

    EDIT: wenn ich das richtig verstehe, dann würde ich besser:

    Code
    php $_GET['id'] = $_GET['id']


    falls $_GET['id'] sonst verloren gehen würde.
    Grund: mMn sollten vars nicht einfach so definiert werden, sondern immer nachvollziehbar in den scripten