Aiun

eval() bzw. prototype und mootools machen das mit einem Parameter an das Request-Objekt.

Welche Art Fehler ? in PHP gibt es mehrere Error-Reporting Parameter die in der php.ini gesetzt werden, bzw. auch zur laufzeit geändert werden können. Die meisten Fehler landen per default im Browserfenster, das kann man aber unterdrücken. Exceptions werden leider von PHP selbst fast nie geworfen (viele Frameworks erzeugen Exceptions durch eigene Prüffunktionen in den lowlevel-Funktionen) schau dir diesbezuglich "errorreporting()" "seterrorhandler()", oder so ähnlich heißen die funktionen an. in der PHP.ini einfach nach "Error reporting" suchen, da stehen die default-Werte für deinen Server. in der php.ini stehen auch meistens die erklärungen zu den parametern, denke damit solltest du klar kommen. Wenn du aber Apache Fehler meinst, mir ist kein Beispiel bekannt wo die nicht im error-log landen

$text = preg_replace("/\<img src=\"([^\"]*)\"\>/si", "[img=\\1]", $text); der Bildpfad darf ja alles, "außer" einem Anführungszeichen enthalten. Natürlich währe es noch sauberer [0-9a-zA-Z....(andere zeichen)] zu verwenden um auch hier mist zu unterdrücken.

dann würde ich sagen hast du einen Fehler in deinen JS Code. Leider habe ich meine Kristallkugel zum polieren gegeben, daher ist das jetzt etwas schwierig

he he, für ein Framework aus eigener Hand. hmm, mysql tools, könnte es sein das das reine Windows-Programme sind ? so 1:1 sind die doch nicht auf Linux vorhanden oder irre ich ? phpmyadmin hast du oft/schnell auf jedem Server mit drauf und kannst auch ohne rootrechte oder ssh zugreifen.

Darf ich die Frage mal umdrehen ? ich schreibe derzeit Dokumentationen (APIdoc, Tutorial...) Was für Informationen sind am wichtigsten oder welche Art von Tutorials erscheinen dir / euch am sinnvollsten ? Ich bin jetzt grob bei: - Skeleton (funktionslose, einfache Umgebung als Download) - erster Datenbankzugriff - Datenbankabstraktion / OR-Mapping - Templates - Controller & Applikationsstruktur (MVC...) weitere Ideen ? danke

das ist auch eine Frage der Details - willst du durch den Text durchsuchen ? - wird immer ein ganzer Text angezeigt oder können es auch mehrere in einer Anzeige sein ? - Wie häufig werden die Texte geändert ? - Wieviele User greifen gleichzeitig zu ? ich würde es evtl. als Verschwendung ansehen, die Texte in die Datenbank zu legen, obwohl du sie nie dort brauchst. (z.B. Sql-Abfragen, übersichten, sortierung etz.) dann eher (abhängig von den Details) die Variante nur Dateinamen in der DB zu hinterlegen. mit einem guten OR/Mapping sollte der unterschied im Quelltext nicht zu groß sein.

Wie hibernate: nein, nicht das ich wüsste. OR-Mapping haben einige der Frameworks, wie gut, hängt von den einzelnen ab. (einer der Gründe warum ich Sphere3 begonnen hatte). Wirklich "gutes" (meine Meinung / Anforderungen) Mapping ist aber eher selten. Da meine Hibernate Zeit kurz war, und lange her ist k.A. ob es das ist was du suchst: ich nutze einen Codegenerator der mir aus XML-Dateien Basis Entity und Setklassen generiert, so das alle verbleibende Implementierung rein objektorientiert abläuft. Mit 5 anfangen ist der richtige Weg, wenn du dann doch auf 4 entwickeln musst, musst du dich mit den Eigenheiten eh beschäftigen. Aber 4 sollte langsam sein Ende finden da musst du auf die antwort der anderen warten. Ich meine mich zu erinnern das Mysql5 das kann. (kein Fan von SP)

