[Chr!s]

Morgen,
derzeit bin ich in meinem Framework an einen recht fortgeschrittenen Punkt angekommen, zur Zeit befasse ich mich mit dem umschreiben der URIs mittels htaccess und mod_rewrite. Alle Anfragen, die keine Datei sind und kein Ordner (also nicht existieren) werden auf die index.php umgeleitet, in dann die URIWrapper Klasse die URI ausseinander nimmt und entsprechende Teile zurückgibt.

Nun soll das Framework ja für alle möglichen Einsatzgebiete bereitgestellt werden (es könnte damit z.B. ein Forum realisiert werden, aber auch ein Blog, oder eine ganz normale Informationsseite). Dabei möchte ich den Benutzer des Frameworks gerne entscheiden lassen, wie denn nun die umgeschriebenen URIs aussehen können, und dazu brauche ich denke ich mal eure Hilfe.

Mir fehlt die Idee zum Ansetzen für die Konfigurierbarkeit dieses Features. Wie man URIs umschreibt und auswertet ist hier nicht mein Problem, das ist schon längst implementiert.

; URI Configuration
[URI Configuration]

; Should the application use rewritten URIs like /module/action/parameter/
; or do you prefer the normal URI ?module=module&action=action&parameter=parameter?

rewriteURIs = "true"

; If URIs should be rewritten, you can define here a pattern the
; URI should look like. Use here wildcards like {param1} {param2} {param3} ..
; ( This could result for example in articleID,articleTitle-extraParameter )

rewritingPattern = "{param1},{param2},{param3}"

; If URIs should contain a trailing slash, this option must be set to true
; If you don't want trailing slashes, set this option to false.
; (This functionality is only efficacious if rewriteURIs is set to true.)

trailingSlash = "true"

So sieht das ganze derzeit in der fürs URIRewriting abgekapselten Konfigurationsdatei aus. Mir geht es hier vorallem um den rewritingPattern. Das Framework kann ja im vornherein nicht wissen, wieviele Parameter da auf einen zukommt.

Mal angenommen ich stelle für rewriting pattern {param1},{param2} ein. Jetzt kommen aber bei der Benutzung der Applikation noch 2 zusätzliche Parameter hinzu - woher soll das Framework dann wissen, wie es diese anzuhängen hat? Klar ich könnte sie einfach dranpappen, aber ich möchte schon irgendwo ein intelligentes System entwickeln dass ja auch möglichst viel Arbeit abnimmt.

Einen alternativen Konfigurationswert wie einen URI-Trenner (hier in dem fall das ",") könnte ich zusätzlich noch einfügen, dennoch haperts bei mir noch mit dem Verständnis wie ich solch eine Konfiguration umsetzen könnte.

Wer hilft mir auf die Sprünge?

[dr.e.]

Hallo Chr!s,

um hier ein wenig Generik ins Spiel zu bringen solltest du dich von der Param1, Param2, Param3 Geschichte trennen und von n Parametern ausgehen. Das bedeutet, dass du eine /-URI immer als Folge von Param/Value auffassen solltest. Damit kannst du generisch Parameter anhängen oder ersetzten. Das klingt erstmal sehr einschränkend, da du immer von Param/Value ausgehen musst, man kann aber dann auch ein Präfix konfigurieren - oder dynamisch bestimmen - um weitere Informationen wie Actions etc in die URI mit aufnehmen zu können. Das kann dann so aussehen:

http://www.example.com/module1/action1/param2/~/key1/value1/key2/value2

Du kannst dann die Actions aus dem REQUEST-STRING extrahieren - das geht dann aber dann nur per PHP - und den Rest als Parameter in das REQUEST-Array schreiben. Ich habe dazu eine Rewrite-Rule geschrieben, die alles an die index.php übergibt:

RewriteRule !((index|print|helloworld).php|css|jpe?g|png|gif|zip|rar)$ /index.php?%{QUERY_STRING} [NC,L]

Die oben angesprochenen Parameter aus der URL werden dann mit PHP auswertet und in das REQUEST-Array geschrieben, damit die Applikation darauf zugreifen kann. Ich erledige das in der Klasse Page, die als erstes instanziert wird (PageController-Implementierung).

Damit hast du die Möglichkeit beliebig viele Parameter an eine URL anzuhängen und zusätzlich auch noch Action-Parameter zu definieren. Konfigurations-Technisch musst du nun einmal den Token ("/~/") definieren und zum anderen, was du vor dem Token erwartest. Der Rest ist generisch auswertbar.

Soweit meine Vorstellung klar?


EDIT: Wichtig an der Geschichte ist noch, dass du für das generieren der Links in allen Komponenten deiner Software einen zentralen Link-Handler hast, der sowohl "normale" als auch /-URIs handeln kann. Dieser fragt dann den Schalter "rewriteURIs" ab...

[$traight-$hoota]

ich finde /module/action/param/~/key/value/key/value ist eine recht unflexible form und bildet quasi nur die struktur des frameworks mit modulen und actionen nach. aber das interessiert den user sowiso nicht und macht uris teilweise zu kompliziert.
es macht zwar etwas mehr aufwand, aber dennoch lohnt es sicht, wenn beliebige feste oder per konfiguration änderbare uri-pattern ausgewählt werden können.
am beispiel eines weblogs würden einige beispiel-URIs nach dem Vorschlag von dr. e vielleicht so aussehen:

/blog/category/{kategoriename}
/blog/view_article/{artikelname}
/blog/archive/~/year/{jahr}/month/{monat}

folgende URIs wären aber wesentlich besser:

/categories/{kategoriename}
/articles/{artikelname}
/archive/{jahr}/{monat}

als beispiel könntest du dir mal die URI-formatierung in weblogs wie beispielsweise wordpress ansehen, da kann man auch mit gegebenen parametern beliebige URI-schemata konfigurieren. also müsste für ein framework ein komplexeres system implementiert werden, in dass für einzelne komponenten speziell formatierte URIs registriert werden können.

[dr.e.]

Hallo $traight-$hoota,

die Einführung des Tokens impliziert ja, dass man entscheiden kann, was feste, und was generische Teile der URL sind. Der Token könnet auch ein "archive" oder "articles/mycategory" sein. Das muss jedoch generisch implementierbar sein, so dass man beim Rewriten auch weiß, welcher Teil des Strings die Key-Value-Paare enthalten. Dein zweiter Vorschlag ist IMHO auch nicht besser als das, was Chr!s auch schon macht, nur in grün.

[Chr!s]

Zitat von $traight-$hoota

als beispiel könntest du dir mal die URI-formatierung in weblogs wie beispielsweise wordpress ansehen, da kann man auch mit gegebenen parametern beliebige URI-schemata konfigurieren. also müsste für ein framework ein komplexeres system implementiert werden, in dass für einzelne komponenten speziell formatierte URIs registriert werden können.

Bei Wordpress ist es ja noch einfach - da ist es speziell auf Wordpress bezogen. Mein Framework hat aber keinen bestimmten Einsatzbereich.

@dr.e:
So wie du es mir vorgeschlagen hast habe ich es bereits - jedenfalls hört es sich für mich so an. URIs können und werden bereits in dem Format umgeschrieben:
http://example.com/module/param/param/param [,/] was auch immer die Parameter sein mögen (können auch aciton-anweisungen sein, das steht ja offen).

Kann auch gut sein dass ich deine Ausführung nicht verstanden habe.

[dr.e.]

Hallo Chr!s,

mit

http://example.com/module/param/param/param [,/] was auch immer die Parameter sein mögen (können auch aciton-anweisungen sein, das steht ja offen).

hast du meiner Ansicht nach noch keine Generik erreicht, da du immer von einem Modul abhängig bist. Nehmen wir an, du hast mehrer Frontcontroller-basierte Applikationen in einer Seite eingebaut, so musst du zwangsläufig mehrere Module in der URL unterbringen. Das bedeutet wiederum, dass du ein generisches Schema der Form

http://www.example.com/module1name/module1param/genericparam1/genericvalue1/genericparam2/genericvalue2/modulename2/moduleparam2/genericparam3/genericvalue3/

benötigts. Dies kannst du so nicht abbilden, denn du must zwischen Parameter einer Action und "normalen" Parametern unterscheiden können. Dies geht nur, wenn man ein Unterscheidungsmerkmal in URLs einführt.
Ich baue Actions jedoch als generische Parameter wie folgt in die URL ein, so dass ich mir darüber keine Gedanken machen muss:

"Normale" URL:

./?sites_demosite-action:Login=param1:value1|param2:value2

Rewrite-URL:

./sites_demosite/action/Login/param1/value1/param2/value2/

Wenn zwei Actions in der URL auftauchen werden diese einfach aneinander gehängt und sind anhand des Keywords "action" unterscheidbar. Generische Parameter werden nach einem "/~/" als Key/Value-Paare angehängt. Damit bist du hinsichtlich der mehrfachen Verwendung von Actions save und kannst zusätzlich generische Parameter anhängen. Man könnte zusätzlich Standard-Schemata definieren, die am Anfang erwartet werden damit man Standard-Pfade wie beispielsweise in Wordpress erzeugen kann.

[dago]

Hi Chr!s, verstehe ich die Zeile richtig:

rewritingPattern = "{param1},{param2},{param3}"

dass dieses Pattern so in der Art in der URL aussieht: http://domain.tld/Aparam1,Aparam2,Aparam3/Bparam1,Bparam2

Dann kannst du einfach einen Separator definieren, wie "," und als Pattern nur beschreiben, wie das "param" aussehen soll.

Beispiel:
{param1}={param2}, zweiter Parameter wird dem ersten zugewiesen
{param1}-{param2}, Parameter besteht aus zwei Wörtern


@dr.e.

./?sites_demosite-action:Login=param1:value1|param2:value2

Ich sehe hier ungerne weitere Sonderzeichen. hältst du dich hier den noch an die Standards?

[Basti]

Hi.

Ich hab gerade von meinem Framework eine Light-Version für einen kleinen Auftrag (http://funkchecker.de) erstellt und erst beim Hochladen erschrocken festgestellt, dass der Kundenserver (STRATO) kein mod_rewrite verfügbar hat. Drum hab ich mich auch ein wenig damit auseinander gesetzt.

Ich denke, das Problem ist ja weniger, die Werte auszulesen, als diese zu erzeugen, also Links zu generieren. Zmindest war das bei mir dann eben hier der Fall.

Mein Framework-/CMS-Schema ist bislang folgendes:

Einfacher Seitenaufruf, ggf. mit Parametern (quasi ein GET-Request im übertragenen Sinne:(
{domain}/[{page_id}[?{query_string}]]
example.com/
example.com/startseite
example.com/startseite?message=a65e3

Action-Aufruf (~= POST-Request)
{domain}/{module}.{action}[/|?*]
example.com/user.login
example.com/page.edit?page=sartseite
example.com/media.image/f52bg17re18.png

Letztlich ist ein erster Parameter (nach deinem Modell), der kein Punkt enthält nur eine Abkürzung für /page.display?page_id={param}.

Das Schema module.action ist also letztlich immer gleich, bis auf diese eine Abkürzung. Und was dahinter passiert, liegt dann am Modul selbst.

Ist allerdings noch nicht wirklich weit genug gedacht, da es in Kürze auch "Sektionen" geben muss, also praktisch Seitenaufrufen über einen Pfad:

example.com/users/basti
example.com/groups/students2007a
example.com/einrichtungen/irgendwas

...das quasi als Wrapper für /page.display?page_id=users/basti

Ehrlich gesagt, weiß ich nicht, wie man das alles simpel in einer Konfigurations-Datei abbilden kann. Ich seh da auch (für mich) keine Notwendigkeit. Geschickt wären halt verschiedene austauschbare Schemata, die jeweils über eigene Klassen zum Umschreiben in beide Richtungen verfügen.

Wer ein Framework benutzt, der benutzt es ja, um einfach programmieren zu können. Der kann sich so auch ein passendes URI-Schema auswählen und implementieren.

Basti