Beiträge von SinnlosS


    Das ganze soll offensichtlich eine gewerbliche Site sein, die Termine veröffentlicht. Für solche Sites ist ein gewisses Maß an Berrierefreiheit gesetzlich vorgeschrieben

    Kannst du mir dafür bitte die Quelle nennen. Ganz abgesehen davon, dass es selbstverständlich immer sinnvoll ist eine gewerbliche Seite so barrierefrei wie möglich zu halten, kann ich beim besten Willen nicht glauben, dass es dafür gesetzliche Vorschriften gibt. Die gibt es für Seiten von staatlichen Einrichtungen bzw. staatlich geförderten Einrichtungen, aber meines Wissens nicht für eine stinknormale gewerbliche Website. Gewerblich spielt für sowas doch keine Rolle, genauso wie jedes normale Geschäft jeder Person frei nach Laune Hausverbot erteilen kann, kann ich von einer Website völlig willkürlich Leute ausschließen die ich da nicht haben will, völlig egal ob gewerblich oder nicht. Wieviel Sinn das macht steht natürlich auf einem anderen Blatt, und dass die obige Seite vom Quelltext her alles andere als gut umgesetzt ist braucht man nicht zu diskutieren.

    Ich habe mir mal einen Blog erstellt auf dem ich in Zukunft gelegentlich etwas schreiben werde.

    Mein erster Artikel behandelt das Thema Datenschutz/Privatsphäre.

    http://www.sinnloss.de

    Das Logo oben muss ich wohl nochmal neu machen, habe mir den SinnlosS-Schriftzug aus einer Grafik gezogen die ich vor ca. 8 Jahren erstellt habe und weiß nicht mehr welche Schriftart ich da verwendet hatte, gefällt mir aber gut. Irgendwo auf dem Weg vom Ausschneiden aus der Ursprungsgrafik über die farbliche Anpassung muss da was schief gelaufen sein, dass das jetzt so verpixelt ist. Bin leider kein Grafikprofi, werd das bei Gelegenheit nochmal neu probieren.
    Falls jemand die Schriftart erkennt, bitte sagen wie die heißt! :)

    Klar geht max-width auch auf Elemente mit position:fixed. Nur das zentrieren mit margin:0 auto; klappt da halt nicht.
    Ich gehe aber davon aus, dass links und rechts neben Kopf- und Fußzeile nichts mehr hinkommt. Dann kannst du die über die volle Breite laufen lassen und darein noch ein div mit dem eigentlichen Inhalt setzen welches du zentrierst.

    Ich hatte hier nur ein iPhone3 zum testen, Kollege hat grad mal mit Android draufgeschaut, da greift der hover-state tatsächlich. Trotzdem ist das für touch-devices nicht empfehlendswert, da es beim ziehen zum Beispiel auch mal zu solchen Effekten kommen kann, dass der hover-state nicht wieder entfernt wird.

    Hier ist ein ganz interessanter Ansatz für ein responsives Dropdown-Menu:
    http://webdesignerwall.com/tutorials/css-…/comment-page-1


    Außerdem, kann mir jemand sagen, warum mein Dropdown menü auf allen jeglichen Computer und Handys, mit allen von mir getesteten Browsern funktioniert, nur Apples Geräte dieses nicht öffnen wollen, wobei IOS Simulatoren dagegen dies anzeigen? -.-

    Das Menu wird auf keinem Smartphone oder Tablet funktionieren, da es auf diesen Geräten keinen hover-State gibt.

    Die Methode ist sehr unsauber und verbraucht unnötig Ressourcen. Warum nicht ein Pfeil aus dem Unicode Zeichensatz. Da gibt es etliche, und dann mit CSS :hover einfärben.

    Genau das. Und wenn es unbedingt eine Grafik sein soll, dann bitte die verschiedenen States als Spritemap anlegen, mit background-image arbeiten, und beim :hover halt nur die background-position ändern. Sowas mit JS zu machen ist vollkommen veraltet und unnötig.

    Eine Forensoftware ist simpler als man denkt.

    Für 99% der Leute - und nach dem zu urteilen was du schreibst auch für dich - ist das falsch, es gilt das Gegenteil. Wer ein Forum selber entwickeln möchte sollte sich hervorragend mit der Programmiersprache und dem DBMS seiner Wahl auskennen und vor allem mit Sicherheitsaspekten. Er sollte auf jedenfall umfangreiche Erfahrung mit großen Projekten mitbringen. Das was du in deinem Posting beschreibst ist nur der 0-8-15-Teil, die absolute Spitze des Eisbergs. Der Teufel steckt im Detail, ein Anfänger wird niemals auch nur annähernd den nötigen Aufwand richtig einschätzen können, bei der Entwicklung dutzende Dinge vergessen zu berücksichtigen und diverse Sicherheitslücken haben.
    Jedem der nicht fundierte Fachkenntnisse und Praxiserfahrung mit großen Projekten mitbringt kann ich nur ausdrücklich davon abraten selber ein Forum zu entwickeln, wenn es nicht ein reines Hobbyprojekt zu Lernzwecken sein soll.

    Wie Bandit kann ich da auch nur zur Verwendung einer fertigen Software raten. Man muss das Rad nicht immer wieder neu erfinden.


    Ich, im Gegensatz zu dir, habe in Projekten mit mehreren Programmierern die Erfahrung gemacht, dass des einen unnötigen Auwand darstellt, sich durch die einzelnen Messages für Exception für jede Methode durchzuarbeiten anstatt einen Satz von 20 Excpetions auswendig zu kennen, der überall Anwendung findet. Soll sich der TE aussuchen, was besser ist.

    Und was vermutest du, wieviele der Leute die so etwas in einem Forum fragen in Teams an wirklich großen Projekten arbeiten? Ich bin grundsätzlich auch immer für klare Strukturen, Abstraktionen, Aufteilungen von Aufgabenbereichen und entsprechende Kapselung. Wie gesagt habe ich es für Exceptions aufgegeben weil mir noch nicht ein Fall untergekommen ist, wo es mir einen echten Mehrwert geboten hätte.
    Das Beispiel "User wird in die Datenbank eingetragen aber dann kann die E-Mail nicht gesendet werden" ist für mich obsolet, da Validierung, Speicherung in der DB und Versand von E-Mails für mich drei verschiedene Aufgaben sind die nicht in einer Methode abgearbeitet werden. Unter anderem auch aus diesem Grund der klaren Trennung von Aufgabenbereichen machen für mich verschiedene Exceptions nicht sonderlich Sinn. Die Art der Exception wird so schon durch die Stelle an der sie auftritt definiert, da brauch ich keine eigene Klasse für definieren.

    Aber wie du schon sagst, der TE soll selber schauen wie es für ihn am meisten Sinn ergibt. Ich fand nur deine Formulierung im ersten Post zu strikt.

    lukasn:
    Exceptions schmeiße ich dann, wenn eine Funktion/Methode die Aufgabe für die sie gedacht ist nicht ausführen kann. Eine Funktion registerUser() soll einen User registrieren. Kann sie diese Aufgabe nicht ausführen wird eine Exception geschmissen. Anders sähe es beispielsweise bei einer Funktion isValid() aus, da gehört es zur Aufgabe der Funktion Daten zu validieren, und eine fehlgeschlagene Validation ist in dem Fall keine Exception.

    Also ich bitte dich Tobse...
    Das war selbstverständlich nur ein simplifiziertes Beispiel. Selbstverständlich werden die Fehlermeldungen in der Praxis mittels Platzhaltern, Variablen oder Konstanten gesetzt.
    Genauso kann man zusätzlich Errorcodes angeben. Und ob man jetzt zig verschiedene Catch-Blöcke schreiben muss um die verschiedenen Exceptions abzufangen, oder ob man ein switch-Anweisung für die Errorcodes schreibt, ist nun wirklich kein nennenswerter Unterschied. Ich habe ein komplettes Framework und ein ORM selber geschrieben und schon mehr Projekte umgesetzt als ich noch zählen kann. Früher meinte ich auch es wär toll für jeden Blödsinn eine eigene Exception zu definieren. Die Erfahrung hat mich gelehrt, dass es überflüssig ist, ich habe es noch nicht ein einziges Mal benötigt.
    Wenn du persönlich es toller findest unzählige verschiedene Exceptions zu definieren dann tu das, aber behaupte bitte nicht das wäre nötig.

    Du solltest dich mal mit Ajax vertraut machen um immer nur die Inhalte einzeln neu zu holen, die wirklich aktualisiert werden müssen. Das wird sicherlich nicht die komplette Seite sein. So ein minütlicher Autorefresh einer kompletten Seite ist in meinen Augen ein ziemliches Unding.
    Für Ajax empfehle ich die Verwendung eine JS-Frameworks, z.B. jQuery.

    session_regenerate_id() generiert die Session ID aber auch automatisch.

    Ich habe auch nichts gegenteiliges behauptet. Das bezog sich auf diese Aussage von dir:

    Aber das Ändern einer Session ID ist nicht die Regel sondern nur in speziellen Ausnahmefällen

    Das ist nämlich falsch, session_regenerate_id() ist bei sensiblen Session-Daten ein Sicherheitsfaktor den man berücksichtigen sollte, wenn man verantwortungsvoll coden möchte.

    Kann man. Allerdings musst du da eher eine UsernameInvalidException werfen, nur Exception ist ziemlich ungenau und kann ich richtig abgefangen werden.

    Naja, außer in wirklich großen Projekten an denen mehrere Leute arbeiten und die umfangreich konzeptioniert und dokumentiert werden, schmeiße ich auch immer nur normale Exceptions. Die Genauigkeit erhalte ich über die Message die geschmissen wird, da kann ich sogar noch viel präziser werden als einfach nur durch den Klassennamen der Exception.
    Wo das Problem beim abfangen sein soll kann ich auch nicht wirklich erkennen.

    Sensible Daten (z.B. DB-Zugangsdaten) außerhalb des Web-Roots liegen haben. Optimalerweise ist die einzige php-Datei die im/unterhalb des Web-Roots liegt die bootstrap/index.php.

    Das sämtliche Validierungen von User-Eingaben IMMER serverseitig stattfinden müssen sollte selbstverständlich sein. Clientseitige Überprüfungen sind immer nur ein netter Zusatz, dürfen aber NIEMALS serverseitige Validierungen ersetzen.

    Auch Sicherheitsaspekte beim Session-Handling sollten berücksichtigt werden:
    http://phpforum.de/forum/showthread.php?t=216531

    Über das Thema gibt es jede Menge ganze Bücher, das ist nicht in einem Thread im Forum mal eben abgetan. OOP sollte natürlich selbstverständlich sein aus Gründen der Wartbarkeit und Erweiterbarkeit.
    MVC ist auch ein guter und verbreiteter Ansatz, wobei ich direkt zu HMVC raten würde.
    Models haben aber nichts mit einer Datenbank am Hut, ein Model hat es nicht die Bohne zu interessieren woher es seine Daten bekommt. Sowas lagert man besser in ein Repository aus von dem man sich dann die Models holt. Das Repository weiß dann ob die Daten mit denen das Model gefüttert wird aus einer DB, aus einer XML-Datei oder sonstwoher kommen, und kümmert sich außerdem um eine konsistente Identity Map.

    Werden sie nicht - sie werden meistens automatisch generiert.

    Es reicht also vollkommen, wenn du weißt: durch session_start() hast du eine ID automatisch bekommen und mit session_id() kannst du sie auslesen und ändern. Aber das Ändern einer Session ID ist nicht die Regel sondern nur in speziellen Ausnahmefällen und mir würde auch kein Grund einfallen, warum man eine session_id() manuell festlegen sollte...

    Für das regelmäßige Wechseln der Session ID über session_regenerate_id() gibt es sehr gute Gründe, nämlich Sicherheit vor Session-Diebstahl.

    Die manuelle Vergabe einer Session ID benötigt man wohl in den wenigsten Fällen, kann aber durchaus Sinn machen, wenn Sessions länger gespeichert werden und Admins gegebenenfalls eine ältere Session übernehmen, sei es aus Debugging-, Wartungsgründen oder sonstwas.

    Edit:
    Hier auch noch ein guter Artikel zum Thema Session-Sicherheit, die Inhalte sollte man auf jedenfall kennen und berücksichtigen wenn es um sensible Daten geht:
    http://phpforum.de/forum/showthread.php?t=216531

    Ja, Sessions sind auch bei Ajax-Calls vorhanden. Das einzige worauf man achten sollte ist bei Ajax-Calls kein session_regenerate_id() zu verwenden, sonst kann die Session beim weiteren navigieren verloren gehen.

    Prinzipiell ist es möglich HTML von Ajax-Calls zurückzugeben. Sauberer ist es aber nur die benötigten Daten im JSON-Format zurückzugeben und das HTML dann clientseitig mit JavaScript zu generieren. Je nach Anforderung kann da ein JS-Template-System hilfreich sein, z.B. Mustache:
    https://github.com/janl/mustache.js