Als Entwicklungsumgebung kann ich dir phpEclipse empfehlen, wenn du eh die Arbeit mit Eclipse gewohnt bist, kommt dir das auch noch zu gute. Die Einarbeitung in PHP ist wieder etwas anderes. Ganz gut sind die openbooks von galileocomputing, einfach mal eine suchmaschine deiner wahl verwenden. Das Niveau das du von Java gewohnt bist, gibt es in PHP dank diverser Frameworks / Klassenbibliotheken da kann ich mal aufzählen - ZendFramework (eine umfangreiche Ansammlung von Hilfsfunktionen und Klassen) - phpsolar (full scale also Controller, Datenzugriff, MVC-Modell...) - limb3 (keine Ahnung, nur kurz reingesehen) - flow3 (Coming soon, von den typo3-Jungs) - ezcomponents (mehr auf das visuelle ausgelegt) und dann am Rande erwähnt Sphere3, Eine Eigenentwicklung meinerseits. Jedes von den Systemen hat genau wie JSP, Struts & Co sein eigenes 'How-To-Use'. Natives PHP wie gesagt openbook. Aber ehrlich gesagt würde ich mir rel. früh ein / mehrere Frameworks ansehen, spart dir eine Menge Stress "Datenbankvisualisierungstool" ich vermute du spielst auf phpmyadmin an, das ist, behaupte ich mal, eine art Standard in Verbindung mit php und/oder mysql.

Typo3 < Plugin < eigener Code Du kannst diese Funktionen ja in einem Plugin realisieren (oder in mehreren) Entsprechend 1 das du im Typoscript für das Menü einbindest und eins für den Inhalt, das z.B. mit +/- durch die Inhaltsseiten blättert. 'theoretisch' ^^ musst du ja nur Links generieren zu bestimmten Typoseiten. Allerdings hast du dann die hürde vor dir eine Extension zu tippen (immernoch weniger arbeit als ein mini-cms zu schreiben, was dann eh zu Problemen führt)

