Webocton - Community

[raum40302]

Hallo Thomas,

Das freut mich wenns jetzt funktioniert
RegExr = Bitte keine Ursache hab sie ja hier gehabt!

Gruß Markus

[starhunter]

Hallo Markus,

mir sind noch zwei Fehler aufgefallen und zwar in PHP Dateien.

Vorher

Code: Alles auswählen


<?php
/**
 * Check if file is on the blacklist.
 *
 * @param $filename
 *   File name.
 * @return TRUE if file is not blacklisted.
 */

 function check_file($filename)
 {
      return true; # nur eine dummy funktion
 }
?>


Nachher:

Code: Alles auswählen


<?php
/**
 * Check if file is on the blacklist.
 *
 * @param $filename
 *   File name.
 * @return TRUE if file is not blacklisted.
 */

 function check_file($filename)
 {
      return true; # nur eine dummy funktion
 }
?>


Obwohl das Plugin gelöscht anzeigt hat sich nichts getan.

MfG

Thomas

[Benedikt Loepp]

Hallo Thomas,

ne ist eigentlich richtig

Code: Alles auswählen

/**

also mit 2 Sternen soll stehen bleiben war ein Anregung von gabischatz. Weil oft kopfdaten in der Form erstellt werden.

Nachtrag zu meinem Script:
in CSS werden meistens Kopf Kommentare ala

Code: Alles auswählen

@charset "utf-8";
/**
* @for          http://lugm.de/
* @author       Luz Müller <info@lugm.de>
* @name         datum.css
* @media        screen, print, handheld, projection
* @url          http://lugm.de/css/datum.css
* @made         18.01.2012
* @last-mod     18.01.2012, 12:32
* @license      CC License
* @license URI  http://creativecommons.org/licenses/by-nd/3.0/legalcode
**/


oder ähnlich eingefügt. Dabei ist zu beachten, dass das öffnen des Kommentarbereich´s mit /** erfolgen sollte, damit dieser erhalten bleibt.

Daraufhin habe ich diese Art des Kommentars zum stehen bleiben "verdonnert" . Das bezieht sich wohl auf CSS aber ich dachte wahrscheinlich das man das in PHP ähnlich macht, Ist aber kein Problem das bei PHP auszuschliessen und nur in CSS stehen zu lassen.
Die Raute ist ein Einzeiliger Kommentar in PHP? Wusste ich nicht
Das ändere ich die nächstenTage. Danke für die Info!!

Gruß Markus

[raum40302]

Hallo Thomas,

So ich habe es geändert das die Raute (#) in PHP als einzeiliger Kommentar gilt, und in PHP (/**) auch als Kommentar angesehen wird und gelöscht wird, in Javascript- und Style- bereichen bleibt es erhalten! Evtl. würde es angebracht sein ein neuen Punkt in der Checklistbox zu erstellen um die Möglichkeit zuhaben die /** Kommentare zu löschen oder nicht.
Danke für die Infos!

Gruß Markus

[Inge]

Hallo Markus,

es ist ja schön, daß Du bemüht bist, die Eierlegendewollmilchsau zu erschaffen, aber die Wunscherfüllung mit dem # als Kommentarerkennung ist IMHO mächtig gefärlich, denn das Zeichen kann ja auch anderweitig vorkommen, z.B.

Code: Alles auswählen

echo '<span style="color:#ff0000">blabla ".$min_anzahl." noch mehr bla.</span>';} else {

Dann wäre ja alles nach

Code: Alles auswählen

echo '<span style="color:

auch weg, oder sehe ich da was falsch?

Gruß
Inge

[raum40302]

Hallo Inge,

die Eierlegendewollmilchsau zu erschaffen

Die werden wir alle zusammen schon noch erschaffen ! Ein Programm kann nur Perfekt werden (wenn es das überhaupt gibt) wenn es durch viele Leute getestet wird und die Ihre Erfahrungen schildern, nur so kommen wir zu einem (fast) perfekten Programm.
Deine Anmerkungen sind natürlich korrekt (Danke für die Info) , daran habe ich nicht gedacht ob wohl das Farbnummern Thema hier gerade hoch im Kurs steht . Ich habe es nun ausgeschlossen und es sollte stehen bleiben in Html Schreibweise

Code: Alles auswählen

bgcolor="#112233"

und in Css Schreibweise

Code: Alles auswählen

style="color:#ff0000" oder style="color: #ff0000"

Sollte irgendwas nicht passen dann immer herdamit wir kriegen die Eierlegendewollmilchsau schon noch hin .

Gruß Markus

[Inge]

Hallo Markus,

ich hatte ja nur ein Beispiel für das Problem mit der Raute genannt, darum will ich hier mal noch eines nachschieben, was mir gerade einfällt ...
Die Raute ist auch ein gültiger Delimiter in regulären Ausdrücken und da finden sich bestimmt noch mehr Fallstricke.

Gruß
Inge

[raum40302]

Hallo Inge,
das mit den regulären Ausdrücken ist so eine Sache den /* und */ wird in regulären Ausdrücken auch gerne verwendet. Es ist ein Problem an dem ich schon dran bin aber eine Handfeste Lösung wie ich reguläre Ausdrücke erkennen kann habe ich noch nicht . Klammern sind nicht unbedingt vorhanden. Meines Wissens beginnen reguläre Ausdrücke mit / und enden mit / wenn dann z.B. direkt nach dem Begin des regulären Ausdrucks ein * als Platzhalter kommt könnte es ja auch ein Kommentar sein. Die einzige Chance sehe ich wahrscheinlich darin das ich nach dem Start des Kommentars suche und dann ringsum Prüfe ob es sich um ein regulärer Ausdruck handelt (also z.B. nach \ ^ | [ ] suche ) allerdings ist die Problematik vermutlich das diese Art viel Zeit braucht. Das muß ich mal testen ist ja nur in Javascript und PHP.

Guß Markus

[Inge]

Hallo Markus,

Du wirst's schon richten.

Gruß
Inge

[starhunter]

Hallo Markus,

Meines Wissens beginnen reguläre Ausdrücke mit / und enden mit / wenn dann z.B. direkt nach dem Begin des regulären Ausdrucks ein * als Platzhalter kommt könnte es ja auch ein Kommentar sein.

Nicht immer, zumindest nicht in PHP.

Bei den alten ereg Funktionen gab es keine begrenzer.

siehe http://php.net/manual/en/function.ereg.php

Bei den neuen preg Funktionen kann man seine eigenen Begrenzer benutzen.

siehe: http://www.php.net/manual/en/regexp.ref ... miters.php

Zu JavaScript kann ich leider nichts sagen.

MfG

Thomas

[Benedikt Loepp]

Hi,
melde mich auch mal wieder ... hatte zwischendurch nicht wirklich Zeit hier großartig reinzuschauen, aber mich freut es, wie ihr hier eifrig diskutiert und bastelt

Generell wäre es glaub ich deutlich einfacher, die hier diskutierten, sehr speziellen Funktionen direkt im Editor zu implementieren. Im Gegensatz zum Plugin sind dort ja wesentlich mehr Informationen über die Datei vorhanden, z.B. ob es gerade ein PHP- oder HTML-Abschnitt ist, oder auch ob es sich innerhalb von PHP um einen String handelt. Damit ließen sich so Probleme wie mit der # relativ einfach lösen
Allerdings denke ich, auch mit der Plugin-Lösung sollte man schon recht weit kommen können. Es muss ja auch nicht immer alles absolut vollautomatisch gehen, solange der User per Optionen bestimmen kann, was genau er für Entfernungen wünscht

Ist das Plugin dann ausgereift, kommts auf jeden Fall in die Plugin-Datenbank! Auch wenn ich seit einigen der Versionen hier im Thread nicht mehr selbst getestet habe, gefällt mir das nämlich Grundsätzlich alles sehr gut hier


Nur nochmal als Info:

Ich kannte bisher nur die Phase 5 Schnittstelle und muß jetzt erst mal umdenken

Ich bin mir jetzt nicht ganz sicher aber das sollte im prinzip die gleiche Schnittstelle sein wie im Scriptly, ich meine die Plugins von Phase5 und Weaverslave sollten hier und dort laufen. Schaumal in der Hilfe unter Plugins.

Phase5 hatte eine eigene Schnittstelle, Weaverslave hatte eine eigene Schnittstelle. Der Weaverslave unterstützte seine eigene, die von EPS, sowie die von Phase5. Und genauso macht es auch der Scriptly: Er unterstützt die Weaverslave-Pluginschnittstelle, die von Phase 5, und die von EPS. Es ist also möglich, auf drei unterschiedliche Weisen ein Plugin zu schreiben. Die Phase5-Schnittstelle ist dabei die simpelste, die EPS-Schnittstelle erweitert diese etwas, und die Weaverslave-Schnittstelle ist völlig unabhängig davon, aber deutlich umfangreicher


P.S.: Falls seit ansonsten meinem letzten Posting irgendwelche Fragen hier im Thread aufgekommen waren, die ich vielleicht überlesen hab - weist mich ruhig drauf hin

Schönen Gruß,
Benedikt Loepp

[raum40302]

Hallo,
@Thomas das mit PHP ist soweit klar so detaliert wusste ich das nicht ich benutze wahrscheinlich aus Reflex in Php(und hier nutze ich eigentlich nur die preg Funktionen) und Javascript "/" als Begrenzer. Meines wissens sind die Regulären Ausdrücke in Javascript an Perl angelehnt und in Perl sind, mein ich, die Begrenzer vorgeschrieben.

sehr speziellen Funktionen direkt im Editor zu implementieren

Das ist prinzipiell richtig.

z.B. ob es gerade ein PHP- oder HTML-Abschnitt ist, oder auch ob es sich innerhalb von PHP um einen String handelt.

