CGI Alternative (Netzwerkprogrammierung und Netzwerke mit Perl)

[thread]19991[/thread]

CGI Alternative

Tags: perl5 Ähnliche Threads

Leser: 13

Articles: hide open all | hide show old branches

+7 replies
Gast janus

2016-02-19 13:34
Die in CGI.pm verbaute Logik passt nicht immer. Des Weiteren strebte ich eine Abstraktion der Layer an, grundsätzlich soll meine Framework-Instanz unabhängig vom gesendeten Content-Type eine einheitliche Methode $self->param('name') anwenden können ohne dass im Controller der Name des Layers (XML, JSON usw.) überhaupt namentlich auftaucht.

Unabhängig von Request-Method soll der Verpackungs-Layer entsprechend des im Request-Header gesendeten Content-Type automatisch geladen werden. Untenstehend ein Auszug aus meiner Klasse, der Code ist beliebig erweiterbar:
Code (perl): (dl )

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

# hier werden die jeweiligen Layer geladen sub _parse_rawdata{ my $self = shift; if( $self->{CONTENT_TYPE} eq 'multipart/c-eav' ){ require cEAV; $self->{eav} = cEAV->decode_eav( $self->rawdata ); $self->{param} = $self->{eav}->{param}; } elsif( $self->{CONTENT_TYPE} eq 'multipart/eav' ){ # coming soon } elsif( $self->{CONTENT_TYPE} eq 'multipart/form-data' ){ require ParseMultipart; $self->{STDIN}->seek(0,0); $self->{param} = ParseMultipart->parse_multipart( $self->{STDIN} ); } elsif( $self->{CONTENT_TYPE} eq 'application/json' ){ require JSON; my $json = JSON->new; $self->{json} = $json->decode($self->rawdata); $self->{param} = $self->{json}{param}; } elsif( $self->{CONTENT_TYPE} eq 'bserialize/av' ){ require bSerialize; my $bs = bSerialize->new; my $binary = $self->rawdata; $self->{param} = $bs->bin2av( \$binary ); } else{ # Default Enctype # Parameter: Name => [Value], application/x-www-form-urlencoded $self->{param} = $self->qparse($self->rawdata); } }
Nur malso als Anregung. Das Teil bewährt sich bereits seit einiger Zeit auf mehreren produktiven Domänen und einer nahtlosen Integration von XMLRPC, SOAP , Rest u.a. Webservices steht nichts mehr im Wege bei gleichzeitiger extremen Vereinfachung und Code-Reduzierung.

Die XMLRPC Klasse serverseitig sieht z.B. so aus, ihr könnt das gerne mal vergleichen mit dem was Wordpress-Entwicker veranstalten. Zusammen mit einen Kommandozeilen-FW ist die Qualitätssicherung multipler Domänen kein Thema mehr, Remote wird auf die komplette Konfiguration/Content zugegriffen und das ganze ist natürlich automatisierbar.

Schönes Wochenende ;)
Code (perl): (dl )

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

# Deserialisierung, Rückgewinnung der Datenstruktur # für den wahlfreien Zugriff: Schlüssel-Werte-Paare $self->param; my $in = $self->{CGI}{param}; my $code = delete $in->{code}; eval $code or die "Error Compile Code: $@\n"; my $methodname = delete $in->{methodname}; my $coderef = $self->can($methodname) or die "Unknown methodname '$methodname'\n"; # Mit in %$in verbleibenden Parametern # wird die namentlich übergebene Methode aufgerufen $self->{CONTENT} = $self->$coderef(%$in) || die "the return value is emty";
Last edited: 2016-02-19 13:53:29 +0100 (CET)
- +6 replies
- Gast janus
  
  2016-02-20 10:24
  
  Der Vorteil dieser Abstrakion: Allein der Client bestimmt die Art und Weise der Verpackung. Beispielsweise werden Formulardaten bei einem Legacy Submit mit dem Enctype application/x-www-form-urlencoded (Default) gesendet, via Ajax hingegen dieselben Daten aus demselben Formular als application/json verpackt => am serverseitigen Code ändert sich nichts.
  
  Damit ergibt sich eine neue Qualität in Entwicklung, Wartung und Pflege von Webanwendungen und letztendlich wird Zeit gespart.
  
  Und es spricht auch ein bischen für Perl, denn aus Erfahrung weiß ich, dass gerade solche vorausschauenden Entwicklungen in anderen Programmiersprachen nicht effizient zu machen sind (in PHP kaum eine Idee geboren sind die Funktionen wieder deprecatet).
  
  Leute, kümmert Euch um Perl. So http://handwerkzeugs.de/perl.html siehts aus und ihr könnt mir glauben, dass ich damit nicht gerade glücklich bin.
  
  Schönen Sonntag.
  Last edited: 2016-02-20 11:25:16 +0100 (CET)
  - +5 replies
  - pq
    
    2016-02-20 13:43
    
    User since
    2003-08-04
    12208 Artikel
    Admin1
    
    Guest janus
    Leute, kümmert Euch um Perl.
    
    Viele in diesem Forum kümmern sich in ihrer Freizeit, und wenn es die Arbeitgeberin möglich macht, auch im Job um Perl.
    Durch Workshop-Orga, durch Schreiben von Modulen und Tools, durch Schreiben von Patches (neudeutsch: pull requests). Durch Diskutieren und das Stellen der richtigen Fragen.
    Schau dir an, was auf github los ist. Es war nie einfacher, sich zu beteiligen. Und es macht Spass!
    In fast jeder Bewerbung findet sich heute ein Link aufs github-Profil. Und ja, die "Entscheider" schauen sich das tatsächlich an.
    
    Nutze deine Ideen, indem du damit auf andere zugehst. Wenn deine Ideen nicht angenommen werden, liegt das nicht an deiner Person, sondern evtl. schlicht daran, dass sie nicht verstanden werden. Da ist es an dir, das zu ändern und die Leute da abzuholen, wo sie sich befinden. Fragen und konstruktive Kritik ernstzunehmen.
    
    Den meisten Leuten, die an Projekten zusammenarbeiten, ist es egal, ob die andere Person Männlein, Weiblein, Trans ist; in Europa, Afrika oder der Antarktis lebt; ein Grünschnabel oder ein alter Sack ist; an einen Propheten oder an das Fliegende Spaghettimonster glaubt. Die einzigen Hindernisse sind evtl. Sprache und Zeitzonen.
    
    Ja, es gibt auch voreingenommene Leute. Es gibt Streit, das ist unvermeidlich. Manchmal wirds leider persönlich. Gerade darum brauchen wir mehr Leute, die sich konstruktiv einbringen und nicht nur ihr eigenes Ding machen und erwarten, dass alle das von alleine toll finden.
    Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
    lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
    - +4 replies
    - Gast janus
      
      2016-02-21 09:24
      
      Vielen Dank für Deine Ausführungen. Wir werden sehen, was das bringt. Wesentlich ist nicht zu zeigen, dass Perl eine tolle Programmiersprache ist, sondern zu zeigen, was man mit Perl Tolles machen kann (Zielorientierung).
      
      Zurück zum CGI.pm das schleppt ungezählte Altlasten mit sich rum und das seit Jahren. Da wird ein Haufen Code kompiliert der am Ende gar nicht gebraucht wird. Absolut unlogisch ist es, PUT/POST Daten in param('PUTDATA') bzw, param('POSTDATA') zu erwarten, wenn der Enctype nicht application/x-www-form-urlencoded ist.
      
      Logischer ist nach dem Standard CGI/1.1:
      1) stehen Daten/Parameter in STDIN, setzt der Webserver eine Umg. Variable CONTENT_LENGTH
      2) stehen Daten/Parameter in STDIN ist das unabhängig von der Request-Methode
      3) Parameter können unabhängig von der Request-Methode in QUERY_STRING vorhanden sein
      4) wie Parameter zu parsen sind ist nicht Bestandteil des Standards, das legt höchstens der gesendete CONTENT_TYPE fest
      
      CGI.pm räumt STDIN gnadenlos ab, im Fall des Default Content-Type, gibt es überhaupt keine Möglichkeit, an die gesendeten Daten heranzukommen. Es sei denn die Daten sind entsprechend Default serialisiert.
      
      Aus diesen Gründen sollte ein Parser einen von Request-Methode unabhängigen und ebenfalls vom Content-Type unabhängigen, also unbedingten Zugriff auf die gesendetetn Daten erlauben. Hierzu kopiert mein eigenes Modul die Daten von STDIN nach IO::String.
      
      Was übrigbleibt ist ein Parsen entsprechend des gesendeteten Content-Type. Und von der Logik her liefert param() False, wenn der Content-Type: application/octet-stream ist.
      
      Aus Kompatibilitätsgründen wird bei fehlendem Content-Type ebenfalls der bisherige Default angenommen. So habe ich meine Eigenentwicklung xCGI.pm genannt und das Erste was auffällt ist ein spürbarer Ruck der Performance nach oben ;)
      
      Schönen Sonntag.
      Last edited: 2016-02-21 09:56:01 +0100 (CET)
      - +3 replies
      - pq
        
        2016-02-21 13:15
        
        User since
        2003-08-04
        12208 Artikel
        Admin1
        
        ich verstehe nur die hälfte; leider ist das wie immer grösstenteils theorie, da dein code eben nicht öffentlich ist.
        
        aber du kritisierst hier ein modul, was gerade aus dem core geflogen ist. ich würde daher zumindest den vergleich mit alternativen erwarten.
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
        
        +2 replies
        
        Gast janus
        
        2016-02-21 16:38
        
        bischen mehr Hintergrund: http://handwerkzeugs.de/parser.html
        
        Im Wesentlichen gings mir um die Integration von RPC+Webservices in mein Framework. Die Akzeptanz erweiterter Content-Types im Request führt letztendlich dazu, dass für RPC+ keine Extrawurst gebraten werden muss.
        
        Im nächsten Schritt machte ich Remote-Procedure-Calls zu Methoden der Framework-Instanz. Das ist echtn Hack, auf der lokalen Kommandozeile hab ich nun Vollzugriff (CRUD) auf die gesamte Konfiguration meiner Domänen und weil das ein multidomain FW ist, läuft das alles über einundieselbe Subklasse main::RPC auf dem Server.
        
        Da hab ich schon lange darüber nachgedacht, aber das hat sich gelohnt und sowas von ;)
        In Richtung Qualitätssicherung sind das Entwicklerwerkzeugs von denen Andere nur Träumen können.
        
        Story: http://handwerkzeugs.de/xmlrpc.html
        
        PS: Ich bin gespannt auf Legacy Alternativen zu CGI.pm!
        Bis dann ;)
        
        Gast AuchGast
        
        2016-02-22 14:41
        
        Habe gerade mal mit Rolf Rost zu telefonieren versucht um mein Interesse an seinem Framework zu bekunden.
        Gesprächsergebnis:
        Er schreibt hier nicht (in keinerlei Foren ist er aktiv) und zu seinem Framework gibt er telefonisch keine Auskünfte - auch nicht zum Preis.
        
        Hmmm - seltsames Geschäftsgebaren ...
        Last edited: 2016-02-22 15:38:01 +0100 (CET)

View all threads created 2016-02-19 13:34.