[TYPO3-UG Freiburg] RealUrl vs. CoolUri

[Mikel]

Moin zusammen,

da ich ja vorgestern spontan doch noch absagen musste, stelle ich meine 
Erfahrungen mit RealUrl und neuerdings mit CoolUri hier zur Debatte.

Ich verwende seit Jahren RealUrl, in eigentlich allen Projekten. 
Allerdings bin ich damit seit der Einführung von Extbase immer an 
größere Grenzen gestoßen. Extbase bzw. der entsprechende Fluid Link 
Viewhelper erzeugt nicht gerade Links, über die sich Suchmaschinen erfreuen.

Folgender Ausgangspunkt:

Eine Extbase-Extension hat drei Actions, die verschiedene Parameter 
benötigen, um korrekt anzuzeigen.

Action 1 --> List
Zum Beispiel eine Liste von News, gefiltert nach Jahr (in meinem 
Beispiel kann über ein Dropdown das Jahr gewechselt werden).
Benötigte Parameter in URL --> NUR das Jahr, action (list)

Action 2 --> Show
Die Detailansicht einer News.
Benötigte Parameter in URL --> uid des entsprechenden Datensatzes, 
action (show)

Action 3 --> Download eines angehängten PDF's
Ein Newsdatensatz hat Relationen zu FAL-Dateien.
Benötigte Parameter --> uid der Datei, action (download)

"Ungeschönte" URI's:

Action 1 --> 
domain.xy/index.php?id=24&tx_extname_pluginname[year]=2010&tx_extname_pluginname[action]=list&tx_extname_pluginname[controller]=ModelName
Action 2 --> 
domain.xy/index.php?id=24&tx_extname_pluginname[ModelName]=4&tx_extname_pluginname[action]=show&tx_extname_pluginname[controller]=ModelName&cHash=0149de7f00fac9921b95f9c8c1300b44
Action 3 --> 
domain.xy/index.php?id=24&tx_extname_pluginname[file]=121&tx_extname_pluginname[ModelName]=4&tx_extname_pluginname[action]=downloadDocument&tx_extname_pluginname[controller]=PressRelease&cHash=838076fbc461129a496b19dd70c73799

Ziel:
Action 1 --> domain.xy/pfad-zur-seite-mit-plugin/2010
Action 2 --> domain.xy/pfad-zur-seite-mit-plugin/pfad-zur-news (kann 
auch domain.xy/pfad-zur-seite-mit-plugin/2010/pfad-zur-news sein)
Action 3 --> 
domain.xy/pfad-zur-seite-mit-plugin/pfad-zur-news/download/uid-der-datei

Problematik mit RealUrl:

Es fängt eigentlich schon an mit dem Parameter für den Controller. Wenn 
man den Fluid-VH link.action verwendet, dann wird dieser per Default mit 
übergeben. Wenn man allerdings bei allen Plugins voraussetzen kann, dass 
alle den selben Controller verwenden, dann ist dieser Parameter in der 
URL unnötig. Nun könnte man stattdessen einfach den link.page VH 
verwenden. Ist meiner Meinung nach aber nicht besonders toll.
Erzeugt man die Links also per link.action, dann werden alle nicht 
benötigten Parameter in die URL geschrieben. Dies sorgt für einen 
unnötig langen Pfad --> 
domain.xy/pfad-zur-seite/controllername/show/name-des-datensatzes-oder-uid
Bei etwas komplexeren Konstellationen hat man da schnell mal 5 unnötige 
Ebenen zusammen.

Die weitere Problematik: Wenn man in einer Action einen Parameter setzt, 
welcher in einer anderen action nicht notwendig ist und diesen per 
RealUrl rewritet, dann werden Fehler geworfen (Controller blabla not 
allowed by this plugin).

Und noch eine: Da das Jahr in der List-Action "geschönt" wird, taucht an 
allen Stellen, an denen das Jahr nicht übergeben wird, ein doppelter 
Slash auf. Man kann in RealUrl zwar noMatch = bypass setzen, dies 
allerdings nur für ValueMaps. Per Workaround müsste man sich jetzt eine 
ValueMap für alle Jahre erstellen (ein Array mit den vorhandenen 
Jahreszahlen). Wird das Jahr nicht übergeben, trifft ValueMatch nicht. 
Erst dann greift der "bypass" und das Pfadsegment wird nicht ersetzt. 
Bei Jahreszahlen funktioniert dieser Workaround. Wenn man hier 
allerdings Kategorien übergeben wollte, dann muss man sich schon was 
besonderes einfallen lassen.

CoolUri:

Die Ersetzungen werden per XML gesteuert. Dabei stehen die gleichen 
Mittel zur Verfügung wie in RealUrl (valueMatch, DB-Lookups, etc). Man 
kann allerdings deutlich mehr Einfluss nehmen. Über einen 
"predefinedpart" kann man z.B. den Controller einfach aus der URL 
rausnehmen, wenn dieser nicht für die Logik benötigt wird. Zudem kann 
auch auf die Reihenfolge der Pfadsegmente Einfluss genommen werden. 
Parameter, welche nur in bestimmten Actions vorausgesetzt werden, können 
ersetzt werden, ohne, dass diese auch in anderen Actions vorausgesetzt 
werden (doppelte Slashes bzw. Fehlermeldung).

Die Nachteile, die ich derzeit sehe:
- Wenig Dokumentation
- die Größe der Community nur ein Bruchteil der RealUrl-Community
- schon bei der Installation gibt es Probleme, da die Tabellen für den 
Pfad-Cache nicht geschrieben werden. Ich habe diese manuell in der 
Datenbank angelegt, um den Cache nutzen zu können
- das Fehlerseiten-Handling von TYPO3 wird "deaktiviert", da CoolUri 
sein eigenes Fehlerseitenhandling mitbringt. Ich muss mal schauen, ob es 
hierfür einen Workaround gibt, da ich mir die URL's der nicht gefundenen 
Seiten bisher immer per Mail zusende, um Fehler direkt korrigieren zu 
können.

Generell lassen sich die Probleme, die ich hatte, eher schwierig in 
einer Mail erklären. Mich würde schon interessieren, wie ihr das 
Rewriting von Extensions konfiguriert, um nicht auf diese Probleme zu 
stoßen.
Habt ihr da ähnliche Erfahrungen? Würde es sich lohnen, dies mal an 
einer leeren Installation zusammen zu analysieren?

Mikel