Wie programmiere ich OOP & Moose? (Allgemeines zu Perl)

[thread]20205[/thread]

Wie programmiere ich OOP & Moose?

Leser: 16

Articles: hide open all | hide show old branches

+29 replies
hlubenow

2016-12-09 23:14

User since
2009-02-22
876 Artikel
BenutzerIn

Habe leider keine direkte Antwort auf Deine Frage (das vorweg).

Ich hatte mal so einiges in Python mit OOP geschrieben, und hatte mich gefragt, ob das auch mit Perls OOP (ohne Moose) geht. Als das tatsächlich ging, hatte ich aus meinen Notizen diese Seite dazu zusammengestellt. Wie gesagt reines Perl, ohne Moose.

Auf Deine Frage hin wollte ich nun nur mal mein erstes Beispiel (das ich bei OOP immer zuerst mache, z.B. auch in Java, C++ oder Lua) mit Moose machen. Ergebnis: Geht nicht.
Also, ich glaube, Moose ist nichts für mich: Groß, langsam, unkonventionell, offenbar auch unpraktisch.
Das, was ich normalerweise in OOP mache, geht auch mit reinem Perl (5). Wahrscheinlich sogar noch etwas schneller. Und ich glaube, auch nicht mit mehr Code.

Aber trotzdem viel Glück, wenn es unbedingt "modern" sein soll. ;)

modedit Splitted from Print/Tutorial/Slides/Videos zu Mouse+Moose in Deutsch msg #185748
Last edited: 2016-12-13 10:02:02 +0100 (CET)
- +9 replies
- Raubtier
  
  2016-12-10 03:12
  User since
  2012-05-04
  1076 Artikel
  BenutzerIn
  2016-12-09T22:14:38 hlubenow
  Auf Deine Frage hin wollte ich nun nur mal mein erstes Beispiel (das ich bei OOP immer zuerst mache, z.B. auch in Java, C++ oder Lua) mit Moose machen. Ergebnis: Geht nicht.
  
  Ähm, dass die Frage aber nicht zu deinem Beispiel passt, ist dir schon klar? In deinem Beispiel schreibst du ja auch
  
  Code (perl): (dl )
  
  1 2
  
  my $lamp = Lamp->new(); $lamp->showState();
  
  In dem verinkten SO-Artikel wird aber statt $lamp->showState(); nun nach Lamp->showState(); gefragt, das dann trotzdem auf das state einer konkreten Lampe zugreifen soll. Das ist nicht sinnvoll - wozu sollte man das auch wollen?
  
  Dein Beispiel dagegen ist ganz einfach in Moose:
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
  
  #!/usr/bin/perl package Lamp; use Moose; has 'state' => ( is => 'rw', default => 'off' ); sub showState { my $self = shift; print $self->state; print "\n"; } package main; my $lamp = Lamp->new(); $lamp->showState();
  
  Quote
  Also, ich glaube, Moose ist nichts für mich: Groß, langsam, unkonventionell, offenbar auch unpraktisch.
  Ich glaube, du hast nicht verstanden wie Moose funktioniert. Ich habe jetzt fast keine Moose-Erfahrung (da ich alles größere in C++ mache), aber dein Beispiel ist nun so einfach, dass ich da nicht verstehe, wo das Problem sein soll.
  - hlubenow
    
    2016-12-10 15:29
    
    User since
    2009-02-22
    876 Artikel
    BenutzerIn
    
    Raubtier
    Ähm, dass die Frage aber nicht zu deinem Beispiel passt, ist dir schon klar?
    
    Nein, war mir nicht klar, aber danke, daß Du es aufgeklärt hast.
    
    Raubtier
    Ich glaube, du hast nicht verstanden wie Moose funktioniert.
    
    Stimmt, hatte ich ja geschrieben, daß ich mich noch nicht mit Moose befaßt hatte.
    Aber wenn sich das von normalem Perl-OOP so einfach nach Moose übertragen läßt, wie Du es gepostet hast, dann könnte man das vielleicht auch mit den anderen Konstruktionen aus meinem Text so machen. Dann wäre man recht schnell da.
    
    Bitte nicht ärgern, wenn ich dieses oder jenes noch nicht verstanden hab'. Dazu ist man doch hier: Um Dinge über Perl zu lernen. ;)
  - +7 replies
  - hlubenow
    
    2016-12-12 18:53
    User since
    2009-02-22
    876 Artikel
    BenutzerIn
    
    Könntest Du noch bitte diese Syntax erläutern?
    
    Code (perl): (dl )
    
    print $self->state;
    
    In normalem Perl geht das ja nicht (wenn ich mich nicht irre).
    Wie macht Moose/Mouse daraus gültiges Perl? Bzw. was ist dort "$self"?
    "print $self" deutet auf Hash-Referenz. Aber wenn man eine Hash-Referenz bildet, geht die letzte Zeile hier nicht:
    
    Code (perl): (dl )
    
    1 2 3 4
    
    my %h = (state => "off"); my $href = \%h; print "$href\n"; # print $href->state;
    
    Das verwirrt mich irgendwie. Erweitert Moose Perl in einer Weise, daß daraus eine ganz andere Sprache wird?
    - +6 replies
    - Linuxer
      
      2016-12-12 19:41
      
      User since
      2006-01-27
      3891 Artikel
      HausmeisterIn
      
      Doch, das geht auch im normalen Perl. ->state ist ein ganz normaler Methoden-Aufruf im "normalen" objekt-orientierten Perl.
      
      Es wurde ein Attribut 'state' definiert. Mit ->state wird nun die Methode aufgerufen, die den Wert des Attributs ausliest und zurückliefert. Hier ist es nun so, dass diese Methode genauso heisst wie das Attribut selbst. Andere setzen auch "get_*"- und "set_*"-Methoden ein; dann wäre es ->get_state zum Abfragen und ->set_state( 'new value' ) zum neu Setzen.
      
      Beispiel für ohne Moose:
      more (7.5kb)
      
      Ein Objekt in Perl ist eine "blessed reference"; in meinem Beispiel enthält $foo eine Hash-Referenz, die mit "foo" eingesegnet wurde. Methodenaufrufe erhalten als erstes Argument immer entweder die Klasse (z.B. bei CGI->new()) oder das Objekt (z.B. bei $object->new) als erstes Argument.
      
      $self enthält also in aller Regel das Objekt, mit dem innerhalb der Methode gearbeitet werden soll.
      
      Am besten mal in die Tutorials zur Perl-OO reinschauen:
      
      http://perldoc.perl.org/perlobj.html
      http://perldoc.perl.org/perlootut.html
      Last edited: 2016-12-12 19:43:05 +0100 (CET)
      meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
      Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
      - +5 replies
      - hlubenow
        
        2016-12-12 21:36
        
        User since
        2009-02-22
        876 Artikel
        BenutzerIn
        
        2016-12-12T18:41:32 Linuxer
        Doch, das geht auch im normalen Perl. ->state ist ein ganz normaler Methoden-Aufruf im "normalen" objekt-orientierten Perl.
        
        Ach so, so einfach kann es sein. :)
        
        Ich hatte "state" jetzt nicht als Methode gesehen (sondern nur als Attribut), weil in Raubtiers Beispiel "state" ja nicht als Methode (mit "sub state {...}") definiert worden war. Das macht Moose dann wohl automatisch.
        
        +4 replies
        
        Gast janus
        
        2016-12-13 07:27
        
        Moin,
        
        über AUTOLOAD kannst Du das auch mit native Perl realisieren:
        
        Code (perl): (dl )
        
        1 2 3 4 5 6 7
        
        # Macht möglich, die Attribute als Methode abzufragen # Verändert NICHT die Attribute der Instanz, wenn Argumente sub AUTOLOAD{ my $self = shift; my $attr = our $AUTOLOAD =~ /(\w+)$/ ? $1 : undef; $self->{$attr}; }
        
        D.h., in der Anwendung kann ein namentlich genanntes Atribut als Methode betrachtet werden:
        
        Code (perl): (dl )
        
        1 2
        
        print $obj->name; # gibt Inhalt Attribute name aus
        
        Bei sog. Setter jedoch ist es oft so, dass eine Veränderung eines Attributes die Veränderung anderer Attribute nach sich zieht.
        
        PS: Was Moose mit AUTOLOAD am Hut hat, weiß ich nicht, aber ein weiß ich: AUTOLOAD ist eines der mächtigsten Werkzeuge in Perl. In meinem Framework hab ich eine ganze Factory über AUTOLAOD realisiert, damit werden beliebige Klassen und viel Code über eigene Methoden nur dann eingebunden, wenn sie tatsächlich gebraucht werden: zur Laufzeit.
        
        Alles Dinge für lange Winterabende ;)
        Last edited: 2016-12-13 09:35:24 +0100 (CET)
        
        +3 replies
        
        hlubenow
        
        2016-12-23 19:17
        
        User since
        2009-02-22
        876 Artikel
        BenutzerIn
        
        In der Dokumentation in "perldoc perlsub" lese ich zu AUTOLOAD Wörter wie "magically", "eval" und sogar "goto". Das klingt alles nicht sehr seriös, auch wenn es wahrscheinlich ziemlich praktisch ist.
        
        Das gehört also zu den höheren Perl-Künsten, dabei aber wohl eher zu den Dunklen Künsten. :)
        Last edited: 2016-12-23 19:18:15 +0100 (CET)
        
        +2 replies
        
        Gast janus
        
        2016-12-25 19:40
        
        AUTOLOAD hat mit eval, goto, magically überhaupt nichts zu tun.
        Last edited: 2016-12-26 07:25:05 +0100 (CET)
        
        hlubenow
        
        2016-12-26 14:48
        
        User since
        2009-02-22
        876 Artikel
        BenutzerIn
        
        Gelöscht (schon gut)
        Last edited: 2016-12-26 14:51:19 +0100 (CET)
- +2 replies
- GwenDragon
  
  2016-12-10 15:40
  
  User since
  2005-01-17
  14783 Artikel
  Admin1
  
  Wenn Moose zu fett ist, dann nimm Mouse.
  die Drachin Gwen
  
  Meine Perl-Artikel · perldev – verschiedene Perl-Versionen unter Windows starten
  - Linuxer
    
    2016-12-10 16:11
    
    User since
    2006-01-27
    3891 Artikel
    HausmeisterIn
    
    Als weitere Alternative fällt mir noch Moo ein.
    Inwieweit das in den Kanon von Moose und Mouse passt, habe ich jetzt nicht rausgesucht.
    meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
    Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
- +17 replies
- Gast janus
  
  2016-12-10 15:50
  
  Für mich ist Moose auch nichts (Sorry Gwen) weil:
  
  1. Wer OO und performant mit Perl entwickelt, braucht Moose nicht,
  2. und wer dieses Klischee braucht, sollte die Finger von Perl lassen.
  
  Meine Empfehlung zu Perl OOP
  Eric Foster Johnson: Perl Module
  
  Mitp Verlag ISBN 3-8266-0570-5
  
  http://perl.rolfrost.de/class.html
  http://rolfrost.de/ooptut.html
  Last edited: 2016-12-10 15:59:44 +0100 (CET)
  - +16 replies
  - lichtkind
    
    2016-12-26 15:01
    
    User since
    2004-03-22
    5697 Artikel
    ModeratorIn + EditorIn
    
    aber dir ist schon klar das ein Buch von 1998 kaum das wiedergibt was derzeit stand des CPAN's ist?
    Tutorien in der Wiki, mein zeug:
    kephra, baumhaus, garten, gezwitscher
    
    Es beginnt immer mit einer Entscheidung.
    - +15 replies
    - Gast janus
      
      2016-12-26 15:08
      
      2016-12-26T14:01:14 lichtkind
      aber dir ist schon klar das ein Buch von 1998 kaum das wiedergibt was derzeit stand des CPAN's ist?
      
      Ja. CPAN gleicht mittlerweile auch eher einer Müllhalde.
      
      MfG
      Last edited: 2016-12-26 16:07:31 +0100 (CET)
      - +14 replies
      - lichtkind
        
        2016-12-26 16:09
        
        User since
        2004-03-22
        5697 Artikel
        ModeratorIn + EditorIn
        
        zeug gabs schon immer anteilig das man umschifft, heute gibt wertungen und empfehlungsseiten. aber falls du sagen willst das die module schlechter werden kann ich nicht zustimmen
        Tutorien in der Wiki, mein zeug:
        kephra, baumhaus, garten, gezwitscher
        
        Es beginnt immer mit einer Entscheidung.
        
        +13 replies
        
        Gast janus
        
        2016-12-26 16:31
        
        2016-12-26T15:09:29 lichtkind
        zeug gabs schon immer anteilig das man umschifft, heute gibt wertungen und empfehlungsseiten. aber falls du sagen willst das die module schlechter werden kann ich nicht zustimmen
        
        Der Begriff überflüssig triffts wohl eher. Früher hab ich gerne auf CPAN gestöbert auf der Suche nach neuen Ideen. Diese Zeiten sind vorbei. Ob das Schlecht oder gut ist, möge jeder für sich selbst entscheiden.
        
        Ich hab mit Perl 3, mit Perl 4 und mit Perl 5 entwickelt. Major-Release 5 ist hoch entwickelt, die Grundlagen jedoch sind geblieben. Modern Perl hingegen ist eine hohle Phrase solange niemand moderne Anwendungen damit entwickelt. Das betrifft ebenso auch Frameworks wie Catalyst, Mojo und wie sie alle heißen. Was damit machbar ist, kann mein Framework auch machen -- abwärts kompatibel bis 5.6 und i.d.R. wesentlich einfacher mit native Perl.
        
        Eben das sind ja die Stärken von Perl, im Gegensatz zu PHP. Die meisten PHP-Programmierer wissen gar nicht, was sich hinter _toString() verbirgt: OOP/Overload nämlich und sowas kann Perl schon lange. Man muss nur richtig damit umgehen können. Genau das vermittelt meine Buchempfehlung.
        
        http://rolfrost.de/helloworld.html
        Last edited: 2016-12-26 18:25:37 +0100 (CET)
        
        +12 replies
        
        lichtkind
        
        2016-12-26 18:36
        
        User since
        2004-03-22
        5697 Artikel
        ModeratorIn + EditorIn
        
        sinnvolle emfehlungen gibt es unter anderem auf http://perltricks.com/
        
        manche nehmen sich die zeit zu vergleichen und teilen ihr wissen. es hat sich nur der kanal geändert. der grund warum CPAN so nützlich ist: die eintrittsschranke ist niedrig und konsequenz davon ist das da viel ist.
        
        und "hohle phrase" halte ich für zu scharf denn hier geht es um drei verschiednen dinge. zum einen gibt es eine natürliche evolution der werkzeuge und manches ist einfach heute technisch besser und für den teil ist es besser modern perl zu kennen als das buch von 1998.
        
        zum anderen gngs beim modern perl um neuere werkzeuge die ich gerne von ihrere anwendung trenne. denn selbst wenn ich bockmist mit was mache ist ein wekzeug dennoch modern wenn ich potentiell einfach damit was anständiges aufbauen kann.
        
        und nachvollziebarkeit war, wie du richtig schreibst, wichtiger teil von Perl. aber da gibt es dennoch einen tradeoff. du kannst nicht alles von handmachen und wenn du in der Gruppe programmeirst musst du auch zusätzliche sicherheitsvorkehrungen haben um blödsinn zu vermeiden. ich weiss sehr wohl das man sehr viel einfach elegant und spartanisch in core perl bekommt. aber die zeit sich was anzueignen und zu kommunizieren ist ein realer faktor. und die sahce mit ensprechenden Moose-funktionen ist halt das ich zum einen strukturen für grössere systeme schneller aufbauen kann und und gleichzeitig schabernack ausschliessen kann was mir auch später debugging zeit spart oder bugs aktiv vermeidet. alte schule ist nicht immer nur besser sondern am besten kennt man beides und kann abwägen.
        Tutorien in der Wiki, mein zeug:
        kephra, baumhaus, garten, gezwitscher
        
        Es beginnt immer mit einer Entscheidung.
        
        +11 replies
        
        Gast janus
        
        2016-12-26 19:34
        
        Meine Erfahrungen hab ich schon immer selbst gemacht. Eben weil CPAN mittlerweile so vollgemüllt ist, dass es nicht mehr zu gebrauchen ist. Von daher entwickle ich alle Module, die ich brauche i.d.R. selbst.
        
        Zum Entwickeln neuer Anwendungen mit meinem Webapplication-FW genügen oft schon Grundkenntnisse, für eine neue Anwendung brauchts ggf. ein HTML-Template und eine .pm-Datei, entweder als Klasse oder als Trait. Letztendlich sind maximal 3 Interface-Methoden zu schreiben, was darüber hinausgeht wird über eine Factory erledigt. Da ist nicht eine Zeile Code redundant.
        
        Das Argument, dass Moose OOP einfacher macht, betrachte ich hiermit als widerlegt. Sämtliche Moduldateien, die in meinem FW als native mod_CGI laufen, funktionieren ohne Änderungen als FastCGI und mit geringfügigen Änderungen unter mod_perl.
        
        Schöne Grüße für die restliche Weihnacht ;)
        
        +10 replies
        
        lichtkind
        
        2016-12-26 19:40
        
        User since
        2004-03-22
        5697 Artikel
        ModeratorIn + EditorIn
        
        Du ziehst dich auf die Anwendungsfälle zurück wo kleine Lösungen im Vorteil sind. Gut für dich aber da draussen gibt es noch eine Welt und nicht jeder kann alles selber schreiben.
        
        Frohe Weihnacht und ein gesegnete Festlichkeit.
        Tutorien in der Wiki, mein zeug:
        kephra, baumhaus, garten, gezwitscher
        
        Es beginnt immer mit einer Entscheidung.
        
        +2 replies
        
        Gast janus
        
        2016-12-26 19:53
        
        2016-12-26T18:40:53 lichtkind
        Du ziehst dich auf die Anwendungsfälle zurück wo kleine Lösungen im Vorteil sind. Gut für dich aber da draussen gibt es noch eine Welt und nicht jeder kann alles selber schreiben.
        
        Frohe Weihnacht und ein gesegnete Festlichkeit.
        
        Vermutlich unterschätzt Du die Mächtigkeit meines Frameworks. Hier ein Blick auf die
        
        http://rolfrost.de/editbin.html
        
        Routingtable und eine Klassen-Übersicht. Die Vielfalt ergibt sich daraus, dass einer Klasse auch ein beliebiges Interface per Konfiguration zugewiesen werden kann, außer die Klasse definiert bestimmte Interfacemethoden selbst.
        
        Ein neues Feature ist WWW-Authenticate
        http://rolfrost.de/wwwauth.html und http://rolfrost.de/wwwxauth.html
        
        womit sich beliebig viele Realms konfigurieren lassen ohne in die Webserver-Konfig eingreifen zu müssen. Für die Schnittstelle zu handelsüblichen mit htpasswd erzeugten Passwortdateien nutze ich ein Modul von CPAN was ich für meine Zecke umgebaut habe.
        
        Grüße an Alle !
        Last edited: 2016-12-26 22:30:14 +0100 (CET)
        
        hlubenow
        
        2016-12-26 22:50
        
        User since
        2009-02-22
        876 Artikel
        BenutzerIn
        
        Guest janus
        Vermutlich unterschätzt Du die Mächtigkeit meines Frameworks. Hier ein Blick auf die
        
        http://rolfrost.de/editbin.html
        
        Routingtable und eine Klassen-Übersicht.
        
        Dann bist Du rosti? Sag' das doch. ;)
        
        Gast janus
        
        2016-12-26 19:56
        
        2016-12-26T18:40:53 lichtkind
        Du ziehst dich auf die Anwendungsfälle zurück wo kleine Lösungen im Vorteil sind. Gut für dich aber da draussen gibt es noch eine Welt und nicht jeder kann alles selber schreiben.
        
        Mein FW unterstützt Teamarbeit/Arbeitsteilung auf sehr vielfältige Art und Weise.
        
        Frohe Weihnacht und ein gesegnete Festlichkeit.
        Last edited: 2016-12-26 22:30:40 +0100 (CET)
        
        +6 replies
        
        rosti
        
        2016-12-27 08:59
        
        User since
        2011-03-19
        3502 Artikel
        BenutzerIn
        
        2016-12-26T18:40:53 lichtkind
        Du ziehst dich auf die Anwendungsfälle zurück wo kleine Lösungen im Vorteil sind. Gut für dich aber da draussen gibt es noch eine Welt und nicht jeder kann alles selber schreiben.
        
        Da draußen hab ich vor Allem gelernt wie man's nicht machen sollte ;)
        
        In der Tat ist mein FW letztendlich ein Abbild von Erfahrungen über fast 20 Jahre. Im Produktivbetrieb laufen hunderte Einzelanwendungen für sieben Domänen über ein einziges (!) ausführbares Script. Hinzu kommen Webservices fürs Content-Management, Remote DB-Management und Remote Procedure Call für ein clientseitiges Kommandozeilen-Framework.
        
        Im Zuge dieser Entwicklung habe ich auch das hoffnungslos überalterte CGI.pm durch eine Eigenentwicklung ersetzt. Dieser Eigenentwicklung habe ich die Fähigkeit eingehaucht, verschiedene Content-Types parsen zu können. Gerade daran wird doch deutlich, dass da draußen die Entwicklung, trotz Multimedia, scheinbar stillsteht. Mein Parser kann also mehr als nur multipart/form-data und application/x-www-form-urlencoded, dafür sorgt ein Schichtenmodell und diese Layer sind modular austauschbar. In Fakt bestimmt nur der Client mit welchem Content-Type er die Daten sendet:
        
        http://rolfrost.de/content_type.html
        
        Vorausgesetzt, der Parser kennt ihn. Das alles habe ich unter Perl5 entwickelt und das hat die Bezeichnung Modern Perl sicher mehr verdient als Moose & Co. Sicher hab ich dafür Jahre gebraucht und Zeiten, die eine SW-Firma i.d.R. nicht bereitzustellen gewillt ist weil es billiger ist, Praktikanten und Entwickler auszubeuten. Ich hab übrigens hier gleich um die Ecke auch eine Firma die auf diese Art und Weise Profit macht. Dieser Firma hab ich mal angeboten, selbst als Praktikant, ihr sogenanntes Framework nach modernen Aspekten zu überarbeiten und meine Erfahrungen einzubringen. Der Code, den ich dort vorgefunden habe war eine Katastrophe trotz Moose oder wahrscheinlich gerade deswegen, hauptsächlich jedoch wegen dem mangelnden Verständnis des CTO für Objektorientierte Programmierung mit Perl5.
        
        Leute, lest die richtigen Bücher ;)
        
        Grüße an alle!
        
        +5 replies
        
        lichtkind
        
        2016-12-27 15:11
        
        User since
        2004-03-22
        5697 Artikel
        ModeratorIn + EditorIn
        
        Schade das du immer noch glaubst ich versteh dich nicht. Wenn magst schau dir Vorträge von mst an. Er hat die Erfahrung, schrckz vor keinem core hack zurück (wenn kein angebracht) und sieht auch was du meinst und findet tortzdem die Argumente für OO module und modern Perl. Nur weil du damit recht hast, daß man seine werkzeuge gut kennen und sie angessen einsetzen sollte, heisst das nicht das es auch einen guten anwendungsfall für Modern Perl gibt.
        Tutorien in der Wiki, mein zeug:
        kephra, baumhaus, garten, gezwitscher
        
        Es beginnt immer mit einer Entscheidung.
        
        +4 replies
        
        rosti
        
        2016-12-27 16:24
        
        User since
        2011-03-19
        3502 Artikel
        BenutzerIn
        
        Ach ich denk schon dass wir uns verstehen lieber Herbert.
        
        Nicht der Foto-Apparat macht die Bilder, sondern der Fotograf. Genauso ists mit Programmieren. Einer Webanwendung ist es nicht anzusehen, ob sie mit Moose & Co oder native Perl5 entwickelt wurde.
        
        Herzliche Grüße.
        
        rosti
        
        2016-12-28 07:38
        
        User since
        2011-03-19
        3502 Artikel
        BenutzerIn
        
        Ich hab hier mal den Sourcecode eines meiner Module offengelegt:
        
        http://rolfrost.de/mayatec.html
        
        Für die Berechnung der Datierungen werden weitere Module eingebunden, bei denen erfolgt die Fehlerbehandlung über Perls beliebtes Exception-Model. Das ganze Framework läuft in einem try/catch Block, was jederzeit einen definierten Zustand der Anwendung sicherstellt und vor Allem eine griffige Fehlerbehandlung: Für fehlerhafte Benutzereingaben die über AJAX reinkommen reicht ein die "Fehlermeldung"; ansonsten wird ein entsprechender Abschnitt in die gesamte Responsedatei eingebaut.
        
        Vom Umfang her sind es nicht einmal 100 Zeilen Perlcode, hinzu kommt das HTML-Template. Alles zusammen ist kompakt in einer Moduldatei untergebracht. Selbstverständlch erlaubt mein FW auch eine örtliche Trennung von HTML-Template und Perl-Code, was einer Arbeit im Team entgegenkommt.
        
        Sowohl für Perl als auch JS gibt es eine eigene kleine Template-Engine. Das ermöglicht einen einheitlichen Aufbau der jeweiligen Templates, lediglich die Platzhalter sind anders notiert bzw. gekennzeichnet. Der Grund dafür ist, dass beide TE's gleichzeitig ins Geschehen eingreifen.
        
        Es ist ein FW mit dem die Arbeit Spaß macht und Perl-OOP kein selbstherrliches Klischee ist sondern eine praktische Angelegenheit.
        
        Viele Grüße!
        
        +2 replies
        
        hlubenow
        
        2016-12-29 12:06
        
        User since
        2009-02-22
        876 Artikel
        BenutzerIn
        
        2016-12-27T15:24:25 rosti
        Nicht der Foto-Apparat macht die Bilder, sondern der Fotograf.
        
        Und nicht das Auto fährt, sondern der Fahrer? Wir leben in einer Zeit, in der gerade DAS bald anders sein könnte.
        
        rosti
        
        2016-01-01 13:04
        
        User since
        2011-03-19
        3502 Artikel
        BenutzerIn
        
        2016-12-29T11:06:18 hlubenow
        2016-12-27T15:24:25 rosti
        Nicht der Foto-Apparat macht die Bilder, sondern der Fotograf.
        
        Und nicht das Auto fährt, sondern der Fahrer? Wir leben in einer Zeit, in der gerade DAS bald anders sein könnte.
        
        Mag sein. Noch nie wurden Programmierer so ausgebeutet wie in der jüngsten Zeit.
        
        Was mein Framework != Moose betrifft:
        
        Es läuft auch als Single Page Application SPA:
        
        http://rolfrost.de/spa.html
        
        Die History werde ich noch verfügbar machen, morgen ist auch noch ein Tag ;)
        
        Herzliche Grüße an Alle, mit oder ohne Moose ;)

View all threads created 2016-12-13 09:58.