[2.xx] Ideensammlung

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.
Well
Beiträge: 263
Registriert: 25.10.2009, 11:00:19
Wohnort: Beuren
Kontaktdaten:

Re: [2.xx] Ideensammlung

Beitrag von Well » 26.07.2011, 20:32:14

Das hatten wir an einer anderen Stelle schon mal diskutiert und ich bin mir immer noch nicht 100%-ig sicher, ob er beim Umgang mit dem APF-DOM-Baum entfernt werden kann. Meine ersten Tests mit PHP 5.1 haben gezeigt, dass es nicht funktioniert.
Stimmt: http://www.php.net/manual/de/language.o ... rences.php - Da war ich falsch informiert.

Megger
Beiträge: 1233
Registriert: 04.11.2008, 10:57:37

Re: [2.xx] Ideensammlung

Beitrag von Megger » 11.10.2011, 17:24:06

Unterstützung von Sockets beim ConnectionManager wäre super, sollte eigentlich kein großes Problem sein.

Code: Alles auswählen

localhost:/tmp/mysql5.sock
Beim MySQLx Handler ist dies kein Problem, da der Host einfach so an die mysql Funktion übergeben wird, aber beim MySQLi Handler wird aus dem Host ja der Port extrahiert, deswegen kann man dort keine Socket angabe machen, da wäre dann vielleicht ein optionaler Konfigurationsparameter für Sockets wünschenswert
Tutorial: Browsergame mit dem APF (Die ersten Parts handeln von Installation und Inbetriebnahme des APFs, deswegen sicherlich auch für alle Nicht-Browsergame-Programmierer interessant)

APF-Version
  • Entwicklung: 2.0
  • Produktiv: 1.15

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

Re: [2.xx] Ideensammlung

Beitrag von dr.e. » 13.10.2011, 10:43:40

Keine schlechte Idee. Zur Auflösung könnte man einen optionalen Parameter "Port" einführen, dann ist keine Extraktion mehr nötig. Ich nehme das in die Roadmap für 1.15 auf.
Viele Grüße,
Christian

Megger
Beiträge: 1233
Registriert: 04.11.2008, 10:57:37

Re: [2.xx] Ideensammlung

Beitrag von Megger » 13.10.2011, 11:28:32

Soll Port dann entweder für den Port oder für Socket verwendet werden?
Tutorial: Browsergame mit dem APF (Die ersten Parts handeln von Installation und Inbetriebnahme des APFs, deswegen sicherlich auch für alle Nicht-Browsergame-Programmierer interessant)

APF-Version
  • Entwicklung: 2.0
  • Produktiv: 1.15

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

Re: [2.xx] Ideensammlung

Beitrag von dr.e. » 13.10.2011, 13:24:21

Ich würde es so interpretieren:

TCP-Connection:

Code: Alles auswählen

[MySQL]
DB.Host = "localhost"
DB.Port = "3307"
DB.User = "root"
DB.Pass = "..."
DB.Name = "..."
DB.Collation = "utf8_general_ci"
DB.Charset = "utf8"
DB.DebugMode = "true|false"
DB.Type = "MySQLx"
Socket-Connection:

Code: Alles auswählen

[MySQL]
DB.Host = "localhost:/tmp/mysql5.sock"
DB.User = "root"
DB.Pass = "..."
DB.Name = "..."
DB.Collation = "utf8_general_ci"
DB.Charset = "utf8"
DB.DebugMode = "true|false"
DB.Type = "MySQLx"
Alternative ist natürlich, ein "DB.Socket" einzuführen, das als weitere Möglichkeit zu einer Kombination aus "DB.Host" und "DB.Port" genutzt wird.
Viele Grüße,
Christian

Megger
Beiträge: 1233
Registriert: 04.11.2008, 10:57:37

Re: [2.xx] Ideensammlung

Beitrag von Megger » 13.10.2011, 14:05:39

Wenn du von der Extraktion weg willst, dann muss es "DB.Socket" sein, weil ansonsten musst du den Host erst wieder auseinandernehmen, da bei einer mysqli Verbindung der Socket im Connect extra angegeben wird. Auch bei PDO müsste dort eine Extraktion stattfinden, nur bei "normalem" mysql nicht
Tutorial: Browsergame mit dem APF (Die ersten Parts handeln von Installation und Inbetriebnahme des APFs, deswegen sicherlich auch für alle Nicht-Browsergame-Programmierer interessant)

APF-Version
  • Entwicklung: 2.0
  • Produktiv: 1.15

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

Re: [2.xx] Ideensammlung

Beitrag von dr.e. » 13.10.2011, 19:30:02

Das ist korrekt. Lass uns das entsprechend bei der Implementierung beachten.
Viele Grüße,
Christian

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

Re: [2.xx] Ideensammlung

Beitrag von TipTop » 15.12.2011, 22:13:04

Screeze hat geschrieben:Achja einen Punkt hab ich vergessen:

Wie ich das so gelesen habe, bin ich nicht der einzige, der die ablage der konfigurationdateien nach dem gegebenen schema etwas "ungeschickt" findet.

Villeicht sollte man im Sinne der 2.x da doch nochmal drüber nachdenken.

Derzeitige Struktur:

Code: Alles auswählen

config/namespace/context
Wenn ich jetzt allerdings einen namespace ändern möchte, oder von einem projekt in ein anderes einsetzen möchte, wird das ab ein paar dateien echt mühsam alles einzeln zu kopieren. (Ich hab vor kurzem eine solche Änderung gemacht, waren ca 20-30 config dateien, die hälfte hab ich beim 1. durchlauf vergessen, weil ich ein paar ordner wohl nicht durchgeschaut habe)

Meiner Meinung nach sinnvoller wäre:

Code: Alles auswählen

config/context/namespace
Dann sind die einzelnen Contexte klar voneinander abgetrennt, aber trotzdem die namespace trennung noch sinnvoll gegeben.
Genau das selbe wünsche ich mir jetzt - wo meine Applikation langsam größer wird - auch. Hab diesen Thread jetzt nur überflogen, aber falls ich mich nicht täusche, wure auf diesen Punkt nicht näher eingegangen. Wird es eine Änderung diesbezüglich geben?



Für einige Module (die mit Datenbank arbeiten) muss ein Treiber/Handler angegeben werden. Nun sind im Config Ordner schon 3-4 Datein wo z.B. der MySQLi Handler definiert ist - bei einer Änderung, bspw. auf SQLLite-DB müssten nun doch einige Datei angepasst werden. Könnte man für den DB-Handler nicht eine globale Konfiguration einrichten, so wie es bei der core/database/connections.ini der Fall ist?

Grüße
Nico

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

Re: [2.xx] Ideensammlung

Beitrag von dr.e. » 15.12.2011, 22:29:19

Hi Nico,

dieser Punkt wurde bereits in Release 1.13 umgesetzt und aus 2.0 vorgezogen. Für die Beeinflussung des Schemas kannst du entweder die vorhandenen Provider wie unter http://adventure-php-framework.org/Seit ... r-Provider beschrieben konfigurieren (gilt z.B. für Context entfernen oder Environment-Fallback) oder einen neuen Provider schreiben (siehe http://adventure-php-framework.org/Seit ... g-Provider). Vorlage können die aktuell vorhandenen Provider sein. Hier könntest du z.B. die Methode BaseConfigurationProvider::getFilePath() überschreiben oder einen Schalter einbauen.

Effektiv lässt sich dieser Umstand also mit sehr wenigen Handgriffen ändern und ein "neuer" Provider in der Bootstrap-Datei wie unter http://adventure-php-framework.org/Seit ... d-Provider beschrieben registrieren.

Ich hoffe, das hilft dir weiter.
Viele Grüße,
Christian

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

Re: [2.xx] Ideensammlung

Beitrag von TipTop » 22.04.2012, 10:32:48

Ich habe vor Kurzem ja an dieser AjaxAPI gearbeitet und bin jetzt der Meinung, dass das doch ein ziemlicher Humbug ist. Wenn ich einen Ajax-Request anfordere, möchte ich auch einen Rückgabewert - nur sollte dieser halt mit JSON bzw. XML ausgezeichnet sein, damit ich in JavaScript leichter damit arbeiten kann. Dieses First-Template-Prinzip und die TagLibs lassen sich also selbst bei einem Ajax-Request perfekt verwenden. Wichtig ist nur, dass ich irgendwo in der Bootstrap-Datei festlegen kann, welches Ausgabeformat und welche Dateiendung für den Workflow verwendet werden soll.