Ob es ein PHP, Javascript oder HTML Abschnitt ist, ist eigentlich soweit klar das wird schon vom Plugin "unterteilt", ob es ein String ist dürfte nicht allzu schwer sein raus zubekommem ( " und ' begrenzen ja den String). Nur wenn in einem normlen String dann die Raute vorkommt würde das Plugin das als Regulären Ausdruck werten und es stehen lassen. Über die einzenen Funktionen, in Php oder Javascript, wird es auch nicht gehen weil vieles über Variablen geht. (Über die Raute oder den einzeiligen Kommentar // mache ich mir weniger Sorgen da such ich nach dem Strichpunkt und sehe obs davor oder dahinter ist und wenn davor ob die ganze Zeile auskommentiert ist).
Ich glaube das das testen des z.B. Php Blocks auf die Ansammlung von den jeweiligen Zeichen ("[]{}/\|^") in einem String am ehesten auf einen Regulären Ausdruck hinweist. Und wenn das der Fall ist das die Ansammlung da ist dann muss Quasi aufgepasst werden ob und wo das entsprechende Zeichen ist im String oder auserhalb. Die Problematik sehe ich dann in der Zeit und Rechenleistung die diese Art benötigt. Um diesem Problem ein bischen ausdem Weg zugehen sollte vorher getestet werden ob überhaupt ein Regulärer Ausdruck in der Datei vorhanden ist die kann dann über die Suche der funktionen(z.B. pregmatch) gehen.

Im Gegensatz zum Plugin sind dort ja wesentlich mehr Informationen über die Datei

Aber doch nur während des schreibens der Datei wenn sie gespeichert oder geschlossen wurde sind keine anderen Informationen vorhanden (bezüglich z.B. bin ich ein String oder nicht oder bin ich ein reguläre Ausdruck) wie die die im Text der Datei stehen oder täusch ich mich?? Sollte ich mich täuschen währe es natürlich sehr sinnvoll das "plugin" im Editor zu implementieren.

Gruß Markus

[Benedikt Loepp]

Hi,

Ich glaube das das testen des z.B. Php Blocks auf die Ansammlung von den jeweiligen Zeichen ("[]{}/\|^") in einem String am ehesten auf einen Regulären Ausdruck hinweist.

Hier verstehe ich das Problem noch nicht so ganz. Du sagst doch, auf einen String zu testen sollte (derselben Meinung bin ich auch...) nicht so schwierig sein. Naja, dann sollte es doch kein Problem sein, innerhalb dieser Strings einfach keine Entfernung vorzunehmen, wenn ein # oder // oder dergleichen vorkommt. Dabei ist es doch völlig unerheblich, ob in dem String jetzt eine RegEx steht oder jemand einfach viele Rauten echoen möchte Wenn Kommentar-Symbol in PHP-String gefunden => nichts tun. Oder versteh ich das Problem nicht richtig?

Aber doch nur während des schreibens der Datei wenn sie gespeichert oder geschlossen wurde sind keine anderen Informationen vorhanden (bezüglich z.B. bin ich ein String oder nicht oder bin ich ein reguläre Ausdruck) wie die die im Text der Datei stehen oder täusch ich mich??

Nur wenn sie geöffnet ist, da hast du schon recht. Dein Plugin arbeitet momentan doch aber auch nur für die jeweils geöffnete Datei, oder? Wenn du aber all diese Sachen auch schon gut erkennen kannst, ist das auch mehr oder weniger egal - es ist dann quasi nur doppelt gemoppelt, weil die Information im Editor schon vorhanden wäre - aber das macht ja nichts

Schönen Gruß,
Benedikt

[raum40302]

Hallo,

Hier verstehe ich das Problem noch nicht so ganz. Du sagst doch, auf einen String zu testen sollte (derselben Meinung bin ich auch...) nicht so schwierig sein. Naja, dann sollte es doch kein Problem sein, innerhalb dieser Strings einfach keine Entfernung vorzunehmen, wenn ein # oder // oder dergleichen vorkommt.

Und da haben wir es mal wieder ich mache mir vielzuviele Gedanken und die Lösung ist so einfach . Natürlich hast du recht Benedikt wenn die Raute im String ist nichts tun. Dasselbe natürlich auch mit den Mehrzeiligen Kommentaren.

Nur wenn sie geöffnet ist

Ich glaube wir reden aneinander vorbei oder ich verstehs falsch. Ein Beispiel :
ich schreibe in eine neue Datei

Code: Alles auswählen

<?php echo "Hallo";?>

jetzt weis der Scriptly da ist ein String an Position 12 klar. Jetzt speichere ich die Datei und schliesse Sie und schliesse den Scriptly. 2Stunden später öffne ich die Datei mit dem Scriptly wieder und jetzt weis der Scriptly, nach dem öffnen der Datei, das ein String an Position 12 ist ??

aber das macht ja nichts

Genau das denke ich auch

es ist dann quasi nur doppelt gemoppelt, weil die Information im Editor schon vorhanden wäre

Das ist bei vielen Plugins denke ich der Fall das die infos die man sich sucht im Editor vorhanden währen. Aber dann macht das Plugin schreiben nur halbsoviel Spass wenn alles schon da ist .

Gruß Markus

[Benedikt Loepp]

Nur wenn sie geöffnet ist

Ich glaube wir reden aneinander vorbei oder ich verstehs falsch. Ein Beispiel :
ich schreibe in eine neue Datei

Code: Alles auswählen

<?php echo "Hallo";?>

jetzt weis der Scriptly da ist ein String an Position 12 klar. Jetzt speichere ich die Datei und schliesse Sie und schliesse den Scriptly. 2Stunden später öffne ich die Datei mit dem Scriptly wieder und jetzt weis der Scriptly, nach dem öffnen der Datei, das ein String an Position 12 ist ??

Sobald die Datei geöffnet ist, weiß der Scriptly "alles" über die Datei. Das Highlighting ist ja auch entsprechend vorhanden, und alle diese Informationen aus dem Highlighting stehen natürlich auch jederzeit für andere Funktionen zur Verfügung. Daher wäre es vermutlich deutlich weniger mühsam gewesen, solche Sachen wie festzustellen, was ein String ist, zu implementieren - einfach weil die Informationen sowieso schon vorhanden sind

es ist dann quasi nur doppelt gemoppelt, weil die Information im Editor schon vorhanden wäre

Das ist bei vielen Plugins denke ich der Fall das die infos die man sich sucht im Editor vorhanden währen. Aber dann macht das Plugin schreiben nur halbsoviel Spass wenn alles schon da ist

Und ich hätte doppelt soviel Arbeit, wenn ich tatsächlich jede eurer Ideen selbst implementieren müsste - und für viele Dinge bieten sich Plugins außerdem an, da somit der Editor nicht mit Funktionen überfrachtet wird, die nur ein Bruchteil der Leute benötigen
In diesem Sinne: Weiter so

Schönen Gruß, Benedikt Loepp