PHP Inspection Unit

[mirage228]

Hallo,

ich habe mich die letzter Zeit ein wenig mit regulären Ausdrücken beschäftigt. Daraus ist die folgende Unit entstanden.

Mit ihr ist es möglich eine PHP Datei zu analysieren. Dabei werden Klassen und Interfaces mit deren Methoden und Variablen aufgelistet, sowie Methoden ohne Klassenbezug und eingebundene Dateien (über include, require, etc.).
Ab Version 1.9 gibt es auch eine vollständige Unterstützung für Konstanten jeglicher Art (define oder PHP5-Klassenkonstanten).

Das ganze wird hierarchisch in einer Klassenstruktur zusammengefasst. Die für Benutzer relevante Klasse sollte die Klasse TPHPSource in der Unit uPHPInspector.pas sein. Ihr wird beim Konstruktor der PHP Quelltext übergeben und daraus werden die Klassen etc. herausgeparsed. Die anderen Klassen in der Unit sollten nicht direkt instanziert werden.
Die Verwendung der Eigenschaften der einzelnen Klassen sollte relativ einfach sein. Bei Rückfragen, bitte hier in den Thread schreiben.

Zum Parsen verwende ich, wie gesagt, reguläre Ausdrücke. Da die native Delphi Bibliothek TRegExpr in einem für mich wichtigem Punkt nicht ganz vollständig war, bin ich auf die Wrapperklasse von http://www.renatomancuso.com umgestiegen. Der einzige Nachteile daraus ist der größere overhead, da Anwendungen die PCRE.dll mitliefern müssen, die mit knapp 200 KB zu Buche schlägt.

Neu ab Version 1.2:
Es lässt sich nun eine Syntaxprüfung durchführen. Dazu muss man die Funktion SyntaxCheck der Klasse TPHPSource aufrufen. Dabei kann man zwischen reiner Syntaxprüfung und einer vollständigen Ausführung der Datei wählen. Bei der Syntaxprüfung werden nur rein syntaktische Fehler erkannt. Nicht vorhandene Include-Dateien oder undefinierte Funktionen werden nicht erkannt. Dazu muss der erste Parameter auf TRUE gesetzt werden.
Im Zweiten Parameter "FileName" kann noch eine Datei zur Syntaxprüfung übergeben werden (Die Datei wird nicht automatisch von TPHPSource geparsed!)
Wichtig beim Testen eurer Sources ist, dass ihr die <? und ?> nicht vergessen dürft, da die Syntaxprüfung ansonsten immer = TRUE ergibt (der Text wird dann einfach ausgegeben ohne geparsed zu werden). Zudem wird euer Source dann nicht vom PHP Inspector geparsed, wenn die PHP-Tags (<? .. ?>) fehlen (ab Version 1.6).
Das Verhalten kann durch die StrictPHPTagCheck Eigenschaft beeinflusst werden.

Im Anhang befinden sich nun:

• PHPInspector.zip Der "PHP Inspector" in der Version 2.6 (PCRE.dll und Wrapper Units included; Version 5.0 vom 26. Oktober 2004)
• sample_application.zip Eine Beispielanwendung, samt Source.
• php_source_analyzer.jpg Ein Screenshot der Beispielanwendung.

Freue mich auf euer Feedback :)

mfG
mirage228

[jfheins]

Es wäre cool, wenn das ding gleich noch die syntax checken würde ...
(Mit der php.exe und den parametern müsste das doch irgendwie gehe, oder ?)

[mirage228]

Zitat:

Zitat von jfheins

Es wäre cool, wenn das ding gleich noch die syntax checken würde ...
(Mit der php.exe und den parametern müsste das doch irgendwie gehe, oder ?)

Hi,

ja das wäre mit der php.exe möglich. Ich muss mich da aber erstmal reinarbeiten, dann sehe ich, was sich da machen lässt...

mfG
mirage228

[jfheins]

Zur Anregung:
http://de3.php.net/features.commandline

[mirage228]

Zitat:

Zitat von jfheins

Zur Anregung:
http://de3.php.net/features.commandline

Ah, danke, das sieht doch schonmal ganz gut aus :)

mfG
mirage228

[mirage228]

Hi,

heute gibts schon das erste Update auf die Version 1.1

Mir ist ein Fehler in der Funktion CheckIsComment(), die prüft, ob ein angegebener Ausdruck von einem Kommentar umschlossen ist, aufgefallen. Der Fehler trat auf, wenn ein // - Kommentar vorlag. Ich habe den Fehler beheben können und die neue Version 1.1 steht im oberen Beitrag zum Download bereit. :)

@jfheins: Den Syntaxcheck habe ich leider noch nicht einbauen können. Kommt aber bald :zwinker:

mfG
mirage228

[mirage228]

Abend!


Heute gibt es wieder eine neue Version -> Version 1.2

Hier ist die Liste der Änderungen:

• (fix): Mehrere Fehler bei der Kommentarverarbeitung in Funktion "CheckIsCommented" behoben.
• (fix): Falsche Indexierung von Einträgen innerhalb von Klassen (Eigenschaft TextPos war nicht ganz korrekt)
• (add): Möglichkeit mit PHP die Syntax überprüfen zu lassen (lokale PHP Installation, mind. 4.3.0, vorrausgesetzt)

Die Verwendung der Syntax Prüfung ist optional. Die Dateien können auch ohne untersucht. Jedoch ist dann nicht sichergestellt, ob alle Ergebnisse korrekt sind.
Nach dem Erstellen TPHPSource Klasse kann die Eigenschaft PHPExe gesetzt werden. Die sollte den vollständigen Pfad + Dateinamen der PHP.exe enthalten.
Fehler in der Verarbeitung werden in der Eigenschaft SyntaxErrors dargestellt, die fertige Ausgabe von PHP (falls keine Fehler vorliegen), findet sich in der Eigenschaft OutPut.

Man kann einmal nur die Syntax an sich testen (Parameter "CheckForRuntimeErros" = False; Standard) und einmal auch das Laufzeitverhalten (Parameter "CheckForRuntimeErros" = True). Nur bei letzterem kriegt man Meldungen von nicht gefunden Include-Dateien, nicht definierten Funktionen etc.
Optional lässt sich auch ein Dateiname angeben, der dann überprüft wird. (Diese wird nicht automatisch vom PHP Inspector geparsed!).

Ein ausführliches Beispiel findet sich in der Beispielanwendung :)
Die Downloads im ersten Beitrag sind auch schon aktualisiert.

Über Feedback würde ich mich freuen :)

mfG
mirage228

[mirage228]

Abend,

heute gibt es wieder eine neue Version vom PHP Inspector. Es ist die Version 1.3.

Neue Features sind unter Anderem:

• Unterstützung für Interfaces (TPHPInterface Klasse, verwendet Interfaces[] und InterfaceCount von TPHPSource; ImplementedInterface von TPHPClass)
• Unterstützung für abgeleitete Klassen (Feld ExtendsClass in TPHPClass)
• Unterstützung für abstrakte Klassen / Methoden (Feld IsAbstractClass in TPHPClass und IsAbstract in TPHPMethod)
• Unterstützung für finale Methoden (IsFinal in TPHPMethod)
• Unterstützung für Methoden mit private / protected Sichtbarkeit (Visibility von TPHPMethod)
• Neue Methoden FindClass, FindInterface und FindMethod

Zudem habe ich noch einige Fehler in der Bestimmung der Index-Positionen behoben.

Downloads findet ihr, wie gehabt, im ersten Beitrag.

mfG
mirage228

[DSeven]

Guten Tag,

Mich würde jetzt interessieren wie schnell das ganze ist.
Da ich selbst einen Parser geschrieben habe freut mich das projekt, nur zur Zeit schaut es so aus das dein Parser etwas langsam ist. Was dadran liegt das du immer den gesammten quelltext parst und dann das treeview immer wieder komplett neu erstelst.

Was ich noch begrüßen würde ist das du den Parser so umprogrammierst das er beim neu parsen nur die neuen elemente hinzufügt und gegenfür nicht mehr vorhande entfern anstatt jedes mal das ganze neu zu erstellen. Das spart Zeit und zwar sehr viel.
Habe es mal mit meinem Parser probiert.

Ah und um noch mehr Zeit rauszuholen solltest du statt dem Treeview in der Beispielanwendung eine VirtualTree verwenden. Bringt wieder sehr viel Zeit.

Könnte eventuel bei der umsetzung helfen.
Wenn das alles erfüllt ist würde ich deinen Parser auch in meinem Projekt benutzen.

Ansonsten ist das Teil hammer!!! Echt finde es klasse der funtkionsumfang ist sehr groß nur eben das mit dem speed stört mich.

mfg,
DSeven

[Pr0g]

Hallo,

das Projekt ist sehr interessant und ich habe mir das Beispielprogramm mal heruntergeladen und mit ein paar größeren PHP Datein des phpBB2 Forensystems getestet. Bei der Datei "search.php" ~40Kb wurde die Datei zwar geladen, jedoch kam eine Fehlermeldung "Stack-Überlauf." und die Klassenstruktur blieb leer. Bei erneutem laden, kam die Meldung dann nicht mehr, jedoch bliebt die Klassenstruktur nun wieder, bis auf die Hauptpunkte leer. Bei der Datei "viewforum.php" ~20Kb wurde das Programm einfach ohne eine Meldung beendet. Vielleicht helfen dir die Infos bei der Fehlersuche.

DSeven: Du lebts auch noch, von dir und deinem Editor habe ich schon länger nichts aktuelles mehr gehört ;)

MfG Pr0g

[mirage228]

Hi,

Danke erstmal für euer Feedback. :)

@DSeven:
Ich werde mal schauen, wie sich das am besten realisieren lässt, um nur die Unterschiede in der Datei zu berücksichtigen. Das ist auf jeden Fall eine gute Idee!
Ich hatte auch erst überlegt ein VirtualTreeView in die Beispielanwendung zu packen, aber es ist nur eine Beispielanwendung, die jeder "mal eben so" kompilieren und leicht nachvollziehen soll. Optimale Geschwindigkeit war nicht in erster Linie das Ziel des Beispielprogrammes. Aber mit einem VirtualTreeview wäre es natürlich schneller und besser - aber leider hat nicht jeder das VirtualTreeview :-(

@Pr0g:
Ja, das habe ich gestern auch feststellen können. Der Stacküberlauf wird von der verwendeten PCRE.pas verursacht undzwar bei dem Pattern der CheckIsCommented() funktion, wo auf Kommentare oder Strings geprüft wird. Ich werde das nochmal genauer unter die Lupe nehmen...

mfG
mirage228

[mirage228]

Hi,

so die neue Version ist fertig (Version 1.4)

Ich konnte das Problem mit EStackOverflow behoben. Der eine RegEx beim Prüfen von Kommentaren war "fehlerhaft" und verursachte den gennanten Fehler.

Auch habe ich die Erkennung von Kommentaren stark optimiert. Anstatt bei jedem Durchlauf den gesamten Quelltext erneut nach Kommentaren zu parsen, werden nun alle Kommentare am Anfang der Analyse im Vorraus bestimmt (neue Klassen TPHPComment und TPHPComments)
Bei meinem Test (viele Klassen mit schön viel Kommentar :) ) kam ich auf das Ergebnis von ~640ms (jetzt) gegen ~16500ms (alt) für das Analysieren des Codes. Ich werde aber noch versuchen bzgl. Speed etwas mehr rauszuholen.
Das Darstellen im TreeView habe ich nicht mit eingeschlossen, da das etwas länger dauern könnte. Als Lösung kann ich empfehlen, wie bereits vorgeschlagen wurde, das VirtualTreeView von Mike Lischke zu verwenden. Um jedoch so wenige Zusatzkomponenten wie möglich voraussetzen / mitliefern zu können, findet sich im Beispiel ein normales "TreeView" (sollte für Testzwecke aber ausreichend sein).

Aber erstmal viel Spaß mit der neuen Version! (Downloads, wie gehabt, im ersten Beitrag) :)

mfG
mirage228

[DSeven]

Zitat:

Zitat von mirage228

Hi,
Ich werde mal schauen, wie sich das am besten realisieren lässt, um nur die Unterschiede in der Datei zu berücksichtigen. Das ist auf jeden Fall eine gute Idee!

Also mein Parser tut das prinzip zur Zeit nur zur helfte verwirklichen.
Erstmal läuft der gesammte Parser in einem Thread.
Ich parse eigentlich auch immer die gesammte Datei :D (deshalb verwirkliche ich es ja nur zur helfte) aber ich überprüfe beim erstellen des Trees (VirtualTreeView) ob es den Eintrag bereits gibt, wenn ja überspringe ich den eintrag und gehe zum nächsten. So muss ich nur neue einträge erstellen anstatt das gesammte Tree erneut zu erstellen.

Bringt finde ich erheblich viel Zeit.
Ich versuche zur Zeit den Parser so umzustellen das er nur nach änderungen im Quelltext sucht was aber nur teilweise funktioniert.

Es Funktioniert nur dann wenn man auch die Editor Kompo dem entsprechend umprogrammiert. So das sie sich merkt was geändert wurde.

Also ziemlich kompliziert.
Aber eigentlich lässt sich die benötigte Zeit auch beim erstellen des TreeViews rausholen finde ich.
Teste die geschwindigkeit deines Parsers am besten gegenüber anderen Produkten wie phpEdit. Obwohl der auch sehr langsam ist.

@Pr0g: Arbeite gerade am Stable release :D
mfg,
Nexis

[mirage228]

Hi,

ich habe auch versucht zu implementieren, dass wirklich nur unterschiedliche Methoden etc. geparsed werden. Um aber zu untersuchen, dass was geändert wurde, musste ich schon fast das ganze Parsing einmal erledigen, was das ganze Prozedere ca. 1,5x langsamer machte.

Ich hab gestern noch das im Netz gefunden:
http://www.users.on.net/johnson/delphi/textdiff.html

Das sieht ganz brauchbar aus - jetzt muss ich nur schauen, wie sich das auf den Speed auswirkt. Ich hab nämlich das Gefühl das bei kürzeren Sourcen der komplette Neuaufbau am schnellsten ist.

Ich werde mir heute aber dann erstmal phpEdit anschauen und ihn mit meinem Parser vergleichen :)

Danke für die Tipps :)

mfG
mirage228

[mirage228]

Hi,

ich habe heute den Quelltext noch einmal so optimiert, um auch ohne Text-Differenz mehr rauszuholen.
Daraus resultiert die neue Version 1.5 :)

Dabei habe ich folgendes gemacht:

• Die Reguläre Ausdrücken werden einmalig im initialization Abschnitt erstellt, sodass dies nicht immer wieder geschehen muss. Das spart besonders bei langen Sourcen Zeit.
• Kommentare werden nur bis zu der Stelle geparsed, an der irgendetwas (Methode, Klasse, ...) gefunden wurde. Das spart Zeit bei Source, welcher nur am Anfang z.B. Includes, Methoden etc. stehen hat und der rest dadrunter normaler Code ist.
• Zudem habe ich den Kommentar-Algorithmus selbst ein wenig verfeinert (es wird jetzt kein Zweiter durchlauf mehr benötigt). Das spart auch etwas Zeit.

Insgesamt konnte ich eine Geschwindigkeitserhöhung von teils über 20% (variiert nach oben und unten - je nach Source) herausholen!

Aber das mit der Text-Differenz werde ich mir auf jeden Fall noch ansehen @DSeven.

Downloadlinks, wie gehabt, im ersten Beitrag!

mfG
mirage228

[Pr0g]

Gibt es irgend eine Möglichkeit die Unit ohne Beigabe der Dll nutzen zu können. Durch eine andere Lib, oder sonstwas?

MfG Pr0g

[DSeven]

Guten Tag,

Also ich habe heute einen Test mit deinem Parser 1.3 gemacht und einer Datei mit 410 Kb. Es befinden sich da verschiedene Klassen und ein paar variablen und Funktionen.

Dein Parser hat 30 Sekunden gebraucht meiner 132 ms.
ALso du siehst du must noch einiges machen.

PHPEdit hat nur zwei sekunden mehr gebraucht.
OK mein Parser part nicht so viele sachen wie deiner, aber der von phpEdit schon also solltest du dich am speed von PHPEdit orientieren.

mfg,
Nexis

[mirage228]

Zitat:

Zitat von Pr0g

Gibt es irgend eine Möglichkeit die Unit ohne Beigabe der Dll nutzen zu können. Durch eine andere Lib, oder sonstwas?

MfG Pr0g

Hi,

wenn Du mir eine Lib nennen kannst, die PCRE vollständig unterstützt und ohne DLL auskommst, dann wäre das möglich. :)
Das Problem mit TRegExpr (native Delphi) z.B. ist das einige PCRE Befehle nicht unterstüzt werden (Modifier /R für Rekursion z.B.).
Aber ich denke, dass die 200KB der PCRE.dll nicht viel ausmachen...

Zitat:

Zitat von DSeven

Guten Tag,

Also ich habe heute einen Test mit deinem Parser 1.3 gemacht und einer Datei mit 410 Kb. Es befinden sich da verschiedene Klassen und ein paar variablen und Funktionen.

Dein Parser hat 30 Sekunden gebraucht meiner 132 ms.
ALso du siehst du must noch einiges machen.

PHPEdit hat nur zwei sekunden mehr gebraucht.
OK mein Parser part nicht so viele sachen wie deiner, aber der von phpEdit schon also solltest du dich am speed von PHPEdit orientieren.

mfg,
Nexis

Also das Ergebnis mit der Version 1.3 überrascht micht nicht sehr. Dort wird bei jedem gefundenen Eintrag die Funktion CheckIsCommented() aufgerufen, die jedesmal den gesamten Quelltext nach Kommentaren und Strings(!) parsed. Das dauert auch so schon teils lange, aber die Funktion wurde je nach gefundenen Einträgen mehrmals aufgerufen. :?
Das hatte ich in der Version 1.4 verbessert. Damit kam ich auf einen Geschwindigkeitszuwachs von ~16000ms auf ~640ms in meinem Testbeispiel. Mit der Version 1.5 von gestern sollte es noch schneller gehen.

Weisst du zufällig auch, wo ich eine dementsprechend große PHP Datei herbekomme? Die größte, die ich hier habe ist ~75 KB.
Dann werde ich mir heute mal phpEdit runterladen und vergleichen...


Danke nochmal für euer Feedback :)

mfG
mirage228

[DSeven]

Guten Tag,

Wow die Version 1.5 brauch für das erste parsen nur ~900 ms und beim zweiten mal gehts noch viel viel schneller. Also das ist perfekt für den gebrauch. Ich glaube da brauchst du nicht mehr viel zu optimieren. Weil es eigentlich genauso wenn nicht schneller ist als bei PHPEdit so viel ich weis. PHPEdit parst die 450 KB große Datei nicht mal :D

Also die Datei habe ich mir selber zusammengestellt. Einfach eine klasse genommen die mir gefällt und immer wieder hintereinander rein kopiert. So teste ich meinen parser immer :D