Wie wär es, wenn man verschiedene Workspaces der start()-Methode des Frontcontrollers übergeben kann? Ich meine etwas in dieser Art:

Code: Alles auswählen

// include the pagecontroller
include_once('./apps/core/pagecontroller/pagecontroller.php');

import('core::frontcontroller', 'Frontcontroller');
$frontController = &Singleton::getInstance('Frontcontroller');

// WORKSPACES definieren
$workspaces = array(
    'default' => array(
        'contentType' => 'html',
        'mainTemplate' => array('myproject::pres::templates', 'main')
    ),
    'ajaxXml' => array(
        'contentType' => 'xml',
        'mainTemplate' => array('myproject::pres::templates', 'ajax_xml_main')
    ),
    'ajaxJson' => array(
        'contentType' => 'json',
        'mainTemplate' => array('myproject::pres::templates', 'ajax_json_main')
    ),
    'ajaxHtml' => array(
        'contentType' => 'html',
        'mainTemplate' => array('myproject::pres::templates', 'ajax_html_main')
    ),
    'xml' => array(
        'contentType' => 'xml',
        'mainTemplate' => array('myproject::pres::templates', 'xml_main')
    )
);

$frontController->start($workspaces); 
Ist der URL-Parameter workspace im aktuellen Request nicht vorhanden bzw. wird ein Workspace übergeben, der nicht existiert, dann wird automatisch der default-Workspace verwendet. Anhand vom contentType wird u.a. auch die Dateiendung für die Templates des Workspaces festgelegt. Hänge ich in der URL den Parameter ?workspace=ajaxJson an, dann wird dem oben angeführten Code zufolge ein Template in myproject::pres::templates mit dem Dateinamen ajax_json_main.json adressiert.



Derzeit ist die Dateiendung .html im Pagecontroller fest gecodet. Der Frontcontroller müsste also z.B. in der start()-Methode die Dateiendung vom angeforderten Workspace in der Registry speicheren. Die loadDesign()-Methode greift dann einfach auf die Registry und den dort abgelegten Wert zu und verwendet ihn als Template-Dateiendung.

Mit diesem Workspace-Mechanismus könnte man die GUI-Stärke des APF auch bei AJAX-Requests ganz normal verwenden. Man könnte beliebig viele Einstieg-/Main-Templates definieren und somit jeden erdenklichen Einsatzzweck abdecken. Ich denke das wäre ein wichtiger Punkt, denn derzeit scheint das APF ein bisschen zu sehr auf HTML fixiert zu sein. Klar ist HTML im Falle einer Web-Applikation das wichtigste Ausgabeformat, aber dennoch nicht das enzige. Ich kann in .html-Dateien zwar genauso XML und JSON Code unterbringen, aber im Falle eines AJAX-Request benötige ich ein anderes Main-Template als im Falle eines normalen Requests. Zudem erwarte ich in einer .html-Datei HTML-Markup und kein JSON. Der letzte Punkt mag jetzt zwar ziemlich kleinlich und unbedeutend klingen, dennoch sorgt er - denke ich - für eine bessere Verständlichkeit innerhalb einer Applikation.




So und jetzt noch was zu den bereits geplanten Features für 2.0:
Eine form:prefill Taglib zum einfachen Vorbefüllen von Formularfeldern.
Was kann man sich darunter vorstellen? Formulare lassen sich ja jetzt auch schon einfach über Document-Controller füllen!?


PHP 5 >= 5.3.0 Die seit PHP 5.3 verfügbaren Namensräume sollen die jetzigen ablösen.

Eine entsprechende __autoload() Funktion könnte dann die import() Funktion ersetzen.
Im PHP-Manual ist folgendes angeführt:
spl_autoload_register() bietet eine flexiblere Alternative zum automatischen Laden von Klassen an. Aus diesem Grund wird von der Verwendung von __autoload() abgeraten und diese Funktion könnte zukünftig als veraltet gekennzeichnet oder gar entfernt werden.

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

Re: [2.xx] Ideensammlung

Beitrag von dr.e. » 22.04.2012, 12:51:43

Hallo Nico,

die Workspace-Geschichte ist ein interessanter Ansatz, den ich bereits einige Male bei anderen Produkten gesehen habe. Noch flexibler scheint es mir die Evaluierung des auszuliefernden Content-Types an Hand des gleichnamigen Request-Header oder eines Request-Parameters zu evaluieren. Ich denke, es macht Sinn, das auf die Roadmap aufzunehmen und entsprechend nochmal zu diskutieren. Wenn du möchtest, kannst du unter http://wiki.adventure-php-framework.org/Roadmap eine kurze Notiz unter 2.0 mit entsprechender Verlinkung hierher eintragen.

Aktuell könntest du den Ansatz jedoch auch schon verfolgen - nur mit einem kleinen Umweg. Statt direkt dem Frontcontroller eine variable Anzahl an Templates mitzugeben übergibst du ein zentrales Template, in dem per Taglib entschieden wird (z.B. an Hand eines Request-Parameters), welches Template einzubinden ist. Damit erreichst du effektiv das gleiche.

Zweite Alternative ist eine Frontcontroller-Action zu schreiben, die sofern addressiert den AJAX-Request entgegen nimmt und sofern nicht addressiert einfach nicht ausgeführt wird. Statt dessen rendert der Frontcontroller dann die Standard-Seite. Innerhalb der Action kannst du ganz einfach den Page-Controller nutzen um Template-basiert eine Ausgabe erzeugen. Von diesem Ansatz geht auch die Idee der AJAX-API unter http://wiki.adventure-php-framework.org ... nd_das_APF aus - bis auf die Einschränkung, dass hier kein Page-Controller für das Rendering hinzugezogen wird. Das kann aber ganz einfach entsprechen ersetzt werden.
Was kann man sich darunter vorstellen? Formulare lassen sich ja jetzt auch schon einfach über Document-Controller füllen!?
Wir hatten vor einiger Zeit über das Binding von Formular-Inhalten zu einer Datenquelle gesprochen. Konkreter Anwendungsfall könnte hier sein, dass (Select-)Felder aus einer Konfiguration oder wieder andere aus einer Datenbank befüllt werden.
Im PHP-Manual ist folgendes angeführt:
Korrekt, deswegen ist das auch mit könnte formuliert. Bisher sind Namespaces - bzw. konkret das Autoloading - aus meiner Sicht noch nicht wirklich schön implementiert. Insofern haben wir bisher lediglich eine Ablösung der Funktionalität innerhalb von import() und die Einführung von Namespaces diskutiert. Alternativ dazu könnte import() auch durch ein konkretes use plus spl_autoload ersetzt werden.
Viele Grüße,
Christian

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

Re: [2.xx] Ideensammlung

Beitrag von TipTop » 25.04.2012, 18:21:10

dr.e. hat geschrieben:Noch flexibler scheint es mir die Evaluierung des auszuliefernden Content-Types an Hand des gleichnamigen Request-Header oder eines Request-Parameters zu evaluieren.
Hi, könntest Du das näher erläutern?

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

Re: [2.xx] Ideensammlung

Beitrag von dr.e. » 25.04.2012, 20:47:22

Hi Nico,

im Wesentlichen verstehe ich darunter die Unterscheidung der Templates durch Request-Header und/oder URL-Parameter. Damit hast du es für AJAX-Clients sehr einfach, die Unterscheidung zu forcieren, denn AJAX-Requests senden zumeist einen anderen Content-Type-Header.

Effektiv ist das nur noch eine zusätzliche, einfache Methode um die Unterscheidung der Templates zu treffen. Soweit jetzt klar?
Viele Grüße,
Christian

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

Re: [2.xx] Ideensammlung

Beitrag von TipTop » 26.04.2012, 16:27:48

Verstehe. Habs mal auf die Roadmap gestellt.



Bzgl. Coding-Stil würde ich noch vorschlagen, das PHP-End-Tag wegzulassen.

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

Re: [2.xx] Ideensammlung

Beitrag von dr.e. » 26.04.2012, 22:43:43

Verstehe. Habs mal auf die Roadmap gestellt.
Sehr schön!
Bzgl. Coding-Stil würde ich noch vorschlagen, das PHP-End-Tag wegzulassen.
Jep, das führe ich gerade bei jeder Datei, die ich anfasse ein. Solltest du einen Checkin haben, entferne einfach auch alle End-Tags der geänderten Dateien, dann sollten wir bald ein einheitliches Bild haben.
Viele Grüße,
Christian

Gesperrt

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast