tools::http - Refactoring

Dieser Bereich dient dazu, neue Features zu diskutieren und für die Entwicklung zu dokumentieren. // This area is dedicated to new features including proposals and documentation.
Gesperrt
TipTop
Beiträge: 193
Registriert: 25.08.2011, 22:37:08
Wohnort: Klagenfurt, Österreich
Kontaktdaten:

tools::http - Refactoring

Beitrag von TipTop » 22.09.2012, 20:34:09

Hallo allerseits,

zum Hintergrund: Ich benötige für den Extension-Manager meines CMS gerade ein Tool, mit dem sich Http-Requests erzeugen lassen, um über das Admin-Control-Panel Erweiterungen möglichst komfortabel vom Extension-Directory (befindet sich auf webrex.org) aus im CMS zu installieren.

Ich dachte an folgender Verzeichnisstruktur:

Code: Alles auswählen

tools/http/
        adapters/
            CUrlAdapter.php
            SocketAdapter.php
            Adapter.php
        Client.php
        Request.php
        Response.php
Die Klassen Request und Response sind lediglich Datenbehälter, welche die Werte von Http-Requests und -Responses beinhalten. Bei den Werten handelt es sich um diejenigen, die in der HTTP1.1-Spezifikation definiert sind. Die Klasse Client wäre etwa vergleichbar mit einem Webbrowser - ein Client-Objekt führt Requests aus und gibt die Server-Antwort in Form eines Response-Objektes zurück. Für die Server-Kommuniktation verwendet Client einen Adapter (CUrlAdapter -> Standard, ist die CUrl-Extension nicht verfügbar, wird auf den SocketAdapter zurückgegriffen). Adapter.php ist ein Interface.

Ein einfacher Request wäre mit dem Http-Tool dann folgendermaßen realisierbar:

Code: Alles auswählen

<?php
$request = new Request;
$request->setProtocol('http') // od. https
            ->setDomain('www.adventure-php-framework.org');
// abgesehen von Protokoll und Domain können wie schon gesagt auch sämtlich HTTP1.1-Header-Zeilen gesetzt werden

$client = new Client;
$client->executeRequest($request);
$response = $client->getResponse();
?>
Über Client::setAdapter(Adapter $adapter) kann man alternativ zu CUrl- und Socket-Adapter einen anderen Adapter für die Server-Kommunikation verwenden.
Request und Response implementieren zudem die toString-Interzeptermethode - wird diese proviziert, erhält man eine wohlgeformte Zeichenkette, die HTTP-Request bzw. -Reponse repräsentiert.

Was haltet Ihr davon?

Benutzeravatar
dr.e.
Administrator
Beiträge: 4533
Registriert: 04.11.2007, 16:13:53

Re: tools::http - Refactoring

Beitrag von dr.e. » 23.09.2012, 10:22:54

Hallo Nico,

ich finde die Idee sehr schön. Ideal wäre noch, wenn wir alle bisherigen Funktionen des RequestHandler auch dort abbilden können.
Viele Grüße,
Christian

TipTop
Beiträge: 193
Registriert: 25.08.2011, 22:37:08
Wohnort: Klagenfurt, Österreich
Kontaktdaten:

Re: tools::http - Refactoring

Beitrag von TipTop » 25.09.2012, 10:41:26

Der aktuelle Stand: http://www.webrex.org/http.zip

In Request habe ich momentan keine statischen Methoden wie in RequestHandler definiert - da ja Informationen über den aktuellen Request in einem Controller immer nützlich sein können und auch nur dort erhältlich sein sollten, könnte man ja im Pagecontroller ein Request-Objekt erstellen und dieses über die Document-Instanzen in die Controller injizieren. Über Request::setParameters(array $parameters) lässt sich das _REQUEST-Array im Request-Objekt setzen.

Benutzeravatar
dr.e.
Administrator
Beiträge: 4533
Registriert: 04.11.2007, 16:13:53

Re: tools::http - Refactoring

Beitrag von dr.e. » 25.09.2012, 23:07:07

Hi Nico,

danke für deine Arbeit! Ich schau mir den aktuellen Stand in den nächsten Tagen an - leider ist es grade etwas stressig.
Viele Grüße,
Christian

Benutzeravatar
dr.e.
Administrator
Beiträge: 4533
Registriert: 04.11.2007, 16:13:53

Re: tools::http - Refactoring

Beitrag von dr.e. » 29.09.2012, 21:18:03

Hallo Nico,

ich habe mir deine Implementierung angesehen und hier ist mein Feedback dazu:

Request.php
  • Die Implementierung scheint zu wenig allgemeingültig zu sein. Cookies sind Bestandteil von Header-Informationen, insofern wäre es möglich diese auch als solche zu modellieren. Mein Vorschlag ist, Cookies als Header zu behandeln und für bekannte Header Convenience-Methoden zu definieren (Cookies, User-Agent, ...).
  • Der Request unterstützt POST nicht vollständig. Bei POST-Requests werden die Daten per MIME-Typ text/x-www-form-urlencoded im Body übergeben. Dies ist IMHO wichtig zu implementieren.
  • $domain sollte im Sinne von RFC2616 eher $host heissen, da es den Host-Header repräsentiert - ebenfalls als Header modellierbar.
  • Bei den "if ($i < count($params)" und "if ($i < count($cookies)" Statements fehlt noch eine schließende Klammer.
Response.php
  • Die Implementierung sollte ebenso etwas generischer auf Header und Body abstrahiert werden.
Client.php
  • "Adapter" würde ich HttpAdapter nennen, das ist etwas sprechender.
Adapter.php
  • Ich bin mir nicht sicher, ob ich isAvailable() auch in das Interface aufgenommen hätte. Ist es nicht geschickter, das als System-Voraussetzung zu dokumentieren?
  • "Request" und "Response" sind von anderen Frameworks bereits belegt. Vielleicht könnten wir hier ein Präfix einführen um die Interoperabilität sicher zu stellen (z.B. HttpRequest).
  • executeRequest() sollte für mich auch den Response zurück geben. Das spart IMHO einen Methoden-Call und macht die API des Client lesbarer. In etwa so: rufe den Client mit einem Request auf und erhalte einen Response. Wenn ich beim Bäcker "2 Brezen" über die Theke rufe kommen diese ja auch (nach dem Bezahlen) direkt zurück und ich muss nicht nochmal sagen "jetzt gib mir bitte meine 2 Brezen her". ;)
Viele Grüße,
Christian

TipTop
Beiträge: 193
Registriert: 25.08.2011, 22:37:08
Wohnort: Klagenfurt, Österreich
Kontaktdaten:

Re: tools::http - Refactoring

Beitrag von TipTop » 30.09.2012, 12:40:16

Vielen Dank fürs Code-Review :)
Mein Vorschlag ist, Cookies als Header zu behandeln und für bekannte Header Convenience-Methoden zu definieren (Cookies, User-Agent, ...).
Die Implementierung sollte ebenso etwas generischer auf Header und Body abstrahiert werden.


Also sowas wie addHeaderField($name, $value) und getHeaderField($name)? Welche Header würde das betreffen?

Benutzeravatar
dr.e.
Administrator
Beiträge: 4533
Registriert: 04.11.2007, 16:13:53

Re: tools::http - Refactoring

Beitrag von dr.e. » 30.09.2012, 21:55:39

Hi Nico,
Also sowas wie addHeaderField($name, $value) und getHeaderField($name)?
Genau. Ich würde es vielleicht als getHeader(), setHeader() und appendHeader() formulieren.
Welche Header würde das betreffen?
Grundsätzlich zunächst alle. Für spezielle und häufig genutzte Header kannst du dann noch Convenience-Methoden wie z.B. setContentType(), getContentType() implementieren, die intern einfach setHeader() und getHeader() nutzen.
Viele Grüße,
Christian

TipTop
Beiträge: 193
Registriert: 25.08.2011, 22:37:08
Wohnort: Klagenfurt, Österreich
Kontaktdaten:

Re: tools::http - Refactoring

Beitrag von TipTop » 23.10.2012, 17:24:20

Sorry dass ich mich nun länger nicht gemeldet hab - war in die letzten Wochen etwas in Prüfungsstress.

HttpRequest und HttpResponse verfügen nun über die Methoden...
  • addHeader($name, value)
  • getHeader($name)
  • getHeaders()
  • removeHeader($name)
  • removeHeaders()
Diese Methoden habe ich nun in eine Basisklasse ausgelagert, von der HttpRequest und -Response erbt. HttpItem nenne ich die Basisklasse derzeit - welchen Klassennamen würdest Du verwenden?

Benutzeravatar
dr.e.
Administrator
Beiträge: 4533
Registriert: 04.11.2007, 16:13:53

Re: tools::http - Refactoring

Beitrag von dr.e. » 23.10.2012, 23:24:53

Hi Nico,

schön wieder von dir zu hören. Hoffe du hast die Prüfungen gut überstanden?
HttpItem nenne ich die Basisklasse derzeit - welchen Klassennamen würdest Du verwenden?
Hmm, das ist nicht ganz so einfach. Vielleicht HttpHandle oder HttpExchange. Letzteres habe ich unter http://stackoverflow.com/questions/3253 ... stresponse gefunden und finde das Naming nicht schlecht.

EDIT: ganz überlesen: HttpTransaction finde ich am besten. :)
Viele Grüße,
Christian

TipTop
Beiträge: 193
Registriert: 25.08.2011, 22:37:08
Wohnort: Klagenfurt, Österreich
Kontaktdaten:

Re: tools::http - Refactoring

Beitrag von TipTop » 25.10.2012, 12:33:27

Hallo Christian,

ich hab jetzt - denk ich mal - soweit alle von dir angesprochenen Punkte umgesetzt. Schau bitte wenn Du Zeit hast mal drüber: http://www.webrex.org/http.zip

Benutzeravatar
dr.e.
Administrator
Beiträge: 4533
Registriert: 04.11.2007, 16:13:53

Re: tools::http - Refactoring

Beitrag von dr.e. » 25.10.2012, 20:35:15

Hi Nico,

habe mir die Files gezogen und nutze die Zeit morgen im Zug. Melde mich an dieser Stelle wieder mit einem Feedback.
Viele Grüße,
Christian

Gesperrt

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast