Beiträge von SinnlosS

    Ich finde JOIN in der Schreibweise einfach übersichtlicher, und outer joins kann man glaub auch anders nur sehr umständlich oder mit mehreren Abfragen realisieren.
    Mal ne Beispiel-Abfrage in nem Projekt von mir, die sähe ohne JOINs glaub wesentlich unübersichtlicher aus, sofern es sich überhaupt realisieren ließe:

    Jo, das nennt man auch PDO. :D
    Oder was meinste?


    Ich muß ehrlich gestehen, ich habe mich noch nie mit PDO beschäftigt :D

    Ich nutze halt die mysqli-Extension von php objektorieniert mit den Standard-Funktionen für prepared Statement, z.B.:

    Ka wie das bei PDO aussieht. ^^

    Du überprüfst nur ob irgendwo in $datum eine korrekte Datumssyntax ist. Wenn diese gefunden wird kann davor und dahinter noch soviel anderer kram stehen wie man will.
    Du mußt Zeilenanfang ^ und Zeilenende $ markieren:

    PHP
    if (!ereg ("^([0-9]{1,2})\.([0-9]{1,2})\.([0-9]{4})$", $datum, $regs))
    {echo "Datumsformat nicht korrekt!";
    }
    else
    {echo "Datumsformat korrekt!";
    }

    Ist der Rat jetzt speziell auf mein Problem bezogen, oder hat es generell Vorteile display statt visibility zu verwenden?

    Mein Problem habe ich gerade eben erstmal gelöst, in dem ich eine id='auftragsdaten_overflow' für den entsprechenden div vergeben habe, und die javascript-funktionen um folgendermaßen erweitert habe:

    Code
    document.getElementById(Form+'_overflow').style.overflow="";
    
    
    bzw.
    
    
    document.getElementById(Form+'_overflow').style.overflow="auto";

    removeAttribute("overflow",auto) auf den div-bereich hatte nicht funktioniert.

    Ich habe ein kleines Problem und da ich in Sachen css nicht so der crack bin.

    Ich habe eine Übersicht in der ich mir Auftragsdaten anzeigen lasse.
    Für einen Beschreibungstext habe ich jetzt für den div-bereich die css-eigenschaft overflow auf 'auto' gesetzt und eine feste größe definiert.
    Hinter den angezeigten Daten liegt ein Formular um eben diese Daten zu bearbeiten. Per JS kann man jetzt auf Knopfdruck auf das Formular wechseln und wieder zurück.
    Das habe ich mir einfach gemacht und die Anzeige in einen div-bereich gelegt und das Formular hinterher in einen zweiten div-bereich. Das Formular steht default auf visibility:collapse, der div-bereich für die Anzeige auf visibility:visible.
    Über JS wird die visibility eben geswitcht.
    Seit ich jetzt aber in dem div-bereich zur Anzeige ein div-element auf overflow:auto gesetzt habe wird mir die Fläche für dieses div beim switch auf das Formular als schwarzer Kasten dargestellt. Die Textarea ist also überdeckt. Das ist nicht so schön.

    hier nur mal ganz grob der aufbau:

    Code
    function ShowForm(Form) {
        document.getElementById(Form).style.visibility="collapse";
        document.getElementById(Form+'_form').style.visibility="visible";
    }
    function ShowData(Data) {
        document.getElementById(Data).style.visibility="visible";
        document.getElementById(Data+'_form').style.visibility="collapse";
    }

    Hat irgendjemand einen Ansatz wie ich es hinkriege, dass ich das overflow-Attribut beibehalte, aber trotzdem beim Formular den schwarzen Kasten für das entsprechende div wegbekomme?
    Ich habe schon probiert für das entsprechende div in der javascript-funktion den wert für overflow zu ändern, bringt aber auch nix. Kann ich irgendwie per js das overflow attribut komplett entfernen statt nur den wert zu ändern, und dann beim zurückswitchen halt wieder einfügen?

    Für irgendwelche Ansätze oder Denkanstöße wäre ich dankbar.

    Hoffe mal das ist hier richtig, es geht ja im Prinzip schon um css-eigenschaften, nicht um js.

    Ist leider doch noch nicht fertig geworden, Schwesterchen war über Pfingsten zu Besuch und ich war die meiste Zeit unterwegs.
    Wird aber im Laufe dieser Woche auf jedenfall was.

    Ich poste grad mal den aktuellen Zwischenstand, vielleicht fallen jemandem beim rüberschauen Anregungen ein.
    Die Klasse eventCalendar ist noch nicht komplett durchgetestet, wenn die vorerst endgültige Version kommt werde ich das hier auch wieder rauseditieren. Beschreibung der Methoden kommt auch dann.

    class.calendar.php

    class.eventCalendar.php


    @No0ob

    ach das sollte eigentlich auch ein unterstrich sein, danke !


    Aha, hast du es dann auch mal mit nem Unterstrich statt nem Bindestrich getestet? Beim mir kommt exakt deine Fehlermeldung wenn ich den Bindestrich nehme, mit Unterstrich kommt sie nicht mehr.
    Teste doch bitte die Tipps hier auch mal aus und poste die Ergebnisse.


    Das schmeißt den Fehler:

    Zitat

    Parse error: parse error, expecting `'('' in E:\Programme\wamp\www\tbt\test.php on line 4


    Line 4 ist die Funktionsdeklaration.


    Das hier schmeißt keinen fehler mehr:

    Ja bei diesen "Feinheiten" bin ich momentan noch am rumprobieren.
    Bei der Tochterklasse terminKalender, an der ich noch am feilen bin, gibt es funktionen zur Erstellung eines Kalenderblattes für einen Monat oder für ein Jahr.
    Ich bin noch am überlegen inwieweit es vllt. auch nötig/sinnvoll wäre, ein Start- und Enddatum für den Kalender anzugeben.
    Naja, und noch ein paar andere Kleinigkeiten.

    Ich werd vermutlich am WE erstmal eine lauffähige Version für einen Terminkalender posten und dann gegebenenfalls auf Anregungen hin noch anpassen. Die bisher gepostete calendar-Klasse wurde in Kleinigkeiten auch noch überarbeitet.

    Die terminKalender-Klasse wird vorerst nutzbar sein mit mysql oder mysqli.

    EVA-Prinzip einzuhalten ist immer gut (Eingabe - Verarbeitung - Ausgabe).
    Du kannst erstmal aus den aufrufenden Parameter der Seite mit php deine dynamischen Inhalte generieren. Statt sie aber auszugeben speicherst du sie in Variablen.
    Wenn die Verarbeitung komplett durchlaufen ist kommt dein html-gerüst, da gibst du an den entsprechenden stellen mit php nur noch deine Variablen aus.

    Übrigens ein sehr gutes Tutorial für oop mit php5:
    http://www.peterkropff.de/site/php/oop.htm


    Trotzdem nochmal die Frage:
    Muss der header unter allen Umständen weiter nach oben vor den Ausgaben oder kann der dann auch da unten stehen bleiben, wenn es so funktioniert? Ich meine..klar könnte er das - aber ist das mehr Glück als Verstand, daß es geht oder macht es nix und kann so bleiben?


    Du mußt mal den Unterschied zwischen Code und Ausgabe erkennen.
    Alles was zwischen <?php und ?> steht ist erstmal noch keine Ausgabe, das ist einfach der Teil der Datei, der auf dem Server geparsed wird, bevor die Datei an den Client geschickt wird. D.h. solange du nicht mit php explizit Ausgaben erzeugst und solange dein Code so sauber ist, dass keine Fehler oder Notices geschmissen werden, kannst du vor dem header()-Aufruf soviel Code stehen haben wie du willst.
    Es dürfen außerhalb des <?php ?> Bereichs vor der Stelle wo header() aufgerufen wird keine Zeichen jeglicher Art stehen, keine html-tags, keine Leerzeichen, keine Leerzeilen.
    Das wars.
    Bei dir den header() weiter oben zu setzen würde ja auch keinen Sinn machen. Es soll ja erst weitergeleitet werden wenn die email verschickt wurde.

    Notice: Undefined index: Name in /home/u0088629688/public_html/Kontakt2.php on line 7

    Notice: Undefined index: Email in /home/u0088629688/public_html/Kontakt2.php on line 7


    Das sind die Ausgaben die den Fehler beim header() auslösen, genau.
    Ändere diese Zeile:

    PHP
    $strFrom       = "$_POST[Name] <$_POST[Email]>";

    in:

    PHP
    $strFrom = isset($_POST['Name']) && isset($_POST['Email']) && !empty($_POST['Name']) && !empty($_POST['Email'])
        ?
        "{$_POST['Name']} <{$_POST['Email']}>"
        :
        "";

    Damit fragst du erstmal ab, ob die Variablen überhaupt gesetzt sind. Sollte dies nicht der Fall sein verwendest du sie gar nicht erst.
    Wenn du nämlich in deinem Script Variablen verwenden willst die nicht gesetzt sind schmeißt php eben ein Notice wie du sie da hast. Und das ist auch eine Ausgabe.

    Ich glaube das wurde dir aber auch schon auf der ersten Seite geschrieben, wenn mich grad nicht alles täuscht.

    Edit: Achso, es fehlten auch die ' ' um deine $_POST-Keys. ('Name' und 'Email')

    Yo, ich wollte die Klasse halt möglichst abstrakt und universell nutzbar machen, die Einbindung einer db-nutzung ist ja dann abhängig von den tabellen aus denen die termine gezogen werden.
    Dafür werde ich aber auch noch eine Tochterklasse schreiben, als Terminkalender mit vorgefertigter Tabellenstruktur.
    Momentan werden da Termine noch gar nicht gespeichert, die können halt über addDate() aus beliebigen Quellen eingefügt werden.

    Das bisherige ist halt was was ich jetzt mehr oder weniger schnelle eben runtergeschrieben habe, daher auch die Frage nach weiteren Vorschlägen. Vernünftiges Error-Handling will ich da auch noch implementieren.

    Er sagt dir ja genau was falsch ist: Warning: Cannot modify header information - headers already sent

    Vor dem header()-Befehl darf keine Ausgabe an den Browser kommen, auch kein Space oder eine Leerzeile.
    Ein Problem das ich früher schonmal hatte, war, dass ich die .php-Datei als utf-8 gespeichert hatte. utf-8 schickt aber beim Aufruf bevor überhaupt angefangen wird zu parsen schon ein ByteOrderMark an den Browser was eine Ausgabe erzeugt. In diesem Fall die Datei einfach als "utf-8 ohne BOM" speichern. (Die Option gibt es in den meisten vernünftigen Editoren, ich nutze z.B. Notepad++)

    Ansonsten deinen Code nochmal genau prüfen wo du vor dem header() schon eine Ausgabe hast, denn da ist definitiv eine.

    Diesbezüglich kann ich dir dann aber nicht weiterhelfen, da du nicht die komplette Datei in einem postest, genauso wie du sie auch abgespeichert hast.

    noch hat er um hilfe gebeten...
    ich finde man kann da schon mal in groben schritten erläutern worauf zu achten ist (was ja zum teil schon passiert ist)


    Jo klar, war auch nicht unfreundlich gemeint von mir, sorry falls das so rüber gekommen ist.
    War eigentlich mehr als ernstgemeinte Frage gestellt. Wie er beim selberschreiben prinzipiell vorgeht hatte ich ja vorher ganz grob umrissen.
    Bei konkreten Fragen mit Beispielen wie er es versucht hat helfe ich dann auch gerne konkreter weiter, sofern ich kann.

    Ich habe eine kleine Kalenderklasse geschrieben, die ein Kalenderblatt zu einem Monat als HTML-Tabelle erzeugt.
    Wochenenden und Termin die man einfügen kann, können hervorgehoben werden, die entsprechenden Zellen haben eigene Id's für CSS-Definitionen.
    Ich habe es mir so geschrieben, dass es von den verschiedenen Id's jeweils noch zwei Varianten gibt, einmal mit vorangestelltem "thumb" im Id-Namen, einmal oben.
    In der thumb-Variante werden Bemerkungen zu eingetragenen Termin in ein title-Tag der Tabellenzelle für den entsprechenden Tag geschrieben.
    In der non-thumb-Variante werden diese Bemerkungen direkt in die Zelle unter den Tag geschrieben.

    Ganz glücklich bin ich mit der Sache noch nicht, für konstruktive Kritik, Anregungen, Verbesserungsvorschläge bin ich dankbar. Besonders bei der Methode getCalendar() bin ich mir noch absolut nicht sicher ob das so optimal umgesetzt ist.

    Benötigte CSS-Definitionen:
    table#Calendar
    table#thumbCalendar
    td#CalWe
    td#thumbCalWe
    td#CalEvent
    td#thumbCalEvent
    div#event (in der non-thumb-Version für die Ausgabe der Termindescriptions)

    Methoden:
    __construct($month=false,$year=false)
    $month und $year sind optional, defaultwerte sind der aktuelle Monat des aktuellen Jahres.

    setMonth($month)

    getMonth()

    setYear($year)

    getYear()

    setWe($we)
    Mögliche Parameter 1 oder 2. Legt fest Ob nur der Sonntag (=1) als Wochenendtag dargestetllt wird, oder Samstag und Sonntag (=2).

    getWe()

    addDate($timestamp,$descr)
    Erwartet den Unixtimestamp für den Tag (aus mktime(0,0,0,$monat,$tag,$jahr)) und eine Beschreibung des Termins.
    Mehrere Termine für einen Tag sind möglich.

    getCalendar($thumb=true)
    Gibt die HTML-Tabelle für das Kalenderblatt zurück. Default wird die thumbversion geliefert, die nonthumbversion gibts mit getCalendar(false).

    class.calendar.php :

    beispiel.php :

    beispiel.css :

    Wie gesagt, Erweiterungs- und/oder Verbesserungsvorschläge sind gern gesehen.