Naja ok werde meinen Parser im Programm durch deinen ersetzen weil deiner PHP 5 Support hat und schneller ist. Muss das ganze nur noch auf VirtualTree umstellen und in einen Thread packen.

Echt klasse dein Parser hoffe das du weiter dran arbeiten wirst!!!!

@Edit: währe es eigentlich möglich ohne viel Zeit zu verlieren auch Variablen zu parsen die keinen klassen bezug haben wie in PHPEdit? Währe das letzte Feature was ich vermisse.
PHPDoc support währe auch klasse.

mfg,
DSeven

[Pr0g]

Zitat:

Zitat von mirage228

Hi,

wenn Du mir eine Lib nennen kannst, die PCRE vollständig unterstützt und ohne DLL auskommst, dann wäre das möglich. :)
Das Problem mit TRegExpr (native Delphi) z.B. ist das einige PCRE Befehle nicht unterstüzt werden (Modifier /R für Rekursion z.B.).
Aber ich denke, dass die 200KB der PCRE.dll nicht viel ausmachen...

Es geht mit eigentlich weniger um die 200Kb, sondern mehr darum, dass ich ungern eine zusätliche Dll dem Programm befüge, wenn es irgendwie eine Möglichkeit gibt dies zu vermeiden. Ich werde mich mal umschauen, ob ich eine passenden Lib finden kann.

[DSeven]

Guten Tag,

So habe bei mir das ganze auf VirtualTree umgestellt hier die Speed Ergebnisse:
400~ KB Datei:
VirtualTree: 50~ ms
TreeView: 1400~ ms

Also ist deutlich.
Also dein Parser ist schon gut, aber wenn du noch mehr optimieren könntest würde ich mich freuen. Aber für den normalen gebrauch ist es natürlich schon mehr als geeignet.

PS: Und das mit dem genauso schnell wie PHPEdit nehme ich zurück.
Dein Parser ist viel schneller. Habe es mit der 400 KB Datei getestet.
PHPEdit: 1 Minute und 40 Sekunden
Deiner: 900~ ms

Also PHPEdit kan einpacken. Obwohl PHPEdit weniger parst. Zum Beispiel parst es keine Interaces. Und public, private und so weiter interessiert den auch nicht. Ich glaube aber eher das liegt dadran das er noch variablen parst und das brauch zeit.
mfg,
DSeven

[DSeven]

Guten Tag,

Habe zwei Fehler im Parser gefunden. Währe nett wenn du sie beseitigen könntest:

1. Wenn ich folgenden Text in einer Datei stehen habe:
remember to include detailed reproduction steps and a stack trace if you have one. You can also submit other feedback;

Dan parst er ihn und fügt einen eintrag ins Treeview ein das er eine include gefunden hat die dann bis zum ; Symbol geht.

2. Es währe nett wenn dein Parser nur PHP Code parsen würde.
Also erstmal prüft ob das was er parst in den Tags <? ?> drin ist.

Ah und noch ein kleiner Verbesserungsvorschlag:
Ich fände es ziemlich geil wenn du bei klassen, funktionen und interfaces noch zwei Variablen machst.
StartBracket und endBracket oder so. Die mir die Position von den Klammern sagen.

Hoffe ich nerve dich nicht alzusehr.

mfg,
DSeven

[mirage228]

Hi,

erstmal Danke für das positive Feedback bzgl. der Geschwindigkeit :)

Nun zu deinen Fragen / Wünschen ;):

Zitat:

währe es eigentlich möglich ohne viel Zeit zu verlieren auch Variablen zu parsen die keinen klassen bezug haben wie in PHPEdit? Währe das letzte Feature was ich vermisse.

Hi,
ich kann versuchen das einzubauen. Wie sich das aber auf die Geschwindigkeit auswirken wird, kann ich dir im vorraus nicht sagen...

Zitat:

PHPDoc support währe auch klasse.

In welcher Weise sollte der sich äußern?

Zitat:

1. Wenn ich folgenden Text in einer Datei stehen habe:
remember to include detailed reproduction steps and a stack trace if you have one. You can also submit other feedback;

Dan parst er ihn und fügt einen eintrag ins Treeview ein das er eine include gefunden hat die dann bis zum ; Symbol geht.

Wenn das nicht in einem Kommentar steht, ist das ja auch kein Wunder da der RegEx nach "inlclude <egal welche zeichen>;" sucht.
Das war für mich am einfachsten, da ich sonst alle Fälle hätte durchlaufen müssen (mal mit Klammer, mal ohne, mal mit Anführungszeichen, mal ohne. Dann werde ich mir diesbezüglich was einfallen lassen...

Zitat:

2. Es währe nett wenn dein Parser nur PHP Code parsen würde.
Also erstmal prüft ob das was er parst in den Tags <? ?> drin ist.

Oh, wo Du das gerade sagst :) Das wäre ne gute Idee! ;)
(Ließe sich damit evtl. auch Problem 1 lösen?)

Zitat:

Ich fände es ziemlich geil wenn du bei klassen, funktionen und interfaces noch zwei Variablen machst.
StartBracket und endBracket oder so. Die mir die Position von den Klammern sagen.

Bei Klassen ist das kein Problem, weil sowieso der gesamte Body ({ ... }) geparsed wird. Bei Funktionen müsste ich das dann noch nachholen, weil in diesen bisher nur der Kopf ("function x()") geparsed wird.

Dann muss ich halt schauen, wie sich das ganze auf die Geschwindigkeit auswirkt - aber extreme Verluste wird es wohl nicht geben.

Zitat:

Hoffe ich nerve dich nicht alzusehr.

Keineswegs :)

mfG
mirage228

P.S.:

Zitat:

Zitat von Pr0g

Ich werde mich mal umschauen, ob ich eine passenden Lib finden kann.

Ok, Danke :) - Wenn Du was Gutes (und Schnelles? ;) ) gefunden hast, melde Dich einfach :)

[DSeven]

Zitat:

Zitat von mirage228

Zitat:

währe es eigentlich möglich ohne viel Zeit zu verlieren auch Variablen zu parsen die keinen klassen bezug haben wie in PHPEdit? Währe das letzte Feature was ich vermisse.

Hi,
ich kann versuchen das einzubauen. Wie sich das aber auf die Geschwindigkeit auswirken wird, kann ich dir im vorraus nicht sagen...

Sollte aber auschaltbar sein falls es zu langsam ist.

Zitat:

Zitat von mirage228

Zitat:

PHPDoc support währe auch klasse.

In welcher Weise sollte der sich äußern?

Also er soll die PHPDocs Tags parsen und dann der Funktion klasse hinzufügen oder so.
Man kann ja mit PHPDoc zum Beispiel beschreibungen für Funktionen erstellen. Und der parser sollte der funktion dann diese Beschreibung hinzufügen.

Zitat:

Zitat von mirage228

Zitat:

2. Es währe nett wenn dein Parser nur PHP Code parsen würde.
Also erstmal prüft ob das was er parst in den Tags <? ?> drin ist.

Oh, wo Du das gerade sagst :) Das wäre ne gute Idee! ;)
(Ließe sich damit evtl. auch Problem 1 lösen?)

Glaube schon

Also das wichtigste für mich ist erstmal eigentlich das er nur ziwschen den Tags <? ?> parst. Das ist mir sehr wichtig, das andere ist nicht so wichtig.

mfg,
DSeven

[Pr0g]

Ich kenne mich mit regulären Ausdrücken nicht so gut aus, hier mal ein Link: Link. Es ist eine Komponente, die reguläre Ausdrücke nach Perl 5 unterstützt.

Vielleicht kannst du dir den Link mal angucken und mir sagen, ob deine Unit damit funktionieren könnte. Falls ja, du aber bei deiner Dll Variante bleiben willst, kann ich versuchen deinen Code auf die Komponente umzuschreiben?

[mirage228]

Zitat:

Zitat von Pr0g

Ich kenne mich mit regulären Ausdrücken nicht so gut aus, hier mal ein Link: Link. Es ist eine Komponente, die reguläre Ausdrücke nach Perl 5 unterstützt.

Vielleicht kannst du dir den Link mal angucken und mir sagen, ob deine Unit damit funktionieren könnte. Falls ja, du aber bei deiner Dll Variante bleiben willst, kann ich versuchen deinen Code auf die Komponente umzuschreiben?

Hi,

Danke für Deinen Mühen. Leider ist die Komponente kommerziell und selbst die "Freeware" Version hat eine sehr nervige Einschränkung: :?

Zitat:

A small reminder pops up only when you run your application outside the Delphi IDE.

Daher kommt eine Verwendung für mich zumindest nicht in Frage...
[edit]Wenn Du diese, oder eine andere, Komponente benutzen möchtest, kannst Du die Unit ruhig umbauen :)[/edit]

mfG
mirage228

[Pr0g]

Oh, dass sie kommerziell, bzw. mit Popup ist habe ich nicht gesehen, in diesem Fall kommt sie für mich auch nicht in Frage.

[mirage228]

Hi,

also ich wollte euch heute mal über den "Zwischenstatus" informieren. Also ich habe mal testweise implementiert, dass der Body der Funktionen auch geparsed wird, sodass man schauen kann, wo die Brackets anfangen und aufhören. Leider hat das bei diesem Versuch die Parsing Zeit meiner "Massendatei" (760 KB) von ~3500 ms auf ~6500 ms hochgejagt. Da werde ich mir noch etwas überlegen müssen. Ich baue daher in eigenen Klassen einen privaten Konstruktor ein, dem ich bereits fertige IMatch Ergebnisse übermitteln kann, sodass das nicht erneut in der DetermineEntityName() erledigt werden muss.
Derzeit bin ich auch noch dabei die Unterscheidung für <? ?> zu machen, damit man auch HTML Dokumente mit eingebettetem PHP richtig parsen kann. :)

Also am Wochende sollte das ganze das fertig sein (hoffe ich :mrgreen:)

mfG
mirage228

[DSeven]

Guten Tag,

Das hört sich ja gut an, hoffe das du es schafst.
Freue mich schon auf den neuen release. Vor allem wegen <? ?> :D

mfg,
Nexis

[DSeven]

Guten Tag,

Ich hätte noch einen Verbesserungsvorschlag für deinen Parser:

Erstelle eine Klasse für die Includes die du von TPHPEntity ableitest.
Die klasse muss eigentlich nichts enthalten ich will nur überprüfen können ob es sich um ein Include handelt
zurzeit geht das ja nicht. Ich meine wenn ich auf ein Node im CodeBrowser zugreife.
Währe ganz nett wenn du das einbauen könntest. Ich wollte das eigentlich selber machen aber dann müsst ich bei allen
deinen neuen Version immer wieder dieses Feature selber einbauen. Deshalb ist es besser wenn du es selber zum Standart machst.

Es geht hier nur um die Bequemlichkeit, Zeit kostet das ja nicht.

mfg,
DSeven

[mirage228]

Abend,

so die neue Version (1.6) ist nun fertig.

Hier ist der Changelog:

• Wie gewünscht habe ich eine Klasse TPHPIncludeFile für Includes genommen :)
• TPHPClass ist nun Nachfahre von TPHEntity
• Nur Code in PHP-Tags (<? ... ?>) wird geparsed
• Bei Interfaces wird nun auchgeprüft, ob diese auskommentiert sind, bevor alles eingelesen wird
• AnsiCompareStr() Aufrufe durch direkte Stringvergleiche ersetzt (schneller)
• Neue Eigenschaften Head und Body in TPHPMethod
• Eigenschaften BeginBracket und EndBracket für TPHPMethod, TPHPClass und TPHPInterface
• Der Methodenkörper mit dem Code wird nun auch geparsed, um den Anfang und Ende der Methode bestimmen zu können. Diese Option kann bei Bedarf über den Compilerschalter $PARSEMETHODBODY deaktiviert werden.
• Jeder TPHPEntity Nachfahre hat nun die Eigenschaft Parent vom Typ TPHPClass. Dadurch kann man einfach herausfinden, wozu z.B. eine Methode gehört. Methoden ohne Klassenbezug haben die TPHPSource Instanz als Parent, da dieser auch von TPHPClass abgeleitet ist, sowie die Klassen und Interfaces selbst.
• Einige Code- und Geschwindigkeitsoptimierungen

In der/den nächsten Version(en) wird es noch PHPDoc Support geben (mal schaun, wie sich das machen lässt) und ich werde versuchen Variablen im Source erkennen zu lassen.

Downloads gibts, wie gehabt, im ersten Beitrag :)

mfG
mirage228

[DSeven]

Guten Tag,

Danke für den neuen Release.
Aber wie es aussieht hast du ihn vorher nicht getestet?

Ich bekomme wenn ich den Namen einer funktion abrufe nicht den Namen sondern alles samt body.
Außerdem wenn ich über den Schalter das mit dem Body einlesen abschalte bekomme ich ein paar fehler das variablen fehlen und so.

Solltest einen Bug Fix machen. ah und noch was bei meinen Interfaces liest er jetzt nicht mal die funktionen ein.

mfg,
DSeven

[mirage228]

Zitat:

Zitat von DSeven

Guten Tag,

Danke für den neuen Release.
Aber wie es aussieht hast du ihn vorher nicht getestet?

Ich bekomme wenn ich den Namen einer funktion abrufe nicht den Namen sondern alles samt body.
Außerdem wenn ich über den Schalter das mit dem Body einlesen abschalte bekomme ich ein paar fehler das variablen fehlen und so.

Solltest einen Bug Fix machen. ah und noch was bei meinen Interfaces liest er jetzt nicht mal die funktionen ein.

mfg,
DSeven

Hi,

oh, sorry, das sind mir wohl ein paar Fehler unterlaufen :oops:

Einmal hatte ich den Schalter falsch herum gemacht und einmal hatte ich in einem Konstruktor (bei deaktiviertem Schalter) den ersten Parameter vergessen.
Das mit den Interfaces war ein kleiner Folgefehler, der zu Folge hatte, dass der Text bereits in einem übergeordnetem Konstruktor gesetzt wurde, ohne dabei jedoch zu parsen. Und beim Setzen über die property hat das dann nicht funktioniert, weil die Texte ja "gleich" waren. Ich hab das mal gelöst, indem beim Konstruktor von TPHPClass auf jeden fall ParseEntity aufgerufen wird.
Das mit dem Abrufen des Funktionsnamen konnte ich nicht nachvollziehen. Bei mir gibt TPHPMethod.Name immer einen korrekten Wert zurück :gruebel:

