Bessere Editoren für HTML/PHP und CSS

Fragen zur Installation von CONTENIDO 4.9? Probleme bei der Konfiguration? Hinweise oder Fragen zur Entwicklung des Systemes oder zur Sicherheit?
tinof
Beiträge: 197
Registriert: Mi 24. Jan 2007, 20:38
Wohnort: Kirchberg / Sa.
Kontaktdaten:

Beitrag von tinof » Fr 23. Feb 2007, 06:29

Hallo,

ich habe etwas herumprobiert und folgendes funktioniert für mich derzeit hinreichend gut. Bitte beachtet - ich befasse mich erst seit 4 Wochen mit PHP & co und insbesondere mit Contenido - es wir sich also nicht um DIE Lösung handeln, aber es geht zunächst.

Meine Umgebung :
Xampp unter Windows XP, PHP 5.1.4
Contenido aktuelle Version
PHPEdit 2.10. (Release Candidate)
alles auf localhost (=Entwicklugsumgebung)

1)
Für das Debuggen muß zunächst der php - Debugger aktiviert werden :
Das machen wir durch folgende Einträge in der PHP.INI im apache/bin - Verzeichnis.

extension=php_dbg.dll

[debugger]
debugger.enabled = On
debugger.profiler_enabled = On
debugger.JIT_enabled = On
debugger.JIT_host = clienthost
debugger.JIT_port = 7869
debugger.enable_session_cookie = Off
debugger.fail_silently = On
debugger.ignore_nops = Off
debugger.profiler_enabled = true
debugger.session_nocache = On
debugger.timeout_seconds = 300

(Hier gehen bestimmt auch andere Einstellungen, ich weiss ehrlich gesagt auch gar nicht, was das im Einzelnen alles bedeutet :oops: - aber so geht es bei mir)

2)
Jetzt erzeugen wir in phpEdit zunächst ein neues Projekt mit Hilfe des Assistenten :
Im Solution Explorer (wenn der weg sein sollte : <Ansicht><Fenster andocken>) Rechte Maus -> neues Projekt ->
Filename : beliebig
Name : z.B. Contenido
Weiter->
Im Project inclusion Dialog den Pfad zur Contenido - Installation (z.B. \xampp\htdocs\contenido)
Weiter-> und finish->

Nun haben wir schön übersichtlich das gesamte Contenido vor uns. Das ist aber für's eigentliche debuggen erstmal nur schmückendes Beiwerk.

3)
Den zu debuggenden Modulcode kopieren wir in eine Datei *.php die wir zweckmäßigerweise in einem eigenen Ordner (z.B. ...\Contenido\Contenido\debug\) ablegen.

4)
Im Contenido Modul - Editor schreiben wir stattdessen nur ein
include ( $contenido_path . "debug\meincode.php") (Beispiel).

5)
Die php - Datei können wir im phpEdit erstmal öffnen und bearbeiten.
Statt eines Breakpoints (das geht leider irgendwie nicht) schreiben wir eine debugbreak() - Anweisung.

6)
Schließlich starten wir Contenido aus dem Browser heraus (bei mir : MSIE 7) Der Start im internen phpEdit - Debugger geht zwar, führt aber dann später zu undefiniertem Verhalten.
Wir navigieren uns durch das contenido - Menü zur Seite mit unserem Modul (können wir ja als Startseite einrichten :roll: ) .

7)
Sobald contenido an die debugbreak() - Anweisung kommt, springt der Focus zu phpEdit und ich kann jetzt Schritt - für Schritt ausführen (F7/F8 ), Variablen inspizieren usw. - Alles was das Herz begehrt. Auch das Verzweigen in andere (contenido) - Quelltexte funktioniert.

8 )
Wenn das Modul einmal 'abgearbeitet' ist, sind auch Änderungen möglich. Ein Reload im Browser testet erneut.

So, das war's. Das geht sicherlich auch mit anderen Entwicklungsumgebungen aber wie bereits gesagt : Weder Zend noch Eclipse noch ... kamen gleich so schön mit den gesamten Contenido klar.
Ich hoffe, das Ganze ist halbwegs nachvollziehbar und funktiniert auch bei Euch.

P.S. Ich weiß, dass der IE in Webdesinger - Kreisen nicht den besten Ruf hat, aber es gibt da ein tolles Plugin : IE Developer Toolbar
Ein schöner 'Spicker' 8)

Viele Grüße
Tino

tinof
Beiträge: 197
Registriert: Mi 24. Jan 2007, 20:38
Wohnort: Kirchberg / Sa.
Kontaktdaten:

Beitrag von tinof » Fr 23. Feb 2007, 07:11

NACHTRAG !

Bevor ihr jetzt viel Zeit investiert um vielleicht oben genanntes auszuprobieren :

Das ganze läuft immer nur 2-3 mal durch, danach ist Neustart von phpEdit und apache notwendig.

Also - wie einleitend angedeutet - wohl doch nur eine Notlösung.

Sorry und vielleicht kann ja jemand noch 'was verbessern.

tinof
Beiträge: 197
Registriert: Mi 24. Jan 2007, 20:38
Wohnort: Kirchberg / Sa.
Kontaktdaten:

Beitrag von tinof » Fr 23. Feb 2007, 10:54

NACHTRAG II

Bei mir liefen dbg und xdebug parallel im php. Jetzt habe ich xdebug rausgenommen und es läuft schon mehrere Stunden.
Vielleicht lohnt es sich doch.

P.S
Gibt es eigentlich in diesem Forum eine Post - Editieren - Funktion damit ich euch nicht so zuposte ?

EDIT : Ja, danke ! Hab ich wohl vorhin übersehen, sorry
Zuletzt geändert von tinof am Fr 23. Feb 2007, 11:05, insgesamt 1-mal geändert.

HerrB
Beiträge: 6935
Registriert: Do 22. Mai 2003, 12:44
Wohnort: Berlin
Kontaktdaten:

Beitrag von HerrB » Fr 23. Feb 2007, 10:58

Du solltest für Deine Beiträge rechts oben ein "Edit" finden.

Und danke.

Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!

Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net

knb
Beiträge: 224
Registriert: Fr 9. Sep 2005, 14:03
Wohnort: Potsdam
Kontaktdaten:

Beitrag von knb » Di 27. Feb 2007, 19:56

Ich habs mal versucht nachzuvollziehen, den dbg Debugger nach obiger Beschreibung einzurichten.
Habs auch hinbekommen, unter php4.4.2, Apache2, windows, phpedit 2.10 rc.

Ein paar Fragen dazu...

-es sollte doch heissen, DebugBreak() statt debugbreak() , oder ?:

- der trick mit dem include("debug/Filename.php"); der scheint bei mir nur im Outputbereich eines moduls zu funktionieren. geht das genauso auch im Inputbereich? Habe nur kurz probiert.

- bei mir kommen in conlib\db_mysql.inc beim Durchlaufen der funktion
function free() {
@mysql_free_result($this->Query_ID);
$this->Query_ID = 0;
}
oft Alert-Boxen mit seltsamen Warnungen wie
...not a valid mysql resource.... Kann man wegklicken, aber nervig ist das schon! (Fehlerursache Möglw: DB-Verbindung wurde schon in anderem PHP file geschlossen)

Tritt das bei Euch auch auf? Kann man was anderes dagegen tun ausser den debugger so zu konfigurieren dass Warnungn ignoriert werden?

- aussdem gibt es angeblich in vielen php Files irgendwo seltsame Zeilenendezeichen ("\r\r\n"). warnt die PHPEdit-IDE beim durchwandern des Quellcodes ziemlich häufig. " Do you want me to fix this?" Das geschieht aber nur in der lokalen Kopie der Datei die der debugger anlegt, oder?
So gibts beim nächsten Debugversuch die nervige Meldung immer wieder aufs neue. Tritt das bei euch auch auf?

Und gibts diese dialogbox auch so oft?:
"The File "-Embedding" could not be found !"
Cancel

http://www.waterproof.fr/support/forums ... php?t=2020
(Scheint OLE/COM Problem zu sein)
Ist der xdebug Debugger, den phpedit in zukunft schwerpunktmässig unterstützen will, eigentlich irgendwie besser? Schon hingekriegt? Wie siehts aus unter Linux?
Gruss,
Knut

tinof
Beiträge: 197
Registriert: Mi 24. Jan 2007, 20:38
Wohnort: Kirchberg / Sa.
Kontaktdaten:

Beitrag von tinof » Mi 28. Feb 2007, 07:28

Hallo,

- DebugBreak() ist natürlich korrekt (ich muß mich erst an die Sginifikanz der Groß / Kleinschreibung gewöhnen, sorry)

- Inputbereich habe ich noch nicht getestet. Aber ich habe zumindest festgestellt, das (in meiner Installation) JEDES DebugBreak in den Debugger von phpEdit verzweigt, ggf. lädt er sogar erst das Programm (phpEdit) nach.

- Den Fehler in der db_mysql.inc habe ich auch, wenn man ->query_id inspiziert steht da auch NULL. Ich habe das Problem aber nicht weiter verfolgt, dazu habe ich mich noch viel zu wenig mit der Materie befasst.

- das "\r\rn" Problem habe ich noch nicht gesehen, leider auch keine Erklärnug

- die "the file xyz (und oft "-Embedding")" - habe ich öfters und sie kündigt den Absturz der Debugsitzung an. Irgendwie kann der Debugger manchmal nicht mehr die benötigten Dateien finden, beim nächsten Versuch findet er sie aber auch wieder. Ich habe mich hier mit dem Warten auf die final release vertröstet.

- mit dem xDebug habe ich es überhaupt nicht hinbekommen.Zwar gibt es hier das Pendant Xdebug_Break() (o.ä.), das auch den Debugger öffnet - soweit noch ok, danach geht aber fast nix mehr.

Ok, das hilft jetzt alles nicht wirklich weiter, aber wir sind wenigstens schon zu zweit :oops

Ich habe mich bisher auch hauptsächlich auf mein Modul konzentriert, das Contenido - Innenleben nur so weit erforscht, wie ich Klassen / Variablen benutzen mußte. Sobald ich was Neues weiß, melde ich mich wieder

DANKE fürs Ausprobieren !
Tino

knb
Beiträge: 224
Registriert: Fr 9. Sep 2005, 14:03
Wohnort: Potsdam
Kontaktdaten:

Beitrag von knb » Mi 28. Feb 2007, 10:25

Das mit der "-Embedding " Fehlermeldung- dazu habe ich in dem Forum der Firma NuMega ein Posting von dem phpdbg Entwickler Dmitriy gefunden. http://support.nusphere.com/viewtopic.p ... hlight=ole
Unwahrscheinlich dass man das selber in den Griff kriegt. Schade.

Fürs erste bin ich froh, überhaupt funktionierende (wenn auch fragile) Entwicklungsumgebung mit Debugger zur Verfügung zu haben.

Ich werds (die nächsten Wochen) mal unter Linux probieren, vielleicht gehts da mit ner anderen IDE besser. Die Vorgehensweise dürfte ähnlich sein wie beim PHPEdit. Aber auf jeden Fall, danke für die Tips! Waren unverzichtbar um überhaupt loslegen zu können.
Gruss,
Knut

tinof
Beiträge: 197
Registriert: Mi 24. Jan 2007, 20:38
Wohnort: Kirchberg / Sa.
Kontaktdaten:

Beitrag von tinof » Mi 28. Feb 2007, 12:58

Hallo nochmal, ich habe auch noch etwas gegoogled und zum -Embedded - Problem das gefunden :http://www.waterproof.fr/support/forums ... php?t=2020.

Sieht so aus, als muß ich mir (sobald Zeit vorhanden) den xDebug doch nochmal anschauen.

Grundsätzlich deckt sich das aber mit meiner Beobachtung beim Test der anderen Entwicklungsumgebungen (siehe Posts weiter oben) : Es scheint, das öfters eine neue 'Sitzung' gestartet wird. Dann war z.B. beim Zend immer die Debugsitzung weg. Der Waterproof phpEdit hat aber trotzdem (meistens) den Faden behalten.
Vielleicht kann ja ein php / contenido - Profi kurz erläutern, was da eigentlich passiert : Ich würde das als 'PHP - Neustart mit Wiederaufsetzen' bezeichnen. Leider weiss ich nicht warum das so ist.

Danke !
Tino[/url]

tinof
Beiträge: 197
Registriert: Mi 24. Jan 2007, 20:38
Wohnort: Kirchberg / Sa.
Kontaktdaten:

Beitrag von tinof » Fr 30. Mär 2007, 06:16

Nachtrag zum Debugging :

- Das Debugging funktioniert analog auch grundsätzlich im Input - Bereich

- Sobald CMS - Typen, also CMS_VAR[], CMS_VALUE[] usw. im Modulcode sind, klappt das Auslagern in eine externe Datei nicht mehr : Diese Variablen müssen im Modulcode verbleiben, in einer per Include eingebundenen Datei werden sich nicht erkannt und somit auch nicht korrekt behandelt. Workaround : Im Modulcode diese Variablen 'richtigen' lokalen Variablen zuweisen und dann erst per Include in den ausgelagerten Debug - Teil verzweigen. Nicht schick, nicht immer realisierbar, aber manchmal doch hilfreich.
Für die Freizeit : www.hobbybrauer.de

eegroove
Beiträge: 16
Registriert: Mo 19. Apr 2004, 15:34
Kontaktdaten:

wie kann man die Module mit eclipse bearbeiten

Beitrag von eegroove » Sa 11. Aug 2007, 19:11

Hallo,

ich würde gerne die (input/output) Module, die in der Tabelle "con_mod" zu finden sind mit Eclipse-Aptana oder phpEclipse bearbeiten und nicht über das backend.

Das ganze System läuft im Moment nur auf localhost.
Da das nur eine Testplatform ist, die später auf einen anderen Server hochgeladen werden soll, brauche ich mir um Sicherheitsaspecte keine Gedanken zu machen.

Danke
Ernst
(eegroove)

tinof
Beiträge: 197
Registriert: Mi 24. Jan 2007, 20:38
Wohnort: Kirchberg / Sa.
Kontaktdaten:

Beitrag von tinof » Mo 13. Aug 2007, 07:02

Hallo Ernst,

den Modulcode direkt in einer anderen Umgebung zu bearbeiten - genau so wie im Contenido Backend, das wird sicher nicht gehen.

Was ich aber immer mache (wenn ich nicht direkt nach außen verwzeigewie oben beschrieben), ist, das ich den Code im externen Editor mit Syntaxhiglighting und Syntaxprüfung bearbeite und wenn alles stimmt per copy & paste wieder ins Modul übernehme.
Das geht recht einfach und schnell.

Viel Erfolg
Tino

Edit: Die CMS_VAR[] usw. - Variablen immer in "" setzen, damit die externe Syntaxprüfung nicht drüberstolpert.
Für die Freizeit : www.hobbybrauer.de

eegroove
Beiträge: 16
Registriert: Mo 19. Apr 2004, 15:34
Kontaktdaten:

Beitrag von eegroove » Di 14. Aug 2007, 07:00

Das wär doch mal was für die Kategorie, "Feature Requests" ?

Grüße
Ernst

tinof
Beiträge: 197
Registriert: Mi 24. Jan 2007, 20:38
Wohnort: Kirchberg / Sa.
Kontaktdaten:

Beitrag von tinof » Fr 28. Dez 2007, 07:26

Hallo,

.. aus gegebenem Anlaß mal wieder hocholen.

Als eingefleischter Delphi - Programmierer habe ich mit natürlich auch Delphi for PHP angeschaut.
Ich find's genial, die Puristen wird es etwas verschrecken (für eine HelloWorld - Webseite muß man schon > 2 MB (wiederverwendbaren) Quellcode hochladen.
Na jedenfalls ist das die bisher erste PHP - Umgebung, in der das Debugging wirklich und stabil und ohne irgendwelche Konfigurationsorigien funktioniert. Einfach <F9> drücken, und ab geht die Post.
Die bekannten Probleme, z.B. Modulcode vernünftig zu debuggen, löst dieses Produkt auch nicht, wer aber eine schöne PHP Entwicklungsumgebung sucht, sollte sich das mal anschauen. Und wer sich mal über objektorientierte PHP Programmierung informieren möchte, der sollte mal einen Blick auf die VCL for PHP werfen.

Grüße
Tino

P.S. ich bin nur (zufriedener!) Delphi - Nutzer und habe sonst keine Beziehungen zu CodeGear/Borland
Für die Freizeit : www.hobbybrauer.de

Antworten