Thread [XML::Parser] junk after document element at...
(23 answers)
Opened by bianca at 2015-02-05 18:26
Natürlich verwende ich auch Module von CPAN. Meine eigenen Module implementieren im Framework nur noch Methoden des FW-Interface. Untenstehend der CODE für den Webservice Sonnenaufgang, die Interface-Methode heißt in diesem Fall control:
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 35 36 37 38 39 40 41 42 43 44 45 46 sub control{ my $self = shift; die "Request-Methode nicht unterstützt\n" if $ENV{REQUEST_METHOD} ne 'GET'; if( $self->param('year') && $self->param('month') && $self->param('day') && $self->param('long') && $self->param('lat') ){ my $year = $self->param('year') || ''; my $month = $self->param('month') || ''; my $day = $self->param('day') || ''; my $long = $self->param('long') || ''; my $lat = $self->param('lat') || ''; my $tz = $self->param('tz') || 0; my $dst = $self->param('dst') || 0; # CORS Header $self->header( 'Content-Type' => 'text/plain; Charset=UTF-8', 'Access-Control-Allow-Origin' => '*', ); # CPAN Module Astro::Sunrise my($sunrise, $sunset) = sunrise($year,$month,$day,$long,$lat,$tz,$dst); $sunrise = sprintf("%02d:%02d", split(":", $sunrise)); $sunset = sprintf("%02d:%02d", split(":", $sunset)); if( my $obj = $self->param('obj')){ $self->header('Content-Type' => 'text/javascript'); $self->{CONTENT} = XR::xr("%obj% = { 'rise': '%sunrise%', 'set': '%sunset%' }", { obj => $obj, sunrise => $sunrise, sunset => $sunset }); } else{ $self->{CONTENT} = sprintf('{"sunrise": "%s", "sunset": "%s"}', $sunrise, $sunset); } } else{ die "Unbekannter Parameter\n"; } } PS: Zum Programmieren von Webservices brauchst Du keine speziellen Module von CPAN. Was Du brauchst ist ein Serializer, der Client- wie Serverseitig kompatibel ist bzw. einen Parser für JSON oder XML. Und ein bischen Grundlagenwissen zu HTTP und um den Dateibegriff, den Niklaus Wirth um 1980 geprägt hat: Dateien sind Sequenzen. Alles Weitere ist Programmierer-Logik und eine analytische Denkweise, die idealerweise bereits vor dem Entwickeln ansetzt. Nochwas: SOAP, REST, RPC sind in meinem Framework unter einem Dach vereint. Meine Webservices sind z.T. proprietär aber sie genügen jeder gestellten Anforderung und sind deswegen gleichermaßen unkompliziert. Wer JSON haben will, kriegt JSON, wer XML haben will, kriegt XML und wer was anderes haben will, kriegt was Anderes. Aber warum sollte ich die Request Methode DELETE verwenden, wenn auf dem Server ein Datensatz gelöscht werden soll? Abstrakt gesehen, brauchen wir serverseitig nur eine Datenstruktur im Hauptspeicher, die z.B. so aussehen könnte: und eine solche Datenstruktur kann mit jeder beliebigen Request-Methode gesendet werden. Es ist total nebensächlich, auf welche Art und Weise die Daten für den Transport verpackt werden, das kann XML sein, muss aber nicht, Storable::freeze() geht genausogut. Ohne von der Request-Methode abhängig zu sein oder diese zu ändern, nehme ich Diesselbe Methode um eine neue Seite online zu bringen. Der serverseitige Controller kriegt dann z.B. sowas: Code (perl): (dl
)
1 2 3 4 5 6 7 8 9 10 11 $hunt = { control => { action => 'insert', url => '/boo.html' }, data => { title => 'A Dog named Boo', descr => 'Mein Hund Boo ist mein bester Freund', body => '<h2>Meine Erlebnisse mit Boo</h2><p>Boo war ein Findelkind, als ich ihn fand, war er noch ein Säugling...</p>' } }; Meine HTTP-Webservices können auch mit Binärdaten umgehen, mit Sicherheit ist die Verpackung dann jedoch nicht XML. Einheitliche Request-Methode, einheitliche Datenstrukturen nach dem Muster Entity Attribute Value. Für eigene Verwendugn reicht sogar der HTTP-Response-Status-Code: 200 OK wenn serverseitig alles gutgegangen ist. SOAP: Schrott. REST: Verwirrend. Wikipedia: Da steht viel Müll. RPC: Kann ich doch machen, wie ich will, Stichwort Best Practice. WDSL: Mein Gott, wer braucht denn sowas. Perl: Damit kann ich alles machen ;) Last edited: 2015-03-17 11:44:01 +0100 (CET) |