[1.17] Refactoring/Umbenennung Tag-Klassen

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.
Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: [1.17] Refactoring/Umbenennung Tag-Klassen

Beitrag von jwlighting » 02.01.2013, 21:45:34

Nur zur Info: Die Umbenennung der Taglibs fürs APFelSMS habe ich auch fertig.
Warte noch auf funktionierendes SVN - schaffen wir schon ;)

LG :)
Jan

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

Benutzeravatar
dave
Beiträge: 903
Registriert: 04.02.2011, 19:03:57
Wohnort: Berlin
Kontaktdaten:

Re: [1.17] Refactoring/Umbenennung Tag-Klassen

Beitrag von dave » 02.01.2013, 22:35:24

Alter Schwede: Da habe ich aber die nächsten tage zu tun, bin mit der Migration auf 1.16 noch nicht mal fertig ;)

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

Re: [1.17] Refactoring/Umbenennung Tag-Klassen

Beitrag von dr.e. » 02.01.2013, 23:54:36

Ja, das Refactoring ist umfangreich geworden, hat aber endlich einige Altlasten beseitigt.

@dave: der Umstieg ist trotz der vielen Stellen nicht ganz so tragisch. Habe heute 4 Projekte im einer halben Stunde migriert.

@Jan: wenn du magst, schicke mir deine Quellen und ich merge den Code.
Viele Grüße,
Christian

Benutzeravatar
jwlighting
Beiträge: 466
Registriert: 14.07.2010, 14:23:58
Wohnort: LK Oldenburg
Kontaktdaten:

Re: [1.17] Refactoring/Umbenennung Tag-Klassen

Beitrag von jwlighting » 03.01.2013, 19:03:54

@Jan: wenn du magst, schicke mir deine Quellen und ich merge den Code.
Gerne. Findest du im Anhang.
Schreib mich nach wie vor einfach bei Skype an, wenn du zeit für das SVN-Problem hättest.

LG :)
Jan
Dateianhänge
apfelsms_130103.tar.gz
APFelSMS v0.3-RC3 mit vereinheitlichter Taglib-Namensgebung
(17.52 KiB) 60-mal heruntergeladen

Menschen irren - Politiker sind Menschen.
Für den Norddeutschen ist 1kW = 2 Pfund Schlick.

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

Re: [1.17] Refactoring/Umbenennung Tag-Klassen

Beitrag von dr.e. » 04.01.2013, 08:39:59

Hallo Jan,

hab's heruntergeladen und den Code in's SVN gemerged.
Viele Grüße,
Christian

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

Re: [1.17] Refactoring/Umbenennung Tag-Klassen

Beitrag von TipTop » 07.01.2013, 11:46:36

dr.e. hat geschrieben: Das würde ich gerne zunächst diskutieren. Warum? Der Ansatz ist mir ehrlich gesagt zu sehr bei JAVA abgeschaut.
Ich habe mich ehrlich gesagt noch nie mit JSP auseinandergesetzt - wenn das also Java ähnelt, ist das wohl Zufall :)
dr.e. hat geschrieben:PHP hat mit seinen $_REQUEST/$_SERVER-Superglobals bereits einen für die Sprache üblichen Container für derartige Inhalte. Ich sehe keinen Sinn darin, dass ein Framework - unabhängig vom APF - dafür ein weiteres Konstrukt einführt. Für die konkrete Entwicklung kannst du - bezogen auf dein Beispiel - die genannten Superglobals befragen, für Unit-Tests im Setup einfach die gewünschten Werte einfüllen.
Die direkte Verwendung der Superglobals bindet einem zu stark an das HTTP, weshalb ich eine OO-Schnittstelle für den Zugriff auf Request-Daten für sinnvoll halte (bisher haben wir ja auch die Klassenmethoden des RequestHandlers den Superglobals vorgezogen).

Grüße
Nico

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

Re: [1.17] Refactoring/Umbenennung Tag-Klassen

Beitrag von dr.e. » 12.01.2013, 10:50:44

Hallo Nico,
Ich habe mich ehrlich gesagt noch nie mit JSP auseinandergesetzt - wenn das also Java ähnelt, ist das wohl Zufall :)
Sorry, dann liegt das einfach an mir, denn ich kenne beiden Welten sehr gut. ;)
Die direkte Verwendung der Superglobals bindet einem zu stark an das HTTP, weshalb ich eine OO-Schnittstelle für den Zugriff auf Request-Daten für sinnvoll halte (bisher haben wir ja auch die Klassenmethoden des RequestHandlers den Superglobals vorgezogen).
Die Bindung an HTTP sehe ich unkritisch, denn wir bauen mit dem APF schließlich Web-Applikationen und diese basieren zu 99% immer auf dem Layer-7-Protokoll HTTP. Ein valider Punkt ist jedoch die Bevorzugung des RequestHandler. Diesen habe auch auch tatsächlich deshalb vorgezogen, da ich mich dann nicht mehr um das Absichern des Zugriffs auf das $_REQUEST-Array kümmern muss. Allerdings war für mich weniger ein Grund die OO-Kapselung, denn der RequestHandler ist relativ weit von OO entfernt, sondern die Zugrifsssicherung.

Gut an der Idee finde ich, dass wir innerhalb von APFObject - was ggf. aber auch der falsche Ort sein kann, da reine Service-Klassen für den Zugriff auf eine Backend-Schnittstelle keinen Request brauchen (sollten) - eine Methode zum gesicherten Zugriff auf den Request haben. Nachteil sehe ich den Teil des Response-Managements, denn wenn wir im Datenmodell des APF einen Request einführen, muss konsequenterweise auch der Response eingeführt werden. Dann muss sich der Benutzer umsomehr mit HTTP beschäftigen, weil in der Bootstrap-Datei dann u.U. ein

Code: Alles auswählen

foreach($response->getHeaders() as $name => $value) {
   header($name. ': '. $value);
}
echo $response->getBody(); 
notwendig ist, was vorher einfach mit einem echo erledigt war.

Im Code-Block

Code: Alles auswählen

if (isset($this->request->query->id)) { //  __isset()
   unset($this->request->post->myLoginForm->UserName); // __unset()
} 
steckt mir etwas zu viel Magie (__get()). Hier wünsche ich mir explizite Methoden wie

Code: Alles auswählen

$this->request->getValue('id') 
oder

Code: Alles auswählen

$this->request->valueExists('id') 
Was ich an der zweiten Zeile schwierig finde ist die unterschiedliche Abbildung von POST/GET/QUERY. Das macht es im Gegensatz zum RequestHandler aufwändiger deine Applikation zu bauen. Wenn ich einfach den Request-Parameter haben will - egal wo er steht - hätte ich mit der vorgeschlagenen Vorgehensweise etwas Probleme. Sehe ich das richtig?

Was ich in Projekten oft anwende sind Input-Filter, die den Request entsprechend umschreiben und die Applikation vom externen URL-Layout nichts mitbekommt. Wie würde sich das auf die Http-API auswirken?
Viele Grüße,
Christian

Gesperrt

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast