The Perl Jam 2 - Probleme in Perl betreffend Hash-Handling und CGI (Perl/CGI)

[thread]19932[/thread]

The Perl Jam 2 - Probleme in Perl betreffend Hash-Handling und CGI

Tags: perl5 CGI Ähnliche Threads

Leser: 18

Articles: hide open all | hide show old branches

+5 replies
borisd

2015-12-29 00:09

User since
2014-04-23
15 Artikel
BenutzerIn

Hallo,

gibt es hierzu Reaktionen aus der Perl-Community?
("The Perl Jam 2", CCC-Talk über Probleme in Perl betreffend Hash-Handling und CGI)

https://live.dus.c3voc.de/relive//32c3/7130/muxed....

Könnte man die hier zusammentragen?

Gruss
- +2 replies
- Relais
  
  2015-12-29 00:19
  
  User since
  2003-08-06
  2246 Artikel
  ModeratorIn
  
  Schaust Du hier: The Perl Jam 2
  Erst denken, dann posten --
  27. Deutscher Perl- u. Raku -Workshop (Termin wird noch gesucht) 2025 in München.
  
  Winter is Coming
  - borisd
    
    2015-12-29 00:25
    
    User since
    2014-04-23
    15 Artikel
    BenutzerIn
    
    habs auch grad gefunden.
    Scheint niemanden gross zu kratzen :-P
    
    Danke
- borisd
  
  2015-12-29 00:51
  
  User since
  2014-04-23
  15 Artikel
  BenutzerIn
  
  Der Mojolicious-Autor sagt was dazu:
  
  http://blogs.perl.org/users/joel_berger/2015/12/re...
- Gast janus
  
  2015-12-29 09:21
  Über Sinn und Unsinn von CGI.pm habe ich schon vor Jahren nachgedacht. Ich nenne es veraltet aus verschiedenen Gründen und zum Parsen von HTTP-Request-Parametern setze ich es schon lange nicht mehr ein.
  
  Vor Allem erscheint mir die Logik der Vermittlung zwischen application/x-www-form-urlencoded oder multipart/form-data in CGI.pm nicht schlüssig, weil das in CGI.pm mit der Request-Method verknüpft ist. So gibt es außer den genannten beiden Enctypes mittlerweile eine Reihe weiterer Enctypes wie z.B. application/json oder application/xml um nur zwei zu nennen. Ein Parser sollte also mit derartigen Enctypes umgehen können und das unabhängig von der Request-Methode.
  
  Wünschenswert ist daher ein von der Request-Method unabhängiger Layer welcher um beliebige Enctypes erweiterbar ist. Ob die Daten serverseitig aus STDIN oder QUERY_STRING gelesen werden ist eine ganz andere Sache, denn es gibt außer well known Request Methods wie GET, POST, PUT u.a. theoretisch unendlich viele Requestmethoden. Bspw. kann ein HTTP-Client seine Request-Methode ASDF nennen und einen Message Body mit einem proprietären Enctype senden der serverseitig aus STDIN gelesen wird.
  
  Mein Schichtenmodell zeigt die Unabhängigkeit und die universelle Verwendbarkeit. Es 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
  
  # 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' ){ # like c-eav } 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}; } else{ # Default Content-Type # Parameter: Name => [Value], application/x-www-form-urlencoded $self->{param} = $self->qparse( $self->rawdata ); } }
  
  Last edited: 2015-12-29 12:22:52 +0100 (CET)

View all threads created 2015-12-29 00:09.