[tabcontrol]

[do_while]

Ich tippe mal auf Javascript, was da fehlt. Kopiere mal die Seite in eine Testseite und setze das Standard-Seitenlayout fe_page, dann sollte es gehen. Dann kannst Du Stück für Stück die Unterschiede untersuchen.

[okapi]

Ich tippe mal auf Javascript, was da fehlt. Kopiere mal die Seite in eine Testseite und setze das Standard-Seitenlayout fe_page, dann sollte es gehen. Dann kannst Du Stück für Stück die Unterschiede untersuchen.

Hallo Hagen,
danke für den Tipp, du hast recht, mit dem Standard-Seitenlayout bzw. Standard-Template klappt alles, wie es soll. Jetzt muss ich im Detail schauen, wo das Problem liegt.

EDIT: Peinlich, peinlich.... Ich hab schlicht und einfach vergessen <?php echo $this->head; ?> in mein Template zu schreiben, und daher wurde auch "tabcontrol.js" nicht eingebunden.

Vielen Dank für die schnelle Hilfe!
Gruß
Michael

[do_while]

Schön, dass es jetzt läuft ...

[minstyle]

Tolle Erweiterung!

Ich würde es noch schön finden, wenn man dem Elementtyp "Reiter" > Betriebsart "Reitergruppe" noch eine allgemeine Überschrift verpassen könnte.

Lässt sich dieser Wunsch noch in die Erweiterung implementieren?

[cgpro]

Fade in und out wären noch ein super feature, dann wäre es perfekt

wie z.b. hier, aber mit auswahl für effekte im backend. z.b. fx type und duration. (um das ganze noch schön abzurunden)
http://www.silverscripting.com/mootabs/

[drefsa]

Prima Erweiterung. Danke.
Hat aber noch eine "Macke"
grand schrieb:

Ich hab auch noch was, wenn man in ein Tab eine gallery legt wird wenn man bei der Pagination weiterklickt leider nicht die nächste galleryseite angezeigt sondern der Focus auf das erste Tab gelegt.
Wäre cool wenn dieser Fehler behoben wird?

Habe genau das gleiche Problem, allerdings nicht mit einer Galerie, sondern mit zwei "gepipten" RSS-Feeds auf zwei von drei Reitern. Der zweite Feed ist der übersetzte des ersten(EN->DE). Beim Anklicken einer Seite in der Paginierung wird man auf die korrespondierende Seite des ersten Tab (EN) gesetzt. Leider hab ich noch nicht geschnallt woran das liegen mag.
Hat jemand eine Idee? Brains?

Übrigens funktioniert tabcontrol sonst unter 2.7.5 einwandfrei.
Dann mal Danke!

[grand]

Hallo,

wollte mal nachfragen ob wer rausgefunden hat warum der Focus nicht auf das richtige Fenster gelegt wird?

[Brains]

Hallo,

dickes Sorry, ich hab in den letzten Monaten null Zeit gehabt mich um die Extension bzw. Euere Fehlermeldungen und Erweiterungswünsche zu kümmern.
Ich hoffe dass ich ab Februar wieder mehr Zeit dafür habe.
Was das Problem mit dem Seitenwechsel angeht, an sich ist es kein Fehler sondern ein Feature das noch nicht implementiert ist. Beim Seitenaufruf wird standardmäßig das erste Panel angezeigt, da das TabControl sich nicht merkt welches Panel zuvor sichtbar war. Ich bin mir gerade nicht ganz sicher ob ich das irgendwie in eine Komponente wie etwa Pagination einbetten kann automatisch das richtige Tab zu öffnen, werde es aber versuchen. Auf die Schnelle fällt mir auch kein Workaround für Eure Anforderung ein. Sollte mir was einfallen schreibe ich es in den Thread

LG,
Jean

[grand]

Super danke schonmal!!

[quintacom]

Ich habe irgendwie von dieser JavaScript oder Ajax-Technik die hier eingesetzt wird nicht so den Durchblick.

Deshalb werfe ich einfach mal folgende Frage ein:
Wäre es möglich, diese Extension so anzupassen, dass man auf die verschiedenen Panes anstatt über die Reiter dann über eine einfache "Vor und Zurück"-Navigation zugreifen könnte?

Denn wenn man in der Breite nicht so viel Platz hat und trotzdem eine Menge Reiter unterbringen will oder muss, sieht es schlecht aus.

Wer kann da mit Durchblick Tipps geben, wie man so etwas anpassen könnte oder ob das überhaupt irgendwie möglich wäre.

Bedanke mich.

[freak0r]

Hallo Forum,
Hallo Jean,

ich befasse mich erst seit wenigen Tagen mit TL und bin bei der Suche nach einer Umsetzung auf TabControl gestoßen.

Mein Ziel:
- Mehrere Reitergruppen auf einer Seite
- Jede Reitergruppe enthält zwei Panes
Dieses ist dank Tabcontrol kein Problem mehr

- In Pane 1 befindet sich ein Link um Pane 2 zu öffnen
- In Pane 2 befindet sich ein Link um Pane 1 zu öffnen
Diese Togglefunktion habe ich noch nicht hinbekommen, da ich scheinbar nicht fähig bin, den korrekten Befehl zu finden, welcher den Tabs zugewiesen ist.
[edit]okay ich bin etwas weiter. Zeile 170 ff. in der zugehörigen js-datei ist wohl der Schlüssel zum Bau einer Toggle-Funktion.[/edit]
[edit2]mit Workaround gelöst. Lösung im folgenden Post beschrieben[/edit2]

- Beim Wechsel von einer Pane zur anderen sollte ein Scrollen+Faden auftreten.
- Erst wird Pane 1 ausgeblendet, danach Pane 2 ein.
Ich habe das mit ein bissl javascriptgeschnippsel und jqueryvergewaltigung mal anskizziert.
(Klick auf das Bild unter "noch Fragen?" in der Sidebar bzw. auf die zweite Referenz "EADS")

Habt ihr da evtl. ein paar Überlegungen parat?

Bin für jede Hilfe dankbar!

[freak0r]

okay - update soweit.

Togglefunktion über folgenden Umweg realisiert: Vorrausgesetzt, dass wirklich immer nur zwei Panes benutzt werden sollen (oder eins.), ist folgender Workaround vergleichsweise einfach möglich.

Ich habe in der plugins/tabcontrol/tabcontrol.js nach zeile 119 der _initTabs ein

nach zeile 119 einfügen: tabs.reverse();

eingefügt. So werden bei nur zwei Panes/Tabs die Links der Tabs vertauscht. Dies ermöglicht es, in Pane1 einen Reiter zu setzen, der auf Pane2 linkt und vice versa. Die Tabs können entweder über

<div id="tab1">link</div> (pane1)
<div id="tab2">link</div> (pane2)

gegenverlinkt werden, oder durch einfügen einzelner Reiterelemente *innerhalb* der Wrapper.

Und jetzt geh ich an das Problem des umblendens. Falls mir hier jemand zur Seite stehen kann - ich bin für alles offen

[freak0r]

okay, ich löse es jetzt mit einer eigenen moo-tools lösung. da klappt dann auch das faden

[Chris87]

Wie kann ich per Link einen bestimmten Tab aktivieren? Im Changelog steht folgendes:

[Change] Das beim Laden der Seite anzuzeigende Panel kann nun mittels eines Ankers (z.B. #myPane) festgelegt werden. Somit können Panele direkt verlinkt werden. Falls auf einem Client JavaScript deaktiviert ist, scrollt der Browser automatisch auf das anzuzeigenden Panel. Somit ist die Barrierefreiheit gewährleistet.

Aber wo kann man das einstellen?

Danke.

[grand]

EDIT: UPS wurde bereits gemeldet der Fehler! Sorry

Hallo,

iih weis nicht ob das im Bugfix bereits behoben wurde, aber ich musste Tabcontrol wieder weglassen da ein verwenden von Galerien in einem Tab nicht funktionierte, ich habe dies bereits vor einiger zeit mal gepostet aber keine Reaktion darauf erhalten.

Das Problem ist, wenn eine Galerie in einem Tab angezeigt wird und diese Galerie eine Pagination besitzt kann man die nächste Seite der Galerie zwar laden aber es wird der Anzeigefocus der Reiter auf den ersten Reiter gelegt und wenn die Galerie somit nicht im ersten Reiter liegt müsste der User erst wieder auf den Galerie Reiter klicken um die zweite Seite zu sehen.

Wäre eine tolle Sache wenn dieser Fehler behoben würde.

LG

G

[Brains]

@Chris87: Du musst nur Deinen Panelen IDs geben, dann kannst Du die direkt verlinken. Mal angenommen Du hast drei Panele mit den IDs pane1, pane2 und pane3, dann kannst Du die direkt referenzieren über:
http://www.mydomain.com/mypage.html#pane1, http://www.mydomain.com/mypage.html#pane2 und http://www.mydomain.com/mypage.html#pane3
Mehr musst Du nicht einstellen, da die Funktionalität immer präsent ist. Das ganze funktioniert allerdings nur beim Laden der Seite.
Solltest Du noch Fragen dazu haben, kannst Du mir gerne eine PM schicken

@grand: Doch, Du hast dazu Antwort bekommen, siehe meinen Post vom 24.01.2010, aber ich wiederhole es gerne, das war kein Fehler es war nur nicht implementiert. Mit der neuen Version gibt es nun eine Möglichkeit, nämlich über die Anchor-Technik. Dazu musst Du allerdings Dein Gallerietemplate so anpassen, dass es den Anker mit übergibt.

Für spezielle Verhaltensweisen bei Tabwechsel gibt es zudem ein onChange-Callback, welches die Signatur function(currentPane, currentTab) hat und an das TabControl-Objekt gebunden ist. Der geneigte JavaScript-Programmierer wird wissen was damit gemeint ist und wie es verwendet werden kann. In der Datei plugins/tabcontrol/tabcontrol.js ist dieses Callback dokumentiert.

HTH

[Alexander]

Servus.

Gibt es eine Möglichkeit, den einzelnen tabs die entsprechenden Klassen zuzuordnen, wie last/first oder odd/even?

Beste Grüße
Alex

[snau]

Servus.

Gibt es eine Möglichkeit, den einzelnen tabs die entsprechenden Klassen zuzuordnen, wie last/first oder odd/even?

Gibt es:
http://www.contao-community.de/showt...t-Alpha-Effekt

[Alexander]

Super! Besten Dank, snau.

Gibt's irgendwo nen Ticket-System für tabcontrol, bei dem man diese Änderung für die nächste Version vorschlagen könnte?

Beste Grüße und einen guten Wochenausklang
Alex

[deerwood]

Hallo alle,

im Extension-Repositoty wird eine [tabcontrol] Version "1.2.0 stable" angezeigt, aber ein Klick darauf funktioniert nicht. Welches ist denn nun die aktuelle Version?

Die 1.1.4 stable, die ich herunterladen kann, hat jedenfalls noch keine der versprochenen Änderungen wie etwa die Klassen first/last(/even/odd) oder den Link und Span um den Reitertext. Auch Überblenden ist nicht da, sondern display: block/none.

Zum Problem mit "falsches Tab angezeigt" bei mehrseitigen Galerien (und nicht validen Formularen oder Links, denen man folgt und dann per Back-Button zurückkommt) habe ich die Idee, per JavaScript ein Session-Cookie mit dem Tab-Index zu setzen (im Event onChange) und bei Reload oder Rückkehr auf die Seite auszuwerten. Ähnliches habe ich bereits für Akkordeons realisiert (siehe Wiki bzw. das verbesserte Script hier).

Das einzige Problem: die Cookie-Lösung ist im Konflikt mit der Anker-Lösung. Die Anker-Lösung erlaubt ja gezieltes Springen zu einem/Öffnen eines Tabs. Das ist gut und wichtig und funktioniert, wenn kein Cookie gesetzt ist. Ist nur das Cookie gesetzt, dann funktioniert es auch. Wenn aber beides gesetzt ist, was sollte dann Vorrang haben?

• Cookie hat Vorrang: dann geht die Anker-Lösung komplett flöten, sobald der Besucher die Seite einmal besucht hat, weil das Cookie ab dann immer gesetzt ist
• Anker hat Vorrang: dann ist das Cookie wirkungslos, wenn man via Back-Button auf die Seite zurückkommt. Beim Wechsel des Tabs ändert sich ja die URL nicht, der Anker bleibt drin. Beispiel: per Anker auf Tab 2 gelandet, manuell auf Tab 3 umgeschaltet, dort einem Link gefolgt, Rückkehr via Back: der Anker wird gefunden und Tab 2 angezeigt. Mit nicht validen Formularen, die dann mit Fehlermeldungen wieder angezeigt werden, und mit Inhaltselementen, die eine Paginierung haben (Gallerie, News ...) sollte es aber gehen, weil beim Reload der Seite dann von Hause aus kein Anker gesetzt ist.

Die weniger schlechte Lösung ist also, dem Anker Vorrang zu geben.

EDIT: ich glaube, ich habe auch für den Back-Button eine Lösung: bei Klick auf einen Tab muss der Anker per JavaScript gelöscht werden mit "window.location.hash = '';". Nach einem Vortest (nur in Opera) bewirkt das KEIN Reload der Seite. Ich werde das mal ausprobieren und melde mich dann mit Code wieder.

LG, Georg

[soweit_ok]

im Extension-Repositoty wird eine [tabcontrol] Version "1.2.0 stable" angezeigt, aber ein Klick darauf funktioniert nicht. Welches ist denn nun die aktuelle Version?

Die 1.1.4 stable, die ich herunterladen kann, hat jedenfalls noch keine der versprochenen Änderungen wie etwa die Klassen first/last(/even/odd) oder den Link und Span um den Reitertext. Auch Überblenden ist nicht da, sondern display: block/none.

Hallo Georg,
die 1.1.4 stable ist anscheinend die aktuelle Version. Schließe ich daraus, dass ich tabcontrol schon länger eingebunden hab und sich in meiner Erweiterungsverwaltung momentan diese Version befindet und als aktuell angezeigt wird.
HG Andreas

[zonky]

... da bin ich wieder (komme von http://www.contao-community.de/showt...l=1#post140108)

Die Ansteuerung von Akkordeon und Tab ist doch "identisch" - ich wünsche mir auf alle Fälle auch Akkordeon(s), die ich per URL direkt "aufschlagen" kann. Somit käme der Cookie-Session-Konflikt auch hier zum Tragen.

Vorab (@soweit_ok) contao erzeugt, soweit ich das nachvollzogen habe, eine Session sofort und bei jedem eine Session, der auf eine Contao-Seite kommt. Ein entsprechender Cookie mit der SID wird gespeichert. Wie das Fallback für "ohne-Cookie aussieht", habe ich nicht so schnell finden können.

Ein Fall-Back fur "ohne-Cookie" wäre somit für beide Varianten interessant....

Dem Anker würde ich aus dem Bauch herraus auch eine höhere Gewichtung als dem Cookie geben. Die Löschung per window.location.hash = ''; ist sicher eine gute Idee.

Bei meinem Versuchen mit window.location.hash = 'irgendwas'; wurde immer ein Reload gemacht und die Seite scrollte "irgendwohin" (glaube an die Stelle wor der Anker wäre, wenn nicht per CSS die Reiter entstünden).

... muss ich nochmal testen - aber ich glaube das Anspringen der Tabs per Anker ging nur, wenn der Link von einer anderen Seite kommt bzw. funktioniert nicht um in einem Tab einen Link zu einem anderen Tab zu machen...(?)

Gruss zonky

[soweit_ok]

Ja, den Contao-Fallback rauszufinden, falls es einen gibt, wenn der Client keine Cookies erlaubt, wäre wohl wichtig, schätze ich. Damit ich es auch verstehe (bin in dem Thema leider nicht so fit wie ihr), sollte es kein Fallback seitens Contao geben, spräche denn etwas dagegen, in dem Fall die Session selbst zu erzeugen und die SID dann per Hidden Input oder als GET-Parameter in der URL zu übergeben? Dann bräuchte man doch kein Cookie, weil die Session im RAM des Clients gespeichert ist und mittels der SID ausgelesen werden könnte, oder? Bzw. mache ich da einen Denkfehler, fehlt mir eine entscheidende Info? Ist mir ja etwas peinlich, hab mich mit diesem Bereich wie gesagt bisher noch nicht sehr intensiv beschäftigt.

Wahrscheinlich auch ne doofe Frage ... könnte man dem Browser zum Anspringen des Tabs per Anker vielleicht irgendwie vorgaukeln, man käme von einem externen Link? An irgendwas muss das der Tab doch merken, also denke ich mir, es müsste was her, dieses "irgendwas" zu überschreiben.

[zonky]

hab mich mit diesem Bereich wie gesagt bisher noch nicht sehr intensiv beschäftigt.

... kein problem: Die Session-Variablen werden auf dem Server gespeichert unter der ID als "Wiedererkennung" - der Browser liefert die selbe ID, damit der Server auch die richtigen Daten an den richtigen browser ausgibt... ist wie beim Gaderobe abgeben mit Marke. Im Browser kann die ID z.B. als Cookie gespeichert werden oder in Form eines GET-Parameters. Die ID muss aber "zuverlässig" vom Browser an den Server. Guck mal zum Thema Session z.B. bei SelfPHP

Wahrscheinlich auch ne doofe Frage ... könnte man dem Browser zum Anspringen des Tabs per Anker vielleicht irgendwie vorgaukeln, man käme von einem externen Link? An irgendwas muss das der Tab doch merken, also denke ich mir, es müsste was her, dieses "irgendwas" zu überschreiben.

:-) das ist halt Sache des Browsers... anscheinend sind die Standard-Implementierungen so, dass bei gleicher "URL" und unterschiedlichem Anker kein Reload stattfindet - was ja auch gut ist. GGf. müsste man mal prüfen, ob die JavaScript-Tab-Umschaltung nur bei Reload "zündet" und ggf. auf Click-Event umschaltet/ergänzt.

zonky

[soweit_ok]

Okay, vielen Dank für die Info. Alles verstanden ... werd aber trotzdem ruhig nochmal bei selfPHP nachlesen.

[deerwood]

Moin,

also das Öffnen eines Akkoredon-Elements per Anker-Wert fände ich auch eine gute Sache. Siehe unten.

Die Session würde ich nicht nutzen wollen/können: das Umschalten von Tabs bzw. Akkordeon-Elementen findet ja absichtlich OHNE Kommunikation mit dem Server statt (kein Reload). Es ist meiner Meinung nach auch die falsche Stelle, wozu sollte Contao darüber informiert werden, welchen Tab der Besucher gerade anschaut?

Session-Cookies werden auch, soweit mir bekannt, von Browsern akzeptiert, die persistente Cookies ablehnen (weil der Besucher das so eingestellt hat). Und für den hier diskutierten Zweck ist es meiner Meinung nach nicht erforderlich, das Cookie dauerhaft zu speichern, es geht wirklich nur um die aktuelle Session.

Das Problem mit Back/Formularen/Paginierungen haben nebenbei alle Web 2.0/AJAX Anwendungen (z.B. auch noch pk_noobSlide, ce_slide) ... deshalb gibt es auch generische Ansätze, dem beizukommen. Gerade habe ich z.B. den MooTools History-Manager gefunden. Ich lese gerade dessen Beschreibung, Ihr könnt ja mal das Beispiel dort in verschiedenen Browsern (vor allem unter Mac) testen, ob das ohne Reload funktioniert. Irgenwo hatte ich auch noch was gesehen, das mit HTML5 Features arbeitet, falls verfügbar, ansonsten aber auf location.hash downgraded, falls nötig.

Die Anker-Lösung im aktuellen [tabcontrol] funktioniert nebenbei nur bei echtem Reload, weil die Auswertung im Konstruktor von TabControl stattfindet (function initialize) und das Object ja bei domready erzeugt wird. Deshalb kann man nicht in einem Tab auf einen anderen verlinken und erwarten, das der dann aufgeht. Dazu gibt es aber zwei JS Funktionen: selectTab() und selectTabByIndex(). Ich werde aber mal schauen, ob ich daran auch was drehen kann.

LG, Georg

[soweit_ok]

Hallo zusammen,

... MooTools History-Manager gefunden. Ich lese gerade dessen Beschreibung, Ihr könnt ja mal das Beispiel dort in verschiedenen Browsern (vor allem unter Mac) testen, ob das ohne Reload funktioniert.

Hab keinen Mac. Aber meine Tochter (iBook, OS X, 6 Monate alt). Falls niemand von euch einen hat oder auftun kann, würde ich ihr eine Mail mit dem Link schicken und sie bitten, das mal für uns zu testen.

Gestestet hab ich eben unter Win XP mit FF3.6, FF4, Opera11, IE8. Das Verhalten der Browser war identisch.

Ergebnis:
Beim Wechsel auf die Tabs "Content 2" bis "Content 4" und zwischen denen kein Reload. Beim Zurückwechseln auf den Tab "Content 1" erfolgte jedoch in allen Browsern ein Reload.

Korrektur:
Bei einem späteren Test benahm sich der FF plötzlich brav und machte auch beim Rückwechseln auf den ersten Tab keinen Reload. Auch nachdem ich mal den Cache geleert und die Seite neu geladen hatte. Was da anders war als vorher, konnte ich nicht nachvollziehen und die URL-Parameter schauten auch genauso aus. Die anderen Browser machten dasselbe wie zuvor.

Spasseshalber änderte ich in den IE8-Einstellungen mal die Sicherheitsstufe auf "hoch". Erwartungsgemäß ging dann praktisch garnichts mehr. Die Buttons "Previous" und "Next" weiter oben auf der Seite außer Funktion und die Divs der Tab-Elemente unten wurden alle gleichzeitig untereinander angezeigt. Ist klar, weil bei dieser Stufe wohl auch Scripting deaktiviert ist. Was unabhängig vom aktuellen Vorhaben ganz allgemein Gedanken über Verwendung oder Nichtverwendung von Cookies etwas absurd erscheinen lässt, denn wer Javascript abschaltet, doch sehr wahrscheinlich auch Cookies - denke ich mir jedenfalls. Außerdem würde es in dem Fall auch keine Rolle spielen, weil dann Accordions und Tabs eh nicht funktionieren. Und umgekehrt, wer JS zulässt, vermutlich auch Cookies.

Das von luckyB unten in den Kommentaren der Seite beschriebene IE8-Problem trat bei mir mit dem IE8 nicht auf.

Ich kann auch nochmal mit Chrome testen, hab ich aber nur in einer VM und die hab ich dafür jetzt nicht extra gestartet.

Session-Cookies werden auch, soweit mir bekannt, von Browsern akzeptiert, die persistente Cookies ablehnen (weil der Besucher das so eingestellt hat). Und für den hier diskutierten Zweck ist es meiner Meinung nach nicht erforderlich, das Cookie dauerhaft zu speichern, es geht wirklich nur um die aktuelle Session.

Hab übrigens an mehreren Stellen nochmal nachgelesen und wenn man dem glauben darf ... Temporäre Session-Cookies werden im RAM des Client gespeichert. Wenn Cookies insgesamt verboten sind und nicht nach persistent oder temporär unterschieden wird, gehen jedoch beide Arten nicht. Bei näherem Nachdenken kann ich Dir überdies nur zustimmen - Sessions wären dafür doof, weil dann wohl in jedem Fall ein Reload passiert.

Fazit: Eigentlich funktioniert diese MooTools-Lösung super. Bloß das mit dem ersten Tab ist unangenehm und ein Nachteil ggü. dem Default-Tabcontrol-Modul, wo nirgends ein Reload stattfindet. Außerdem beginnt die Seite danach wieder ganz oben. Nicht so toll, wenn das Tab-Dings weiter unten außerhalb des Viewports sitzt.

[deerwood]

Moin,

im Anhang eine Alpha-Version der Cookie-Variante für TabControl. Ich konnte bisher ohne Patches auskommen und habe nur das Template "ce_tabcontrol_tab" geändert. Packt den Anhang aus und laded das *.tpl in Euren Template Ordner (passend zum Theme) hoch. Dann sollte es funktionieren.

LG, Georg

[schman]

Wow sehr cool, gefällt mir ausgezichnet kann ich gleich mal brauchen

[soweit_ok]

Moin Georg,

dankeschön!! Ich hab´s eben im BE "Templates - Neues Template" angelegt und den Code mit Deinem ersetzt. Richtig so, oder meintest Du den Template-Ordner im Filesystem und es dort zusätzlich unter neuem Namen speichern? Wobei mir jetzt nichts einfiele, weshalb das einen Unterschied machen sollte.

Eben mit Firefox getestet. Toll, bis auf einen Punkt funktioniert es schon bestens, auch mit einem Formular im Tab - nach einem Reload oder Rückkehr von einer anderen Seite ist immer der zuletzt offene Tab wieder geöffnet.

1 Fehler: Tritt der bei Dir nicht auf? Beim Klicken auf einen Reiter springt die Seite ganz nach oben und ich muss erst wieder runterscrollen. Mir aufgefallen, weil sich in der getesteten Seite die Tabcontrol-Elemente unten außerhalb des Viewports befinden. Die eine Gruppe sind 4 in Tabs untergebrachte Fotogalerien und ansonsten sind die Kommentare in Tabs. Kommentare und Formular im ersten, im zweiten Verwendungshinweise.

TABELEMENTE.jpg TABCONTROL2.jpg
Zwar glaube ich kaum, dass der unerwünschte Sprung zum Seitenanfang als Nebeneffekt von dieser individuellen Besonderheit bei mir verursacht wird, doch ich erwähne es besser: Außerdem hab ich in beiden Tab-Gruppen als letzten einen "X"-Reiter ohne Inhalt im zugehörigen Tab. Weil der inhaltslos ist, bringt mir das die nützliche Zusatzfunktionalität, beim Klicken darauf die ganze Gruppe bis auf die Reiter-Zeile auszublenden. Finde ich sehr praktisch, so kann man z. B. die Kommentare unten bis auf die Kopfzeile komplett ausblenden.

Wünsch Dir einen erfolgreichen Tag ...
HG Andreas

[soweit_ok]

Wow sehr cool, gefällt mir ausgezichnet kann ich gleich mal brauchen

Hast Du auch schon den Thread zu Georgs super Erweiterung "faqaccordion" mitbekommen? Die kann nämlich viel mehr als "nur" Akkordeons zu verschachteln, die Beschreibung im ER erwähnt nicht alles:

• Kann außerdem genauso wie das Standardmodul auch mit ganz normalen Akkordeons umgehen.
• Löst endlich mal das leidige Formularproblem und zwar äußerst elegant.
• Nach Reload und Rückkehr von im Akkordeon verfolgten Links ist das zuletzt geöffnete Akkordeon automatisch wieder offen und scrollt bei Bedarf komplett in den Viewport.
• Wenn das öffnen eines langen Inhalts aus dem Viewport rutscht, scrollt er sofort automatisch wieder rein.
• Die oft nachgefragte CSS-Formatierung aktiver Toggler und bei hover funktioniert natürlich ebenfalls.

Ja, ich weiß - ist hier off topic, nur mal eben als Tipp.

[soweit_ok]

Ich schon wieder.

Hab´s gefunden ...

                onChange: function(pane, tab) {
                    // remember open tab
                    Cookie.write(this.options.cookieBase, this.panes.indexOf(pane));
                    // kill/set hash mark (for a working back button)
//                    location.hash = pane.id ? '#' + pane.id : '#x';
                    // location.hash = '';

Nachdem ich location.hash = ''; auskommentierte, unterbleibt das Springen zum Seitenanfang. Der leere Anker scheint dem Script auch nicht zu schmecken. Hab den ganzen Test nochmal durchlaufen und finde, so könnte man mit der Funktionalität eigentlich schon gut leben und allemal viel besser als vorher mit dem Standardtemplate.

[zonky]

moin,

habe die Anpassung auch mal eingebaut - funktioniert soweit gut...

das location.hash = ''; habe ich auch auskommentiert - der Browser springt natürlich nach oben, da ja nur ein "leerer Anker" erzeugt wird und nicht der Anker gelöscht wird.

das ginge mit sowas wie

var loc = window.location.href;
  index = loc.indexOf('#');
if (index > 0) {
  window.location = loc.substring(0, index);
} 

zonky

[deerwood]

Hi alle,

das Setzen von location.href führt doch zu einem Reload, oder? Ich kann heute schlecht testen, weil unterwegs und nur mit GPRS Geschwindigkeit am Internet.

Aber probiert doch bitte mal diesen onChange Event:

onChange: function(pane, tab) {
  // remember open tab
  Cookie.write(this.options.cookieBase, this.panes.indexOf(pane));
  if (location.hash.substr(1).length > 0) {
    // kill/set hash mark (for a working back button)
    location.hash = pane.id ? '#' + pane.id : '';
    //location.hash = '#something';
  }
} 

Dann passiert das Setzen/Löschen von location.hash nur noch, wenn man eine Url mit Anker hatte (um ein bestimmtes Tab zu öffnen). Am besten ist es auch, alle Reiter in Betriebsart "Panel Anfang" mit einer CSS Id auszustatten, damit man gezielt springen kann (etwa pane0, pane1 ... oder pane-linka, pane-form, pane-gallery ...). Dann sollte das Springen zum Seitenanfang unterbleiben. Außerdem kann man direkt vor den Reitern noch einen Anker mit Id "something" unterbringen und dann location.hash nach dem Doppelpunkt nicht auf Leerstring sondern auf '#something' setzen.

LG, Georg

[soweit_ok]

Hi Leuts,

ich bekenne ich schuldig, bin heute leider noch nicht dazu gekommen, mich mit mit tabcontrol zu befassen. Georg, deshalb hab ich auch Deinen Codeschnipsel noch nicht probiert.

Ja, soweit mir bekannt, führt location.href zu einem Reload. Was den Gedanken angeht, einen Anker direkt vor die Reiter zu setzen - daran dachte ich auch schonmal. Traute mich das bloß noch nicht vorzuschlagen, weil ich mir nicht sicher war, ob das viell. Quatsch wäre und wollte es erstmal still und heimlich ausprobieren.

Heute bin ich schon zu müde, ich guck morgen wieder ...

Bis dann.
HG Andreas

[soweit_ok]

Jetzt ist mir wieder eingefallen, warum ich den Gedanken, direkt vor den Reitern einen Anker zu setzen wieder verworfen hatte ...

Weil es auf einer Seite mehrere Tab-Gruppen geben kann. Dann kann doch ein #something nichts bringen oder verstehe ich da irgendwas falsch? Was ich auch nicht verstanden habe, was eine individuelle CSS-Id für jeden Reiter bewirken soll.

Ich hab alles nochmal gründlich getestet. Es funktioniert, wie es ist, bereits alles wunderbar und ohne location.hash springt der Browser immer korrekt zur vorherigen Position und nicht nach oben, egal von wo man zurück kam. Und ich denke mir halt, wer Javascript erlaubt, der erlaubt in der Regel auch Cookies. Bzw. Cookies verbietet, meistens auch Javascript. Ohne JS funktionieren jedoch ohnehin weder Tabelemente noch Accordions und dafür existiert auch nichts, was man ernstlich als Fallback bezeichnen könnte. Denn es sieht gelinde gesagt bescheiden aus, wenn dann alle Inhalte untereinander ausgegeben würden. Na klar, ein gut funktionierendes Fallback bei Cookie-Verbot wäre nicht schlecht. Doch da es das grundlegende Problem mit JS nicht lösen könnte, wirklich ein signifikanter Vorteil?

[deerwood]

Hallo alle,

Was ich auch nicht verstanden habe, was eine individuelle CSS-Id für jeden Reiter bewirken soll.

Das ermöglicht erst das gezielte Öffnen eines Tabs, wenn man die Seite verlinkt und einen Ankernamen (fragment identifier, hash) mitgibt. In meinem Beispiel oben haben die 4 Panele die Ids pane-text, pane-links, pane-form und pane-gallery. Rufe ich dann "Reiter.html#pane-form" auf, dann wird der 3. Reiter aufgeklappt, egal ob ein Cookie gesetzt ist (evtl. für ein anderes Tab) oder nicht. Dies Feature ist im Original TabControl bereits eingebaut und meine Cookie-Verbesserung ändert das nicht, Ankernamen haben Vorrang vor dem Cookie.

Schaltet der Besucher nun, ohne mit dem Formular zu interagieren, auf den 2. Reiter "Links" um, folgt einem der dort vorhandenen Links und drückt dann den Back-Button, dann wird die Reiter-Seite wieder angezeigt. Dabei sind 2 Fälle zu unterscheiden:

• Euer Code, der location.hash NICHT verändert: da der Ankername noch immer #pane-form lautet, wird das Cookie (das auf pane-links zeigt) ignoriert und der Besucher sieht wieder das Formular, statt der Links, von woher er kam.
• Mein Code, der location.hash ändert: der Ankername ist # (oder #something), kein Panel hat eine solche Id und deshalb wird der Ankername nicht ausgewertet. Stattdessen tut das Cookie seine Wirkung und der Links-Reiter ist offen.

Interagiert der Besucher mit dem Formular oder der Galerie, dann wird der Anker beim Reload gelöscht und nur das Cookie zeigt Wirkung.

Weil es auf einer Seite mehrere Tab-Gruppen geben kann. Dann kann doch ein #something nichts bringen ...

Gutes Argument. Ich habe den Code nochmal überarbeitet (siehe Anhang). Er erwartet jetzt, dass auch das Reiter-Element (Betriebsart Reitergruppe) eine CSS Id bekommt. Dann wird location.hash beim Reload auf diese Id gesetzt. Das führt dazu, dass der Browser zu den Reitern springt, diese also gerade eben sichtbar sind (wenn die Seite nach unten genug Platz hat). Das passiert auch nicht bei jedem Umschalten der Reiter, wie im alten Code, sondern nur noch beim ersten Reload (und nur wenn ein gültiger Anker gesetzt war). Und es funktioniert auch mit mehreren Reitergruppen, weil immer die ID des zur Gruppe gehörigen DIVs herangezogen wird. Die Reitergruppen können in ein und dem selben Artikel sein (funktional verbunden, Öffnen eines Reiters schließt die Reiter auch der anderen Gruppe(n)), oder in mehreren Artikeln im selben oder verschiedenen Layoutbereichen.

Noch eine Bemerkung zu location.hash: ich würde ja am liebsten den hash komplett löschen ... aber das geht nicht, aus mir unerfindlichen Gründen, in keinem Browser und keiner Browserversion. Daran haben sich offenbar schon viele andere Programmierer die Zähne ausgebissen.

Deshalb halte ich das jetzt implementierte Verfahren für das beste Verhalten und es funktioniert auch in den meisten Browsern (Opera, Firefox, IE, Safari) ... nur Google Chrome schießt quer: obwohl der modifizierte hash in der URL korrekt angezeigt wird zaubert Chrome bei einem Back (nach Folgen eines Links) den alten hash wieder hervor und der Besucher landet im falschen Tab, so als ob das Verändern des hash nie stattgefunden hätte. Nach stundenlanger Recherche und Experimenten kann ich nur sagen: Scheiß drauf, Google sollte sich schämen. Safari, der ja auch die WebKit Engine benutzt, verhält sich richtig, der Fehler liegt also vermutlich nicht im WebKit.

Über Test-Berichte, auch mit mehreren Reitergruppen, und vor allem auch mal mit Links in den Panelen, würde ich mich freuen.

LG, Georg

PS1: ich gehe auch davon aus: wer JS erlaubt, der erlaubt auch Cookies

PS2: ich habe bisher nicht mit ineinander verschachtelten Reitergruppen experimentiert. Im Gegensatz zu verschachtelten Akkordeons halte ich das auch nicht für sooo sinnvoll. Auch denke ich, dass der Autor von TabControl so etwas nicht wirklich vorgesehen hat. Zumindest das Feature der Öffnung von Reitern durch Ankernamen würde ja nur für die äußere Ebene funktionieren. Um auch die innere Ebene gezielt zu öffnen bräuchte es Code, der automatisch auch die äußere Ebene an der richtigen Stelle öffnet. Wäre theoretisch natürlich möglich, ich finde aber keinen diesbezüglichen Code. Falls also jemand verschachtelte Reitergruppen verwendet, bitte melden.

PS3: wäre schön, wenn sich auch mal der Entwickler von TabControl kurz äußern würde.

[soweit_ok]

Vielen Dank für das ausführliche Feedback und den neuen Code. Morgen bin ich unterwegs und kann nicht testen. Montag wahrscheinlich dasselbe, aber bis Die. sollte ich es eigentlich mal hinkriegen.

[soweit_ok]

Hallo Georg,

ist doch einen Tag später geworden mit dem Testen. Hab den neuen Templatecode eingesetzt, jeder Reitergruppe und jedem Pane eine eindeutige Id gegeben. Dann erstmal wieder mit erlaubten Cookies probiert - alles okay. Danach Cookies in den Browsereinstellungen verboten. Dann funktioniert es leider nicht, weder bei Klick auf "Reload" noch bei Rückkehr von einem Linkbesuch. Also es wurde nicht das zuletzt offene, sondern das erste Pane angezeigt.

Hab ich vielleicht irgendwas falsch gemacht oder klappt es mit dem neuen Code doch noch nicht? Wundert mich, denn Du hast es doch bestimmt ebenfalls getestet.

Auf der getesteten Seite habe ich zwei Reitergruppen.

Auf verschachtelte Reitergruppen lege ich ebenfalls keinen Wert. Ich fände das für die Besucher etwas verwirrend und es sähe nach meiner Ansicht auch optisch nicht unbedingt schön aus. Sehe ich bei Accordions genauso, außer bei FAQ, wo es anwendungstechnisch wirklich Sinn macht. Ansonsten kann man es mit der Komplexität von Inhaltselementen auch übertreiben - ich mag halt gern übersichtliche und bereits auf den ersten Blick plausible Gestaltung.

HG Andreas

[zonky]

... bin im Urlaub - darf nur eMail angucken aber nix anfassen... ;-)

=> nächste Woche wieder

zonky