Auf jeden Fall sind die Fehler behoben :) - Downloads gibts gleich ab sofort im ersten Beitrag

mfG
mirage228

[DSeven]

Zitat:

Zitat von mirage228

Das mit dem Abrufen des Funktionsnamen konnte ich nicht nachvollziehen. Bei mir gibt TPHPMethod.Name immer einen korrekten Wert zurück :gruebel:

Auf jeden Fall sind die Fehler behoben :) - Downloads gibts gleich ab sofort im ersten Beitrag

mfG
mirage228

Guten Tag,

Danke für den schnellen Fix.
Ja und das mit den Funktionen hast du recht :) Ich habe statt Name immer Occurence benutzt :) Also mein fehler.

mfg,
DSeven

[DSeven]

Guten Tag,

Also wenn der {$DEFINE PARSEMETHODBODY} Flag gesetzt ist zeigt er mir die Interface funktionen nicht an, wenn er nicht gesetzt ist werden sie angezeigt.

mfg,
DSeven

[mirage228]

Zitat:

Zitat von DSeven

Guten Tag,

Also wenn der {$DEFINE PARSEMETHODBODY} Flag gesetzt ist zeigt er mir die Interface funktionen nicht an, wenn er nicht gesetzt ist werden sie angezeigt.

mfg,
DSeven

Hi,

bei mir werden Interface Funktionen in jedem Fall erkannt. :gruebel: Wie sieht denn Deine Deklaration aus?
Ah, hab den Fehler! Der sucht versehentlich nun auch bei Interface nach den {} !

mfG
mirage228

[mirage228]

Hi,

so das ist nun auch behoben. :)
Ich habe mal ein paar Beispiele aus der PHP Doku ausprobiert und es scheint wirkich alles zu gehen :)

Die aktualisierten Downloads befinden sich im ersten Beitrag ;)

mfG
mirage228

[DSeven]

Guten Tag,

Ja jetzt geht es wirklich.
Habe aber nebenher was neues gefunden was zu bemengeln ist.

Undzwar parst dein Parser nur Code der zwischen <? ?> steht aber es gibt durchaus programmierer die nur einen anfangs Tags <? setzen und denn ende Tag nicht und mich würde es freuen wenn er alles nach <? parst auch wenn der Tag nicht geschlossen wurde.

mfg,
DSeven

[mirage228]

Zitat:

Zitat von DSeven

Habe aber nebenher was neues gefunden was zu bemengeln ist.

Undzwar parst dein Parser nur Code der zwischen <? ?> steht aber es gibt durchaus programmierer die nur einen anfangs Tags <? setzen und denn ende Tag nicht und mich würde es freuen wenn er alles nach <? parst auch wenn der Tag nicht geschlossen wurde.

Hm, ist eigentlich syntaktisch nicht korrekt, aber selbst PHP.exe scheint es so zu akzeptieren :shock:
Na, dann werde ich das noch einbauen - in Form eines Parameters, wie "StrictPHPTagCheck" oder so.

mfG
mirage228

[mirage228]

Abend,

so ich habe in der neuen Version 1.7 noch ein paar Dinge ergänzt - neben Deinem Vorschlag, DSeven ;)

Was sich geändert hat:

• Über die Eigenschaft StrictPHPTagCheck von TPHPSource kann das Verhalten beim Verarbeiten von nicht geschlossenen PHP-Tags beeinflusst. Ist der Parameter = FALSE werden auch nicht geschlossene Tags akzeptiert, was bei gemischten (HTML/PHP) Dokumenten möglicherweise zu falschen Ergebnissen führt. Ist der Parameter = TRUE werden nur syntaktisch korrekte Dokumente akzeptiert.
• Die Eigenschaft VarName von TPHPVariable war fehlerhaft, falls die Variable mit einem Wert initialisert wurde.
• Methoden in Klassen werden nun mit TPHPClassMethod dargestellt. TPHPMethod ist vorwiegend für Methoden ohne Klassenbezug, da diese keine Abstrakten und Finalen oder Statischen Funktionen erlauben und somit einen einfacheren RegEx benötigen. Das wirkt sich positiv auf die Parsing Zeit aus :)
• Methoden in Interfaces werden durch die Klasse TPHPInterfaceMethod dargestellt.
• Eigenschaft IsStatic für TPHPClassMethod und TPHPVariable.

Ich habe diesmal etwas ausführlicher getestet, um Fehler zu vermeiden. Falls ich doch noch Fehler gemacht haben sollte -> Immer her damit :mrgreen:

Downloads gibts, wie immer ;), im ersten Beitrag.

mfG
mirage228