Extended Header als Standard für SF 1.6 Einstellungen

[smail]

Hallo zusammen,

ich möchte an dieser Stelle nochmal ein paar wichtige Vorschläge zusammenfassen. Das Feature-Request an sich ist damit nichts wirklich neues.

Um was geht es?
Tiggr hat mit dem Extended Header-Plugin eine, meiner Meinung nach, sehr wichtige Schnittstelle zur Verfügung gestellt. Die Notwendigkeit bzw. der Nutzen wird aus meiner Sicht an verschiedenen Stellen bzw. durch verschiedene andere Feature-Requests deutlich:

• Header als letztes abarbeiten, Module fügen JS und CSS hinzu (Web2.0-Fähigkeit)
• Plugins können den Header-Berich ändern

Was könnte uns diese Erweiterung für SF 1.6 bringen?
Ich versuche das mal ganz praktisch zu beantworten. Mit der Möglichkeit, dass Plugins bzw. Module Zugriff auf den Header der Seite bekommen, kann man eine Vielzahl interessanter Anwendungen realisieren, wie z.B.

• jquery-Plugin, Mootools Plugin, etc.
  Die verschiedenen js-Bibliotheken könnten als einzelne Plugins realisiert werden. So kann jeder seine Lieblingsbibliothek schnell und einfach einbinden und muss nicht mehr "basteln".
• Plugins bzw. Module, die auf den o.g. Bibliotheken basieren, wie z.B. Lightbox, Thickbox oder andere.
  Wir hatten hier ja bereits mehrfach das Thema "Wie realisiere ich mit dem Galeriemodul eine Lightbox-Version?" Allein die Länge dieses Threads spricht doch dafür, dass es derzeit wohl (für Einsteiger) nicht so einfach ist...
• Einfache Einbindung der Google-Maps API
• ...und vieles mehr.

Was muss dafür getan werden?
Tiggrs Extended Header Plugin benötigt derzeit noch eine kleine Anpassung der index.php im Projektverzeichnis. Die Änderung betrifft aber nur wenige Zeilen Code, es werden nur zwei Events getriggert, eins bei Anfang des Headers und eines am Ende. Die Änderung ist also minimal invasiv! Schön wäre es daher, dass sie in den Standard wandert.


Fazit
Ich wünsche mir, dass das Plugin in SF 1.6 standardmäßig funktionieren sollte, d.h. ohne Hack von Dateien. Und wichtig: hierzu brauchen wir natürlich das Feedback der Core-Entwickler.

Ich finde übrigens, Tiggr hat sich mit der Entwicklung genau an Björns Wünsche bzw. Vorgaben gehalten:

Wenn Ihr helfen wollt, dann funktioniert das nur, indem Ihr autonom arbeitet und das Ergebnis hier zur Verfügung stellt. [...] Wichtig ist mir, dass da dann auch was für die Community rausspringt.

(siehe hier)
Erst der Vorschlag, dann die Implementierung und damit geht der Ball zurück an die Entwickler.

Ich denke, die Vorteile liegen klar auf der Hand. Vielleicht gibt es aber auch Nachteile, die ich gerade nicht sehe und die auch berücksichtigt werden sollten. Anmerkungen und Feedback sind daher willkommen

Viele Grüße
Jan

[bjoern]

Der Vorschlag klingt vom Grunde her gut. Ich möchte das noch ein wenig globaler haben, sprich, dass ich ein Output Objekt habe, wo verschiedene Änderungen reingeworfen werden können. Neben den Headern gibt es ja auch noch andere Bereiche, die von eine Ausgabemanipulation profitieren könnten. Z.B. wenn nur bestimmte Container ausgegeben werden sollen oder die HTTP Header manipuliert werden sollen.

Mal schauen, was ich da in der 1.6 tun kann. Und wo wir gerade beim Thema sind. Die 1.6 werde zumindest ich (wenn die Termine halten, ist ja immer so eine Sache...) zwischen Januar und April 2008 entwickeln. Die 1.4.1 erscheint noch dieses Jahr.

[bjoern]

Die 1.4.1 erscheint noch dieses Jahr

Muss ich revidieren, Version ist zwar zum größten Teil fertig, den letzten Schliff schaffe ich aber erst im neuem Jahr.

[smail]

Einen Vorschlag zur Implementierung ohne Änderung des Core habe ich unter Plugin jQuery v00.03.00, Case Study - Module schreiben in den Header veröffentlicht.