Extended Header als Standard für SF 1.6 |
Willkommen, Gast ( Anmelden | Registrierung ) [ Hilfe | Mitglieder | Suche ]
Extended Header als Standard für SF 1.6 |
Wed. 5. December 2007, 14:53
Beitrag
#1
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 587 Mitglied seit: 01.07.2006 Mitglieds-Nr.: 62 |
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:
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.
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: ZITAT 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 -------------------- Zufall ist das Pseudonym, das Gott sich zugelegt hat, wenn er unerkannt bleiben möchte.
|
|
|
Thu. 6. December 2007, 18:14
Beitrag
#2
|
|
Administrator Gruppe: Members Beiträge: 1.092 Mitglied seit: 16.06.2006 Wohnort: Köln Mitglieds-Nr.: 1 |
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. -------------------- Es wird, es wird...
|
|
|
Fri. 28. December 2007, 20:36
Beitrag
#3
|
|
Administrator Gruppe: Members Beiträge: 1.092 Mitglied seit: 16.06.2006 Wohnort: Köln Mitglieds-Nr.: 1 |
ZITAT 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. -------------------- Es wird, es wird...
|
|
|
Fri. 15. February 2008, 16:46
Beitrag
#4
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 587 Mitglied seit: 01.07.2006 Mitglieds-Nr.: 62 |
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.
-------------------- Zufall ist das Pseudonym, das Gott sich zugelegt hat, wenn er unerkannt bleiben möchte.
|
|
|
Vereinfachte Darstellung | Aktuelles Datum: 25.9.24 - 11:23 |