nach einiger weiteren Suche habe ich nun eigene Klassen entwickelt um Dokumentationsblöcke und Klassen zu parsen, falls mal jemand vor dem gleichen Problem steht: fragen. Die Klassen parsen bestimmte marker / schlüsselwörter (class, function /** ....) und generieren XML-Dateien um die Klassen zu beschreiben. Die wiederrum können dann in Webseiten eingebunden werden um die Dokumentation darzustellen wie immer gewünscht.

Bzgl. text meinte ich webseiten, die de fakto kein Layout haben. nur Text sind der aneinander gereiht wird (siehe viele blogs, die nur eine papierseite immitieren) Du hast jetzt ein grundsätzliches Problem von HTML angesprochen. Es gibt leider (immernoch) keine Möglichkeit, Layout und inhaltlicher Struktur nebeneinander existieren zu lassen. Um Inhalt mit einem Rahmen zu umschmücken brauche ich eine Tabelle, oder ein duzend verschachtelter Div-Layer um Ecken und Seiten zu platzeren. Natürlich Div-Layer haben 'offiziell' keinen Einfluss auf die Struktur, aber im Dokument tauchen trotzdem duzende Layer auf, die ja eigentlich keine Verbindung zum Inhalt brauchen (Strukturell gesehen), da wäre es sinnvoller ähnlich Javascript per ID o.ä. Layout-Tags mit Inhalt-Tags zu verknüpfen, ohne das sie 'dort' im Code auftauchen. ... nur ein Beispiel. Das web besteht aber nunmal aus mehr als Textdokumenten, sonst bräuchten wir weder HTML noch CSS, dann reicht das hochladen von .txt-ähnlichen Dateien . Überschriften können nur in den wenigsten dokumenten (unabhängig vom web) überhaupt sinnvoll eingesetzt werden, weil die Autoren nicht wissen wie sie ihre Programme benutzen sollen. Was html auch noch fehlt wären so logische Tags, die nicht zwangsweise Gerendert werden müssen, um Text oder Codeblöcke logisch zu kategorisieren (erstellt wann, letztes update wann, Titel/Art des Inhalts z.B. Summary, intro) h(x)-Tags beschreiben nunmal nur einen Punkt im Dokument, keinen Bereich. Was dazu führt das in vielen seiten Div-Tags mehr Struktur zeigen als p, hx und Co. oder weis jemand von einer solchen Möglichkeit und ich habe sie nur noch nicht bemerkt ?

Das Problem das die meisten Layouts immernoch aussehen wie Tabellen liegt nicht an der Technik, sondern an den Designern. Die Menschen sind aber auch durch die lokalen Programme, Toolbars unsw. diese Struktur gewöhnt. Sidebars in irgendwelchen Dateibrowsern unsw. Und die alternative, die ich zwar weniger als den Klassiker im Netz sehe, aber genauso schade, ist die dekradierung von Webseiten zu Textdokumenten. d.h. Layout scrollt weg, weil Inhalt länger, alles untereinander, 500px festbreite mit füllfarbe oder ähnliches .( wie gesagt, das Problem liegt wohl eher bei den Designern.

deine Beiträge werden zu lang ^^, wir sollten das irgendwohin auslagern, sonst weis nie jemand wieviel noch zum kern des beitrags gehört und wir müssen uns nicht wiederholen.

Layouts werden aber ersteinmal nicht technisch, sondern optisch / grafisch entworfen. Die technik dient zur Machbarkeit als nebengedanke, ist aber nicht treibender Grund. Dein Problem ist, wie im anderen Thread schon gesagt das du aus sicht der Technik nicht aus sicht von Anforderung oder Optik denkst. die Technik muss erfüllen was als sinnvolle Anforderung angesehen wird. Wenn er also Layouts in tabellendenken entwirft ist das völlig ok. Ein TR ist nichts anderes als ein Div mit anderen divs auf 100% höhe, verschachtelte Tabellen gab es auch, das ist alles das gleiche. Unterschied Tabelle->css ist 1. Die Auszeichnung, d.h. Screenreader und automatische Analyseprogramme können Tabellarischen Inhalt und Layout trennen. 2. Die Verbindung der Zellen ist optional (im moment eh noch nicht wirklich möglich, das ist ja das Problem ) Natürlich machen wir hier auch ein wenig Überzeugungsarbeit, aber wir sollten das nicht übertreiben. Es währt sich in diesem Thread ja niemand gegen CSS, sondern fragt nach dem wie. Und an dem Tabellendenken ist nix schlimmes dran. Wenn ein Ingenieur mit dem Gedanken an ein Fahrrad beginnt um herauszufinden wie er ein Auto bauen soll, dann bitte, solange das resultat ok ist.

hu, ich suche derzeit Tools um Dokumentationen eines PHP-Frameworks zu erstellen. Das Tool sollte PHP-Code analysieren und daraus "einfachen" xml-Code generieren, den ich dann für verschiedene zwecke, z.B. Einbindung in die Website des Frameworks nutzen kann. getestet habe ich: phpdocumentor Problem: die meisten Formate sind full-html, framed oder alles inline. das XML-Format docbook ist nicht gerade gut zu parsen und in meinem Beispiel waren es dateien je methode, anstatt datei je Klasse dann die php reflection API Problem: die API gibt nur informationen über klassen die bereits geparsed sind, was dazu geführt hat, das der Code auch ausgeführt wird. (in einigen Dateien stehen oben aufrufe drin, die Klassenabhängigkeiten auflösen) ergo, komme ich auch mit der reflection api nicht weiter. Gibt es andere Tools die ihr empfehlen könnt, bevor ich wieder das rad ein 3. mal entwickeln muss ? danke

ein großteil der Layouts die heutzutage ohne tabellen gemacht werden sind nur kopien von der Layoutstruktur die nuneinmal aus einer Tabelle besteht, selbst wenn es technisch nicht so realisiert ist. Wirklich "innovative" Layouts, oder abweichende, gibt es relativ wenig. Also hört doch bitte auf auf dem Tabellendenken rumzuhauen das kann nerven und hilft weder Threadersteller noch sonstjemandem. dan!eL, ich vermute du meinst Tutorials wie "3 column layout", "2 column Layout" etz ? gibt es viele Seiten, aber keine die mir jetzt besonders groß oder wichtig im Kopf erscheint. Wenn du was findet kannst du dich ja mitteilen.

Javascript und die größe der Div-Boxen in Pixel berechnen (bei onResize !)

javascript, du kannst mittels ajax inhalte abrufen und in dein Dokument einfügen. und nein !, du musst nicht wieder mit tabellen arbeiten. Es sei denn du hast ein ganz verrücktes design in dem die divs zu viel arbeit machen würden, aber davon gehe ich hier mal nciht aus

:confused: sehr innovative Frage. Was genau willst du denn nun prüfen und was steht da drin ? die meisten Quellcodekommentare sind eh in einer Schreibweise die kein Prüfprogramm versteht. Du hast eine XML Datei + Kommentar-Tags oder wie ? oder beschreibt die XML-Datei deinen eigentlichen code ? :confused::confused:

jep, ich denke wir beenden das auch für diesmal nur ein kommentar zum abschluss, wenn ein Div/htmldokument die höhe des inhaltes hat, dann müsste es auch die breite des Inhalts haben, ergo keine 100% breite. ich hab hier noch etwas für den Threadersteller, wg. Browserkompatibilität: if (document.documentElement && document.documentElement.clientHeight) { x = document.documentElement.clientWidth; y = document.documentElement.clientHeight; } else if (self.innerHeight) { x = self.innerWidth; y = self.innerHeight; } else if (document.body) { x = document.body.clientWidth; y = document.body.clientHeight; } evtl. kann das ja jemand noch erweitern / verbessern. Ich weis nicht wie es mit Safari aussieht, nie getestet.

ein div ohne breite hat 100%, die logik besagt eigentlich das es dann auch 100% höhe haben müsste. Das die verantwortlichen (nicht?) immer wissen was sie tun, sieht man meiner Meinung nach an den ewigen diskussionen über html5, xhtml2 und dem ganzen Formatwust. Präsentationen werden stets an das Medium angepasst (Beamer, Monitor) und nutzen "immer" 100% der verfügbaren Fläche aus. Ausdrucke auf Papier werden auf das Papier angepasst (teilweise mehrspalting und trotzdem zentriert ^^) Warum also dann nicht webseiten auf den Bildschirm (Browser) anpassen? Eben wenn du deinen Browser nicht im fullscreen benutzt, ist es tierisch nervend (meine Meinung) wenn die Webseiten eine bestimmte größe vorgeben, anstatt sich an den Browser anzupassen. Mehr scrollen als nötig, das halbe (falls schöne) Layout verschwindet oder ich habe 200px "nichts" weil meine Auflösung höher ist als die vom Designer vorgesehene referenzgröße. *g* die Themen die dieser diskussion bedarfen kommen auch immer wieder.

*g* naja, es muss schon die Möglichkeit geben das Material an die Ausgabeform anzupassen. ergo höhe und breite des Bildschirms. Wobei ich denke mir würde ein einfaches Rechnen mit CSS besser gefallen

Jester, ich denke das Problem liegt darin das du aus sicht der Technologie denkst, nicht aus sicht der Anforderung. Anforderung ist in seinem Beispiel nunmal, das zwei Elemente feste größen haben und eines den rest nimmt, an der Anforderung ist auch nichts auszusetzen. Nun ist es eine Frage der Technologie diese Anforderung zu erfüllen, nicht andersrum.wenn Css das nicht kann, ist das kein Fehler des denkens, sondern des CSS Das es auch gute layouts ohne dieses gibt, daran zweifle ich nicht, das ändert nichts daran das die Möglichkeit benötigt wird und somit auch erfüllt werden sollte. Momentan ist div-layout zwar besser als ein Tabellenlayout, aber in der Aufteilung einer Seite war die Tabelle besser. Divs klatschen alles untereinander, nebeneinander ja nur dank float (was dem Ganzen ein wenig den sinn nimmt) und dann haben wir wieder das Problem das die elemente weder gleiche höhe, noch gleiche breite haben können, da sie keine Beziehungen untereinander haben (selbst wenn gewollt). Was dazu führt das wir immer schöne ausreden brauchen wenn der Kunde Layoutelemente haben will die "zueinander passen", ergo etwas gemeinsam haben, und wir sagen müssen "geht nicht!" ... das ewige Thema.

ich empfehle ein kleines Javascript das die höhe deines Div-Layers festlegt. Dann ist es auch einzeln scrollbar. Für alle ohne JS bleiben deine Menu-Divs stehen und werden weggescrollt. Wobei du mit body, html {height: 100%} den effekt schon erreichen könntest, musst du testen. Es wird wohl noch ein wenig dauern bis alle browser verstanden hat das wir 100% height "brauchen" ^^, genauso wie rechnen in CSS:mod: