Stefan Muenz: Perl-Maker - Perl-Scripts zum Zusammenklicken ...

Liebe Forumer,

fuer echte Perl-Programmierer ist so was natuerlich ein Fanal. Fuer Anfaenger aber ist es vielleicht eine sinnvolle Unterstuetzung. Oder?  Oder nicht? Vielleicht sagt ihr mal was ihr davon haltet. Es handelt sich um einen web-basierten, interaktiven Online-Editor fuer Perl-Scripts.

Los gehts auf http://www.perlmaker.de/ (einfuehrende Infos). Der eigentliche Editor befindet sich unter http://www.perlmaker.de/perlmaker.htm. Der Editor unterstuetzt den User mit Makros, also partiellem Perl-Code fuer bestimmte Aufgaben, vor allem fuer CGI-Scripts.

Wie viel man bei diesem Verfahren Perl lernen kann, ist natuerlich fraglich. Aber andererseits sagen viele Praktiker, dass es am besten ist, wenn man sich vorhandenen Code nimmt und diesen dann anhand von Hilfen und Dokumentation selbstaendig anpasst. Insofern kann so ein Online-Editor vielleicht sogar wertvolle "Bausteine" liefern.

Also einfach mal ausprobieren und dann mal hier die Meinung sagen ;-)

viele Gruesse
  Stefan Muenz

  1. Hallo Forumer,
    hallo Stefan,

    erstmal muß ich zum Ausdruck bringen, wie ich mich gefreut habe, das das forum wieder online ist, jetzt bekommen die langen ladezeiten wieder einen Sinn.

    fuer echte Perl-Programmierer ist so was natuerlich ein Fanal. Fuer Anfaenger aber ist es vielleicht eine sinnvolle Unterstuetzung.

    ich bin weder das eine, noch das andere

    Oder?  Oder nicht? Vielleicht sagt ihr mal was ihr davon haltet.

    Gerne, ich finde die Sache Spaßig, aber wirklich nützlich finde ich sie nicht. Ich glaube nicht, das mir das zu Anfang viel geholfen hätte, ich hätte noch lange nicht gewust, was die einzelnen Befehle nun wirlich zu bedeuten hätten.

    Wie viel man bei diesem Verfahren Perl lernen kann, ist natuerlich fraglich. Aber andererseits sagen viele Praktiker, dass es am besten ist, wenn man sich vorhandenen Code nimmt und diesen dann anhand von Hilfen und Dokumentation selbstaendig anpasst.

    Ja, da stimme ich den "vielen" zu, ich habe meine Anfänge auch mit einem hier nicht ganz unbekannten forumsscript (wwwboard) gemacht, und nach und nach das ein oder andere verstanden.
    ABER, wenn ich nicht sehr viel übersehen habe, liefert der Perlmaker keinen zusammenhängenden Code, sondern blanke Befehle.
    So gehört für mich zu einem
    open(DATEI,"NAME")
    auch immer ein
    close(DATEI)
    usw.

    Ich fürchte der Perlmaker ist nur für Leute, die genau wissen was sie schreiben wollen, aber es schneller angeklickt als geschrieben haben.

    Gruß
    Wilm

  2. Hallo,

    das Ding ist witzig. Und ich glaube für erste Schritte ist es auch geeignet.

    Der Vorteil ist wohl, dass ein Newbe mal reinschnuppert, was er mit Perl oder überhaupt serverseitigem Scripting für Schabernak treiben kann. Entweder er hat dan Blut geleckt oder er lässt es bleiben. Nur wird er sich bei weiterem Interesse umschauen müssen, wo bekommt er denn einen Editor mit Debugger usw. her. Mal abgesehn davon dass er CGI Server Perl usw auf dem eigenen Rechner einzurichten.

    Bye Ed X

  3. Hallo Stefan,

    ich finde die Seite durchaus brauchbar. Ich persönlich würde meine Skripte natürlich nicht damit erstellen, weil ich an sich kein Maus-Mensch bin. Bei mir geht doch fast alles mit der Tastatur.

    (btw: Vermisse eine Tastenkombination für reload unter NS4.7, aber das nur am Rande)

    Ich meine, wenn ich ein foreach $bla (@sowieso) { ... } haben will, dann tippe ich das schneller als daß ich auf "foreach" klicke, dann vor die Klammer, die dort enstanden ist, Variable eingegeben, dann zwischen den Klammern geklickt (naja, da hätte ich sowieso die Cursortasten genommen) usw.

    Doch, natürlich, mir ist die Möglichkeit, von Hand zu tippen, nicht genommen worden. Also kann ich tippen und wenn ich doch mal einen Klick brauche, dann klick ich eben doch :-)

    Aber wofür es wirklich gut ist:
    Zu meinen Anfängen, als ich gerade kapiert hatte, daß es ein GET und ein POST gibt, hätte mir die Seite schon sehr viel geholfen.
    Wie ging das nochmal? Ach, gehen wir mal hin und kucken, wie die das gemacht haben ... klick auf "GET&POST{}" .. und ach ja, so ging´s. Gleich ins eigene Skript kopieren :-)

    Meinetwegen noch etwas modifizieren, dann hat´s sich.

    Genauso ist es mit ein paar anderen Dingen wie zum Beispiel dem HTML-Header. Ich muß noch heute stets nachschauen, was man als erste Zeile an den Browser schicken muß "Content-type" etc.

    Ich für meinen Teil halte das Tool für durchaus sinnvoll und würde es auf der SelfHTML-Linkliste sehr begrüßen. In meinen Bookmarks ist es schon.

    Zum Arbeiten nehme ich allerdings lieber Phase V wegen der Syntaxhighlighing. (ActiveState Komodo hab ich auch, aber es ist nicht leicht, Phase V / Proton den Rücken zu kehren :-) )

    Grüße, Vedat

    1. Hallo!

      (btw: Vermisse eine Tastenkombination für reload unter NS4.7, aber das nur am Rande)

      wie wärs damit: [strg] + R ?

      Gruss Markus

    2. Moin,

      Aber wofür es wirklich gut ist:
      Zu meinen Anfängen, als ich gerade kapiert hatte, daß es ein GET und ein POST gibt, hätte mir die Seite schon sehr viel geholfen.
      Wie ging das nochmal? Ach, gehen wir mal hin und kucken, wie die das gemacht haben ... klick auf "GET&POST{}" .. und ach ja, so ging´s. Gleich ins eigene Skript kopieren :-)

      und sich wundern, aergern, fluchen, loeschen, nochmal kopieren, fluchen, selbst neuschreiben (Reihenfolge modifizierbar)

      wie Alex schon sagte, der Code, der dort angeboten wird, ist zu Teilen schlicht und ergreifend falsch (und damit Müll).

      Ich für meinen Teil halte das Tool für durchaus sinnvoll und würde es auf der SelfHTML-Linkliste sehr begrüßen. In meinen Bookmarks ist es schon.

      [x] dagegen

      [x] dafuer als Negativbeispiel

      Zum Arbeiten nehme ich allerdings lieber Phase V wegen der Syntaxhighlighing. (ActiveState Komodo hab ich auch, aber es ist nicht leicht, Phase V / Proton den Rücken zu kehren :-) )

      ich arbeite mit Proton (V2.11) und bin nach wie vor zufrieden damit ;)

      Viele Gruesse,

      n.d.p.

  4. Hallo,

    fuer echte Perl-Programmierer ist so was natuerlich ein Fanal.

    ACK (ohne Anspüruch ein *echter* Perl-Programmierer zu sein),

    Fuer Anfaenger aber ist es vielleicht eine sinnvolle
    Unterstuetzung. Oder?  Oder nicht?

    Letzteres.

    Wie viel man bei diesem Verfahren Perl lernen kann, ist natuerlich
    fraglich.

    Nicht fraglich ist, wie viel Falsches man lernt, das man später mühevoll aus dem Kopf bringen muß.

    Aber andererseits sagen viele Praktiker, dass es am
    besten ist, wenn man sich vorhandenen Code nimmt und diesen dann
    anhand von Hilfen und Dokumentation selbstaendig anpasst.

    Ja, das gilt aber nur, wenn man qualitativ hochwertigen Code als Grund/Vorlage nimmt. (z.B. mitgelieferte Standard-Module, die zum grössten Teil in Perl geschrieben und hervorragend Dokumentiert sind).

    Insofern kann so ein Online-Editor vielleicht sogar
    wertvolle "Bausteine" liefern.

    Auf Anhieb festgestellte Mängel:

    • kein -w
    • kein use strict / kein my
    • kein use CGI (Querystrings werden mit veraltetem Code geparsed)
    • teilweise keine Überprüfung von Rückgabewerten (flock, close)
    • keine Einhaltung an gültige Konventionen

    Hier werden genau die Art von Newbies "erzeugt" die später in Massen die gleichen, sinnlosen Fragen in/im Foren/Usenet stellen, die mühelos hätten verhindert werden können. Nämlich mit dem Lernen, anhand der von Profis erstellen, frei mitgelieferten Perldokumentation (die alles, samt Tutorials für Anfänger und Profis, enthält) von Anfang an. Und dem zwar manuell aber richtigen Eintippen des einen oder anderen Befehls.

    Alles IMHO.

    viele Gruesse
      Stefan Muenz

    Gruß Kai

    1. Hallo Kai,

      Auf Anhieb festgestellte Mängel:

      • kein -w
      • kein use strict / kein my
      • kein use CGI (Querystrings werden mit veraltetem Code geparsed)
      • teilweise keine Überprüfung von Rückgabewerten (flock, close)
      • keine Einhaltung an gültige Konventionen

      Auch wenn strict zum guten Ton gehoert - aber wenn es wirklich soooo verpflichtend waere, warum ist es dann nicht laengst Default beim Perl-Interpreter?

      Und "use CGI" ist auch noch kein Gesetz, das der liebe Gott gemacht hat, es ist nur eine der beliebtesten ewigen Stammtisch-Wiederholungen in den Newsgroups. Kein Zweifel - das CGI-Modul ist sinnvoll. Aber fuer ein Script, das nur ein einziges Formularfeld auszuwerten hat, moeglicherweise nicht. Denn jedes Modul-Laden erzeugt ja auch wieder Serverlast.

      Ansonsten stimme ich dir durchaus zu. Die "Bausteine", die das Tool liefert, lassen sich wahrscheinlich noch verbessern.

      viele Gruesse
        Stefan Muenz

      1. Hallo Stefan,

        Auch wenn strict zum guten Ton gehoert - aber wenn es wirklich soooo verpflichtend waere, warum ist es dann nicht laengst Default beim Perl-Interpreter?

        Perl lebt von Konventionen, nicht von Einschränkungen.

        Die Option lässt Programmierern, die wissen was sie tun, eine größere Freiheit. Anfängern (und darum ging es ja) hilft 'use strict' sauberen Code zu produzieren, und damit lästige, schwer auffindbare Fehler zu vermeiden.

        Letztendlich ist es nur eine Angebot zur Hilfe, das nicht in Anspruch genommen werden muß.

        Und "use CGI" ist auch noch kein Gesetz, das der liebe Gott gemacht hat, es ist nur eine der beliebtesten ewigen Stammtisch-Wiederholungen in den Newsgroups. Kein Zweifel - das CGI-Modul ist sinnvoll. Aber fuer ein Script, das nur ein einziges Formularfeld auszuwerten hat, moeglicherweise nicht. Denn jedes Modul-Laden erzeugt ja auch wieder Serverlast.

        Ich finde nicht, das dieser Rat aus einer Bierlaune heraus gegeben wird. Die Erfahrung zeigt, daß sich viele Anfänger schon schwer damit tun, einen gültigen HTTP-Header zu erzeugen. Das und noch viel mehr ist sehr leicht mit CGI.pm zu lösen (BTW: nebst Überprüfung ob ein Header schon ausgegeben wurde oder nicht).

        Ein Skript, das CGI.pm benutzt ist mit Sicherheit übersichtlicher, leichter zu verstehen und zu warten/erweitern als andere und das ist (für Anfänger) sicherlich sinnvoller als Server-Last (Wobei ich mir nicht sicher bin, in wie weit man wirklich Einbussen hat).

        viele Gruesse
          Stefan Muenz

        Gruß Kai

        1. Moin,

          Ein Skript, das CGI.pm benutzt ist mit Sicherheit übersichtlicher, leichter zu verstehen und zu warten/erweitern als andere und das ist (für Anfänger) sicherlich sinnvoller als Server-Last (Wobei ich mir nicht sicher bin, in wie weit man wirklich Einbussen hat).

          bei mir hat alleine "cgi.pm" die Länge von ca. 200 kB, die erst
          einmal geparst sein wollen. Zugegebenermaßen fällt das bei
          vereinzelten Aufrufen kaum auf, aber bei einem Server,
          der sehr viele CGI-Aufrufe gleichzeitig abfertigen muß,
          könnte sich das m.E. durchaus bemerkbar machen
          (oder gibt es inzwischen die Möglichkeit, auf compilierte
          Perl-Module zurückzugreifen?).
          Ob CGI.pm zum Verständnis der Sprache Perl beiträgt, wenn man
          es einfach blind benutzt, wage ich ebenfalls zu bezweifeln.
          Natürlich produziert man zunächst mit größerer Wahrscheinlichkeit
          fehlerfreie CGI-Skripte, dafür ist es für die meisten wohl um so
          weniger nachvollziehbar, was in CGI.pm genau passiert.
          Man lernt dann IMHO eher das korrekte "Bedienen" der CGI.pm-Library
          anstatt Perl.

          Wenn man allerdings weniger lernen sondern eher zu schnellen
          Ergebnissen kommen will, würde ich dafür sicherheitshalber
          ebenfalls die CGI.pm vorziehen...

          Viele Grüße

          Andreas

        2. Hi,

          Perl lebt von Konventionen, nicht von Einschränkungen.

          Yep.

          Ich finde nicht, das dieser Rat aus einer Bierlaune heraus gegeben wird. Die Erfahrung zeigt, daß sich viele Anfänger schon schwer damit tun, einen gültigen HTTP-Header zu erzeugen. Das und noch viel mehr ist sehr leicht mit CGI.pm zu lösen (BTW: nebst Überprüfung ob ein Header schon ausgegeben wurde oder nicht).

          Hier mal zur Untermauerung: http://www.perlmonks.com/index.pl?node_id=51012
          Ein IMHO sehr guter »Artikel« mit Gründen, aus denen CGI.pm verwendet werden sollte.

          Ein Skript, das CGI.pm benutzt ist mit Sicherheit übersichtlicher, leichter zu verstehen und zu warten/erweitern als andere und das ist (für Anfänger) sicherlich sinnvoller als Server-Last (Wobei ich mir nicht sicher bin, in wie weit man wirklich Einbussen hat).

          Und wer sich um Serverlast sorgen mach soll halt CGI::Lite benutzen. Und wer Sorgen von wegen Performance hat, kann sich ja mal über mod_perl o.Ä. Gedanken machen.

          CU
          Arne "Heinz99" Bochem

      2. Hallo Stefan,

        • kein -w
        • kein use strict / kein my
        • kein use CGI (Querystrings werden mit veraltetem Code geparsed)
        • teilweise keine Überprüfung von Rückgabewerten (flock, close)
        • keine Einhaltung an gültige Konventionen

        Auch wenn strict zum guten Ton gehoert - aber wenn es wirklich soooo verpflichtend waere, warum ist es dann nicht laengst Default beim Perl-Interpreter?

        Da perl -e auch Perlcode von der Kommandozeile verarbeitet, wäre es sehr umständlich alle Variablen zu deklarieren, bzw. bei Verwendung kritischer Konstrukte 'strict' teilweise wieder abzuschalten (z.B. um symbolische Referenzen zu verwenden).
        Außerdem würden die meisten der richtig coolen JAPHs nicht mehr funktionieren ;-))

        Und "use CGI" ist auch noch kein Gesetz, das der liebe Gott gemacht hat, es ist nur eine der beliebtesten ewigen Stammtisch-Wiederholungen in den Newsgroups. Kein Zweifel - das CGI-Modul ist sinnvoll. Aber fuer ein Script, das nur ein einziges Formularfeld auszuwerten hat, moeglicherweise nicht. Denn jedes Modul-Laden erzeugt ja auch wieder Serverlast.

        Deswegen wird vom 'perlmaker' auch kein -w verwendet, da jeder Eintrag im 'error_log' (und davon kämen sicherlich etliche) ebenfalls den Server belastet, wie ich am eigenen Leib schon feststellen musste :-)
        Wenn es nur um die Ladezeit geht, kann man auch CGI::Lite verwenden, daß mit ca 27K (ein Großteil ist Dokumentation) doch angenehm lite ist :-). Denn spätestens wenn es sich bei dem einzelnen Forumularfeld um ein filefeld handelt, wird der GET&POST-code versagen. Genauso bei multipleselect, oder bei mehreren Checkboxen mit gleichem 'name'. Und wo wird dann mit 'perldoc CGI' auf welche Fragen geantwortet? *vbg*

        Ansonsten stimme ich dir durchaus zu. Die "Bausteine", die das Tool liefert, lassen sich wahrscheinlich noch verbessern.

        Die Bausteine sind imho nicht nur verbesserungsdürftig, sondern auch z.T. schlichtweg invalides Perl!

        Gruß AlexBausW

      3. Hallo Stefan,

        Auch wenn strict zum guten Ton gehoert - aber wenn es wirklich
        soooo verpflichtend waere, warum ist es dann nicht laengst
        Default beim Perl-Interpreter?

        Das Glaubensbekenntnis von Perl ist: "There is more than one way to do it."
        Nur: Perl ist ganz bewußt nicht auf Neulinge "optimiert", hat also keine
        "Defaultwerte", die ein Profi lästigerweise alle abschalten muß.
        Hätte es diese, dann hätte es wahrscheinlich nicht die Verbreitung, die es
        heute hat.

        Es gibt Sprachen, die sehr viel besser auf das Lernen des Programmierens
        hin optimiert sind - beispielsweise alles, was aus der Müsli-Richtung von
        Nikolaus Wirth kommt (PASCAL, Modula, ...).
        *Dort* sind dann die Defaults "strikt" - so strikt, daß diese Sprachen im
        Wettkampf um kommerzielle Verbreitung gegenüber den "wilden Hacker-Tools"
        wie C oder Perl untergegangen sind, weil es vielen Programmierern zu müh-
        sam war, um die entsprechenden Schranken (strict typing, Zwang zur Deklara-
        tion von Variablen etc.) herum zu programmieren.

        Eine DAU-freundliche Methode, Perl zu vermitteln, ist m. E. ein Widerspruch
        in sich selbst.
        Vor allem: Die Mentalität des Programmierers lernt man nicht dadurch, daß
        man glaubt, ein Tool würde einem signifikant viele Probleme abnehmen.
        Die meisten Probleme in Programmen resultieren aus Denkfehlern des Program-
        mierers. Und dieser läßt sich durch kein Tool ersetzen.

        Viele Grüße
              Michael

      4. Moin Stefan,

        Und "use CGI" ist auch noch kein Gesetz, das der liebe Gott gemacht hat, [...]

        oh doch, denn es steht in der PerlFAQ (perldoc -q 'CGI form')

        SCNR &

        Viele Gruesse,

        n.d.p.

  5. Moin

    Wie viel man bei diesem Verfahren Perl lernen kann, ist natuerlich fraglich.

    Ich ging bislang immer noch davon aus, dass ich ohne perl zu lernen diese Welt verlassen werde - lasse mich aber gerade belehren :-). Nachddme ich das Nützliche an reg exp schon mal verinnerlicht habe, dachte ich neulich mal, dass eine schöne Klicki-bunti-Umgebung das richtige wäre, um den Lernaufwand zu umgehen....

    Also einfach mal ausprobieren und dann mal hier die Meinung sagen ;-)

    ... und bin dabei u.a. auf http://www.perlscriptingtool.com/pst/ und http://www.solutionsoft.com/DL_PerlBuilder.htm gestoßen - und auf die Grenzen solcher Programme. Das Problem ist und bleibt das Problem, das wir hier von FP-Express etc. kennen: Vielleicht läuft da mal was, aber ob man sich sicher sein kann, dass es möglichst immer läuft --- [HILFE!!! SHOP FUNZT TROTZT FP-EXPRESS NICHT] war meine Assoziation ...

    Aber wenn doch jemand eine DAU-Perl-Entwicklungsumgebung kennt (incl. intensiver Mausunterstützung, Spracheingabetool, integriertem Server, all-perl-and-server-version-code-ausgabe und Translator Swen-deutsch->perlisch)... :-)))

    Viele Grüße

    Swen

    1. Hallo Swen!

      Aber wenn doch jemand eine DAU-Perl-Entwicklungsumgebung kennt (incl. intensiver Mausunterstützung, Spracheingabetool, integriertem Server, all-perl-and-server-version-code-ausgabe und Translator Swen-deutsch->perlisch)... :-)))

      Und wenn Du etwas gefunden hast, womit man wirklich etwas anfangen kann, dann lass es mich wissen.

      Was ich bisher gefunden hat eignet sich für den wahren Anfänger sowieso nicht, bei vielen wird von vorne herein darauf hingewiesen, dass man sich schon Vorkenntnisse in anderen Programmiersprache angeeignet haben muss, etc...

      Nein, so ein SELFPERL, der den Benutzer so gut an die Hand nimmt und führt, wie SELFHTML für HTML es tut, gibt es nirgends (bisher wenigstens)...

      Patrick

  6. Hallo,

    Erst mal schön, daß das Forum wieder offen ist, obwohl ich nun wieder weniger Zeit für die Arbeit haben werde, da mein alte Sucht wieder durchgebrochen ist, und ich ständig am Reloadbutton hänge (nein, nicht wirklich ;-)).

    fuer echte Perl-Programmierer ist so was natuerlich ein Fanal. Fuer Anfaenger aber ist es vielleicht eine sinnvolle Unterstuetzung. Oder?  Oder nicht? Vielleicht sagt ihr mal was ihr davon haltet. Es handelt sich um einen web-basierten, interaktiven Online-Editor fuer Perl-Scripts.
    Los gehts auf http://www.perlmaker.de/ (einfuehrende Infos). Der eigentliche Editor befindet sich unter http://www.perlmaker.de/perlmaker.htm. Der Editor unterstuetzt den User mit Makros, also partiellem Perl-Code fuer bestimmte Aufgaben, vor allem fuer CGI-Scripts.

    Nachdem ich jetzt schon in diversen Newsgroups und Foren die Werbung zum 'perlmaker' gelesen habe, musst ich es doch nun mal endlich ausprobieren.
    Der Perlmaker scheint allerdings kaputt zu sein, oder ich bin zu doof (ich glaube natürlich zuerst mal letzteres ;-) Als erstes öffnet er sich in einem für mich unfreundlichen, auf > 800x600 optimierten Frame. So kann zumindest ich den perlmaker nicht ohne verrenkungen nutzen (was mich natürlich wieder in die Arme meines Leib&Magen-Editors treibt :-)
    Zum Zweiten ist er nicht wirklich intuitiv. Wenn ich mit meinen NN4.73 auf irgendwas klicke passiert gar nichts!? Liegt es daran, daß man auch für einen Test erst mal Geld überweisen muss? Nein, es liegt daran, daß ich NN benutze. Mit dem IE geht es, bis auf das perlmaker-logo, welches nun genau über einem 'Funktions'-Link liegt! *arrggh*
    Arrggh auch, weil der produzierte Code (da schließe ich mich Kai an) nicht besonders gut ist (eher so wie meiner ;-), aber nicht wie er sein sollte :-( ). Dazu kommen Begriffsverwirrungen: print "Content-Type: text/html\n\n"; ist kein HTML-Header wie es auf dem Link zum Code steht, sondern gibt einen HTTP-Header aus, der den MIME-Typ des zurückgegebenen Dokuments übermittelt.
    Warum kein -w verwendet wird, erklärt sich, wenn man den Code mal ausprobiert:

    Datei anhängen

    #Aufruf: &file_append ("Pfad/Dateiname");

    sub file_append {
    if (open (DATEI, ">>$_[0]") != false){

    wenn erfolgreich geöffnet

    print "Erfolg";
    }
    else {

    wenn nicht erfolgreich geöffnet

    die $!;
    }
    close(DATEI);
    }

    ergibt folgenden Fehler beim Ausführen mit -w:

    Unquoted string "false" may clash with future reserved word at perlmaker.pl line
     2.
    Argument "false" isn't numeric in numeric ne (!=) at perlmaker.pl line 2.
    Erfolg

    Die Erklärung, wie man die Subroutine aufruft ist auch nicht hilfreich, da nicht erklärt wird, wie ich nun Daten übergeben kann, die in die Datei geschrieben werden sollen.

    Wie viel man bei diesem Verfahren Perl lernen kann, ist natuerlich fraglich. Aber andererseits sagen viele Praktiker, dass es am besten ist, wenn man sich vorhandenen Code nimmt und diesen dann anhand von Hilfen und Dokumentation selbstaendig anpasst. Insofern kann so ein Online-Editor vielleicht sogar wertvolle "Bausteine" liefern.

    Du hättest hier die Anführungszeichen um "wertvolle" setzen sollen, da die Bausteine imho nicht wertvoll sind. Dieser Perlmaker wirft imho bei einem Newbie mehr Fragen auf, als er löst.

    Also einfach mal ausprobieren und dann mal hier die Meinung sagen ;-)

    Imho wäre einem Newbie mehr mit einem Freeware-Editor und den entsprechenden Makros geholfen, als mit dem 'perlmaker'! Zudem sind die 50 Steine besser in ein Anfängerbuch investiert, nach dessen durchsicht sicherlich auch der letzte Newbie bereits am ersten Tag besseres Perl coden können sollte, als es der 'perlmaker' tut.
    Ich hoffe das ganze ist als meine Meinung rübergekommen, und daß dieser Link nicht in die Linksammlung wandert (aber dies müssen andere entscheiden :-)

    Gruß AlexBausW

    P.S.: Zu mehr Tests hab ich leider die Lust verloren, sorry :-) Außderdem ist es wieder an der Zeit, den Reload-button zu drücken ;-))
    P.P.S.: Zum Schluß musste ich feststellen, daß als Hilfe die Perlseiten von SelfHTML in einem neuen (für mich zu breiten) Fenster aufpoppen.

    1. Hallo AlexBausW!

      Erst mal schön, daß das Forum wieder offen ist,

      Und schön ist's, dass Du wieder da bist!

      Schöne Grüße,
      Patrick

      1. Hallo Patrick,

        Erst mal schön, daß das Forum wieder offen ist,

        Und schön ist's, dass Du wieder da bist!

        Da ja nicht mehr alles archiviert wird, kann ich (denke ich) ruhit hier antworten: (ich bitte um Zurechtweisung, falls dem nicht so sein sollte ;-)

        Vielen Dank für die nette Begrüßung. Es ist doch gleich ein ganz anderes Feeling hier, als man es in anderen Foren findet (auch im Usenet), und man kann es leicht vermissen :-)

        Gruß Alex

  7. Sup!

    Ein Perl-Maker ist ca. genau so klasse wie ein Virus-Construction-Kit.
    Zusammenklicken und anpassen ist -egal wie flexibel das Ding auch sein mag, ich probiere das natürlich NICHT aus ;-) - niemals so effizient wie selbermachen. Zumal, da man sich mit diesem Tool sicher auf unterstem Level bewegt, denn eine Referenz auf ein Array von Referenzen auf Arrays ist nichts, was man schnell mal erklären kann - jedenfalls nicht irgendwelchen Copy&Paster "Programmierern". Die sollen doch bitte PHP benutzen ]:-)

    Gruesse,

    Bio

    1. Hallo Bio

      Ein Perl-Maker ist ca. genau so klasse wie ein Virus-Construction-Kit.

      Fuer diese Wortschoepfung gehoerst du ja wirklich zum Ritter geschlagen ... ich find bloss das Schwert nicht - wo isses denn nur? ;-)

      Die sollen doch bitte PHP benutzen ]:-)

      Oh, und dabei ist PHP nicht mal von Microsoft. Bin mal gespannt, wann wir naehere Details von diesem neuen Feindbild von dir erfahren ;-)

      viele Gruesse
        Stefan Muenz

      1. Tach!

        Ein Perl-Maker ist ca. genau so klasse wie ein Virus-Construction-Kit.
        Fuer diese Wortschoepfung gehoerst du ja wirklich zum Ritter geschlagen ... ich find bloss das Schwert nicht - wo isses denn nur? ;-)

        Was meinst Du, Virus Construction Kit? Sowas gibt's wirklich - auch der juengste etwas bekanntere Wurm ist keine Handarbeit: http://www.heise.de/newsticker/data/pab-09.05.01-000/. Schliesslich unterscheiden sich die ganzen Mail-Wuermer ja nur minimal, das Prinzip ist immer dasselbe. Und wenn man ein Prinzip hat, kann man es auch einen Computer machen lassen. *g*

        So long

        1. Sup!

          Was meinst Du, Virus Construction Kit? Sowas gibt's wirklich - auch der juengste etwas bekanntere Wurm ist keine Handarbeit: http://www.heise.de/newsticker/data/pab-09.05.01-000/.

          Virus Construction Kits bzw. damals Virus Construction Sets genannt gab es schon zu Amiga-Zeiten. Ich habe zuhause in MS eine Diskette mit dem grossartigen Tool "Bootshop", dessen leider genial geschuetzter und mir nicht zugaenglicher Teil dem Intro der uns dieses tolle Tool gebracht habenden Cracker-Gruppe nach mindestens 60 verschiedene Bootsektorviren und ein Virus Construction Set enthalten soll.

          Vielleicht sollte ich mal probieren, ob ich nicht diese doofe Amiga-Diskette irgendwie mit PC lesen und rausfinden kann, ob da wirklich sowas drauf ist - oder ob die mich "Lamer" nur verarscht haben ;-)

          Gruesse,

          Bio

        2. hallo Roland,

          Und wenn man ein Prinzip hat, kann man es auch einen Computer machen lassen. *g*

          *fg* das wirft natürlich ein interessantes licht auf Bio und seine prinzipien ... wurde mozilla so zusammengeklick? ist es DIE wahrheit?

          Grüße
          Thomas

          1. Hi Thomas!

            Und wenn man ein Prinzip hat, kann man es auch einen Computer machen lassen. *g*

            *fg* das wirft natürlich ein interessantes licht auf Bio und seine prinzipien ... wurde mozilla so zusammengeklick? ist es DIE wahrheit?

            Hehe, zumindest koennte man mal einige der Beitraege in den Heise-Kommentarforen automatisieren. *g*

            So long

    2. Hallo Bio,

      Ein Perl-Maker ist ca. genau so klasse wie ein Virus-Construction-Kit.
      Zusammenklicken und anpassen ist -egal wie flexibel das Ding auch sein mag, ich probiere das natürlich NICHT aus ;-) - niemals so effizient wie selbermachen.

      ja ja, so arrogant haben wir vor ein paar Jahren auch auf die ersten HTML-Editoren reagiert. Und jetzt? Scharenweise kaufen die Leute Dreamweaver für schlappe 1000 Mark. (Was daran soviel kosten soll ist mir allerdings ein Rätsel..)

      Ich hacke nach wie vor alles in einen Text-Editor - weiss aber, dass andere mit den HTML-Editoren besser klarkommen.

      Ansonsten liebe ich so klare Meinungen - auch wenns nicht meine sind :-)

      Ciao  Wilfried