[tabcontrol]

Zitat:

---

Zitat von schman

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. :)

Ich schon wieder. :)

Hab´s gefunden ...

Code:

---

                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.

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

PHP-Code:

---

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


---

zonky

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:

PHP-Code:

---

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

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

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?

Hallo alle,

Zitat:

---

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.

Zitat:

---

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.

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.

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

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

=> nächste Woche wieder

zonky

Zitat:

---

Zitat von zonky

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

---

Ist auch ganz gut so, dass Du nix anfassen darfst. Hast Du mehr vom Urlaub. :D Dann noch viel Spaß und tolles Wetter!

Moin,

Zitat:

---

Zitat von soweit_ok

Hab den neuen Templatecode eingesetzt, jeder Reitergruppe und jedem Pane eine eindeutige Id gegeben. Dann erstmal wieder mit erlaubten Cookies probiert - alles okay.

---

Schön zu hören, das ist ja immerhin der Normalfall (Cookies und JS erlaubt).

Zitat:

---

Zitat von soweit_ok

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.

---

Ich gestehe, dass ich diesen Fall nicht getestet habe, weil ich ihn für zu ungewöhnlich hielt (Cookies verboten, aber JS erlaubt). Aber wie gut, dass Du das getestet hast. Du hast damit einen Bug im Original TabControl aufgedeckt, der auftritt, sobald man mehr als eine Reitergruppe pro Seite hat. Entweder in ein und dem selben Artikel (wie es vermutlich bei Dir der Fall ist?): Öffnen eines Reiters in einer Gruppe schließt alle Reiter auch der anderen Gruppe. Oder in verschiedenen Artikeln (egal ob in einem oder verschiedenen Layoutbereichen): die Reitergruppen sind dann völlig unabhängig voneinander.

Der Bug im Original ist, dass JEDE Reitergruppe per Template ce_tabcontrol_tab.tpl einerseits den kompletten JS Code einbringt und andererseits, vor allem, die Anweisung window.addEvent('domready', loadTabControls); jedesmal einfügt. MooTools macht dann stur das, was befohlen wurde: es führt die Funktion loadTabControls() mehrfach aus (window.addEvent('domready', xxx); baut eine Queue von auszuführenden Funktionen auf).

Hat man also 2 Reitergruppen, dann wird der JS-Code 2 mal durchlaufen. In der Folge gibt es für jede Reitergruppe ZWEI TabControl Klassen (insgesamt 4 Klassen statt der 2 erforderlichen), der onChange Event feuert dann auch ZWEIMAL kurz hintereinander. Im Original fällt das nicht weiter auf, der Code macht halt zweimal kurz nacheinander (sinnloserweise) das Gleiche.

Aber in meinem Code wird beim ersten Durchlauf der Hash (korrekt) geändert auf die Id der Reitergruppe ... im unerwünschten/überflüssigen 2. Durchlauf wird dieser Hash aber nicht mehr als Id eines Panels erkannt und deshalb werden dann die Reitergruppen mit Voreinstellung geöffnet. (Mit Cookies an springen die dann ein und richten es).

Vorläufig habe ich bei mir das mehrfache Ausführen der Funktion loadTabControls() mit einem Flag verhindert und damit geht es dann auch mit Cookies aus/JS an ... aber das ist sicher nicht der Weisheit letzter Schluss. Ich suche gerade einen eleganten Weg, den Code und das Hinzufügen zu domready automatisch und zuverlässig nur EINMAL zu machen, auch bei mehreren Reitergruppen.

Außerdem arbeite ich gerade an einem weichen Rollen. Funktioniert auch schon für eine Reitergruppe bzw. mehrere Reitergruppen im selben Artikel. Hat aber noch systematische Probleme für Reitergruppen in verschiedenen Artikeln. Insbesondere, wenn diese in Y Richtung sehr weit voneinander entfernt sind.

Deshalb leider noch kein guter Code ... nur der vorläufige Patch zur Verhinderung des mehrfach Ladens:

PHP-Code:

---

   function loadTabControls() {
+    if (this.loadedTabControlsAlready) {
+      return;
+    }
+    this.loadedTabControlsAlready = true;
     $$('div.mod_article').each(function(el, idx) {
       var xcookieBase = el.id ? 'tabcontrol_' + el.id : 'tabcontrol_x' + idx; 


---

LG, Georg

Hi Georg,

hmmh, dass wir es beide unwahrscheinlich finden, JS an und Cookies aus, darüber hatten wir uns ja schonmal unterhalten. Hab´s halt trotzdem mal getestet, um zu sehen, was passiert. Stimmt, meine beiden Reitergruppen auf der getesteten Seite liegen im selben Artikel. Mein Testcase sieht so aus: In der einen sind mehrere Fotogalerien und ein Tutorial, in der anderen ganz unten über dem Footer das Kommentarmodul und Verwendungshinweise. Und in beiden Gruppen ist der rechte Reiter ohne Inhalt. Ihn schmückt eine "X"-Grafik, der dient als Ausknipsknopf. Wenn man auf diesen Reiter klickt, verschwinden alle Panes der Gruppe und nur die Kopfzeile mit den Reitern bleibt dann sichtbar.

So, eben Deinen Codeschnipsel eingefügt und wieder dasselbe probiert, JS an, Cookies aus. Tja, leider hat es nichts verändert. Der Rücksprung funktioniert nicht. Nach wie vor immer der erste Tab geöffnet und die Positionierung im Viewport erfolgt unabhängig von den Reitergruppen einfach dorthin, wo ich vorher war. Na klar, wenn beim Klicken auf einen Link die Reitergruppe im Viewport zu sehen war, ist sie es exakt genauso nach der Rückkehr (außer eben, dass immer das erste Tab geöffnet ist), doch das hat überhaupt nichts mit der Reitergruppe zu tun.

Ohne es ausprobiert zu haben, folgere ich daraus, dass es ohne Cookies UND ohne JS genausowenig funktioniert, wäre ja sonst unlogisch. Und diese Konstellation ist widerum öfter gemeinsam anzutreffen.

Zuguterletzt hab ich auch noch "ohne JS, mit Cookies" ausprobiert. Tja, da geht dann schon beim ersten Laden garnichts. Sämtliche Panes aller Reitergruppen sind nicht nur offen, sondern die Divs erscheinen auch alle untereinander statt nebeneinander. Sieht nicht wirklich schlimm aus, nur ziemlich raumgreifend. Und bei Klick auf die Reiter passiert so logischerweise auch nichts. Bei den Accordiongruppen ist es übrigens genau dasselbe, in #main genauso wie in #right. Ist das bei Dir genauso oder könnte es vielleicht ebenfalls damit zusammenhängen, dass ich mehrere im selben Artikel habe?

Vielleicht ganz interessant für den ein oder anderen.

TabControl Autoplay

http://www.contao-community.de/showt...ntrol-Autoplay

Danke für den Tipp. Hatte es gestern schon entdeckt. Aus der Beschreibung bin ich allerdings noch nicht so richtig schlau geworden, weil garnichts zu den Steuerungsoptionen erwähnt ist. Ob z. B. eine Benutzeraktion in einem der Tabs das aut. Wechseln stoppt.

@soweit_ok

Die Anzeigedauer der Tabs kann eingestellt werden.
Wenn sich der Mouse-Zeiger auf einem Reiter befindet - stoppt der Autoplay - startet dann wieder, sobald der Mouse-Zeige die Tabs verlässt.

Beispiel: http://www.wbg-premnitz.de/

Hi Christian,

danke für die Info. Ich verwende allerdings das modifizierte Templat von Georg, über dessen Funktion wir in diesem Thread diskutieren. Um Dein Autoplay zu verwenden, würde ich dementsprechend den Scriptcode mit dieser Funktion erweitern. Das Default-Verhalten von ce_tabcontrol, ob nun mit oder ohne Autoplay, nach einem Reload stets den ersten Tab zu öffnen, gefällt mir halt nicht.

Weil mit der erweiterten Funktionalität nun immer automatisch der zuletzt offene Tab geöffnet wird, würde ein Autoplay-Restart nach Verlassen des Fokus diesem Konzept zuwiderlaufen. Daher meine Frage - für eine harmonische Integration wäre das Autoplay-Feature insoweit zu ändern, dass es nach Mausklick in einem Element nicht fortsetzt, auch nicht nach Rückkehr von einem im Tab besuchten Link. Soll also nur beim initialen Laden der Seite anspringen. Auch müsste für eine Reitergruppe "Autoplay:nein" konfigurierbar sein, z. B. per Anzeigedauer=0.

@soweit_ok

Eigenschaften des CE ... siehe Anhang.

Lass uns bitte hier diskutieren http://www.contao-community.de/showt...ntrol-Autoplay

Neue Version am Start.

http://www.contao.org/erweiterungsli...030009.de.html

• Contao 2.10.x fix
• Autoplay integration

Hallo Christian,

nach einem Update von 1.1.4 auf 1.3.0 sind die TABs im Frontend alle ausgeklappt. Nach einem Downgrade auf 1.1.4 geht alles wieder. Müsste ich noch irgendwas beachten bzw. ändern, was ich in der Eile überlesen habe?

Contao 2.10.3, keine Änderungen an fe_page, Ausgabeformat XHTML Strict.

Kann ich bestätigen, funktioniert für mich leider auch nicht. Alle Inhaltselemente untereinander, keine Funktion, obwohl tabcontrol.js laut Quelltext eingebunden ist.
Tabcontrol 1.3.0, frische Contao-Installation 2.10.3.

Gruß
Michael

@Peter & Michael

Kann man das mal im Web sehen?
Habt ihr "Daten bereinigen" (Contao Systempflege) nach dem Update durchgeführt?

Dasselbe hier. Dateien bereinigt. Alle Tabs ausgeklappt.

Gruß
Cazzari

Zitat:

---

Zitat von Cazzari

Dasselbe hier. Dateien bereinigt. Alle Tabs ausgeklappt.

Gruß
Cazzari

---

Hast du Mootools eingebunden?

Hab zum Test die Erweiterung komplett neu auf einem 2.10.3 System installiert (also kein Update) und
dort funktioniert die Erweiterung.
Nur die Klasse .ce_tabcontrol wurde auf .ce_tabcontrol_tabs geändert.

Hallo,

ich habe an der Erweiterung mitgearbeitet.
Die Erweiterung ist für Contao 2.10 gedacht.
Auf meinerTestseite ist MooTools (1.3.2) über google und MooTools-More eingebunden.
Vieleicht fehlt dieses oder ggf. eine falsche Version?



Gruß
Mirco

Zitat:

---

Zitat von MiRa

...
Auf meinerTestseite ist MooTools (1.3.2) über google und MooTools-More eingebunden.
...

---

Funktioniert auch mit dem Contao Mootools.

Zitat:

---

Zitat von christian.barkowsky

Hast du Mootools eingebunden?

---

Ja, Mootols sind eingebunden.
Ich habe wieder die alte Version installiert. Alle Tabs sind eingeklappt.

Gibt es eine Schritt-für-Schritt Anleitung für den Update-Vorgang?

Gruß
Cazzari

Fehler gefunden.

Stellt man die Ausgabe im Seitenlayout auf HTML funktioniert es.
Sorry ... Fehler im XHTML Template ... wird morgen behoben. :rolleyes:

Habe ebenfalls seit gestern das Problem. Ich habe soeben die Erweiterung erneut geupdatet aber es hat sich noch nichts getan.
Muss ich vllt noch was am Template machen?

Zitat:

---

Zitat von Chris87

Habe ebenfalls seit gestern das Problem. Ich habe soeben die Erweiterung erneut geupdatet aber es hat sich noch nichts getan.
Muss ich vllt noch was am Template machen?

---

Entweder auf HTML (HTML5) umstellen oder aber die 1.2.0 einspielen.

Sorry. :(
Update kommt.

Achso ok, dann warte ich noch. Danke.

ich hab das ganze auf html5 zu laufen.
Tabs nun alle untereinander sichtbar. Contao 2.10.2 im Internet explorer 7

hab die screenshots vor mir, auf meinem IETester kann ich es aber nicht reproduzieren!

updates sind eingespielt und werd mal morgen abwarten, bis der kunde mit seinem echten IE7 das ganze prüft :)

PS: danke für den netten Anruf... das ist ja mal nen Support... irre :D

@ways2web ;)

Nun kann wieder aktualisiert werden ... nun sollten alle Fehler raus sein.

Sorry für die Unannehmlichkeiten.

Christian hat ein Update ins ER gestellt. Diese aktuelle Version 1.3.0 Build 20 funktioniert nun auch mit XHTML bestens. Eben getestet auf Firefox 8 und IE 6 bis 9.

Herzlichen Dank, Christian!

Gruß
Michael

Update: Christian war schneller :)

Guten morgen.

ich bin gerade am Testen von tabcontrol. Die reiter werden bei mir als Liste angezeigt. Wie bekomme ich es hin, dass es Reiter werden?

http://www.fischbacher-sv.de/contao/...es/verein.html

Gruß

Zitat:

---

Zitat von gerdi

Guten morgen.

ich bin gerade am Testen von tabcontrol. Die reiter werden bei mir als Liste angezeigt. Wie bekomme ich es hin, dass es Reiter werden?

http://www.fischbacher-sv.de/contao/...es/verein.html

Gruß

---

ein link zu deinem backend hilft uns da nicht viel :(

Sorry

http://www.fischbacher-sv.de/verein.html

Hallo gerdi,

Zitat:

---

ich bin gerade am Testen von tabcontrol. Die reiter werden bei mir als Liste angezeigt. Wie bekomme ich es hin, dass es Reiter werden?

---

Indem Du das Template anpasst:

Code:

---

<!-- indexer::stop -->
<script type="text/javascript">
<!--//--><![CDATA[//><!--
 function loadTabControls() {
  $$('div.mod_article').each(function(el, idx) {
  var xcookieBase = el.id ? 'tabcontrol_' + el.id : 'tabcontrol_x' + idx;
  var xtabs = el.getElements('<?php echo $this->tabsSelector; ?>');
  var xpanes = el.getElements('<?php echo $this->panesSelector; ?>');
  var xinitialTab = '';
  if (Cookie.read(xcookieBase) && !isNaN(parseInt(Cookie.read(xcookieBase)))) {
    var initialIndex = parseInt(Cookie.read(xcookieBase));
    if (initialIndex >= 0 && initialIndex < xpanes.length && initialIndex < xtabs.length) {
    // give precendence to anchor
    var anchoredPane = $(location.hash.substr(1));
    if (anchoredPane) {
      xpanes.each(function(pane, index) {
      if (anchoredPane === pane) {
        initialIndex = index;
      }
      });
    }
    xinitialTab = xtabs[initialIndex];
    }
  }
  new TabControl(el,
  {
    cookieBase: xcookieBase,
    initialTab: xinitialTab,
    behaviour: '<?php echo $this->behaviour; ?>',
    tabs: xtabs,
    panes: xpanes,
    selectedClass: 'selected',
    hoverClass: 'hover',
    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 = '';
    }
  });
  });
 }
 window.addEvent('domready', loadTabControls);
//--><!]]>
</script>
<!-- indexer::continue -->
<div class="<?php echo $this->class; ?>_tabs block"<?php echo $this->cssID; ?><?php if ($this->style): ?> style="<?php echo $this->style; ?>"<?php endif; ?>>
<ul>
<?php foreach ($this->titles as $title) : ?>
 <li class="<?php echo $this->tabs; ?>"><?php echo $title; ?></li>
<?php endforeach; ?>
</ul>
</div>

---

Und es per CSS Stylest:

Code:

---

/* ---------------- Style TabControl --------------- */
.ce_tabcontrol_tabs ul li
{
 float:left;
 display:block;
 margin-right:3px;
 margin-left:3px;
 padding:8px 10px 8px 6px;
 text-align:center;
 background-color:#e6e6e6;
 font-size:12px;
 color:#666699;
 list-style-type:none;
 -moz-border-radius:7px 7px 0 0;
 -webkit-border-radius:7px 7px 0 0;
 border-radius:7px 7px 0 0;
 behavior: url(PIE.htc);
}
.ce_tabcontrol_tabs ul li.selected
{
 padding:8px 10px 8px 6px;
 font-size:12px;
 color:#A84204;
}
.tabs
{
 font-weight:bold;
}
.hover
{
 cursor: pointer;
}
.panes
{
 padding-bottom:10px;
 background-color:#e6e6e6;
 -moz-border-radius:7px;
 -webkit-border-radius:7px;
 border-radius:7px;
 behavior: url(PIE.htc);
}

---

:)
Viele Grüße
MiTsch

Hi Mitsch.

Ich habs jetzt nicht ausprobiert und bin auch nicht der Progger, das ich das so aus dem Code sehen würde, aber was macht denn deine Templateanpassung?
Wenn ich tabcontrol angepasst habe, habe ich das pur mit CSS gemacht...

Gruß
Thomas

vielleicht habich es auch einfach übersehen.. aber ich sah nirgens das css fürs tabcontrol

gruss
ways

Zitat:

---

Zitat von Southbridge Media

Hallo,

ich habe tabcontrol installiert, leider finde ich nirgendwo eine Möglichkeit die einzelnen Reiter zu definieren. Jemand ein Tipp?

nutze v2.7.2

---

Danke für den Thread! Auch ich stand vor dem gleichen Problem! Die Lösung war für mich Deinstallation... :rolleyes:

Hallo,

danke für Eure Hilfe. Ich werde mich mal daran versuchen. Muss ich im Template die Änderungen auch druchführen oder reicht die CSS Erweiterung?

Gruß

Zitat:

---

Zitat von andrea$

Danke für den Thread! Auch ich stand vor dem gleichen Problem! Die Lösung war für mich Deinstallation... :rolleyes:

---

einfach die Felder in dem Typ Reitergruppe des tabcontrol-elementes ausfüllen, das war es doch schon.

Betriebsart:
Reitergruppe
Panel Anfang
Panel Ende

unter Reitereinstellungen:
dann die felder wie gewünscht anlegen

Der Unterschied zwischen der ungeordneten Liste und hübschen Karteireitern ist nur CSS. Ich habe mich bei der Gestaltung meines ersten [tabcontrol]-Reitersets von jukemedia (Jutta Kemperle) inspirieren lassen:

Spielwiese zu diversen Erweiterungen (sehr interessant)
Beispielseite zu [tabcontrol]

Wie immer: HTML-Struktur und CSS verstehen und dann das CSS für den eigenen Bedarf anpassen.

Zitat:

---

Zitat von pmmueller

Der Unterschied zwischen der ungeordneten Liste und hübschen Karteireitern ist nur CSS. Ich habe mich bei der Gestaltung meines ersten [tabcontrol]-Reitersets von jukemedia (Jutta Kemperle) inspirieren lassen:

Spielwiese zu diversen Erweiterungen (sehr interessant)
Beispielseite zu [tabcontrol]

Wie immer: HTML-Struktur und CSS verstehen und dann das CSS für den eigenen Bedarf anpassen.

---

Danke. Peter trifft wieder auf den Punkt. Genau das meine ich doch. Warum sollte dafür im Template was geändert werden?

Gruß
Thomas

Dann werde ich mal noch ein CSS Bauplan in die Erweiterung packen. ;)

Das ist eine sehr gute Idee. So eine Art Standard-CSS-Theme, sodass es schon ein bisschen wie TAB-Reiter aussieht. Das Standard-Theme können wir dann ja "Corega" nennen ;-)

Hallo,

das wäre supi. Ich tue mich auch schwer. :-)

Hallo, ich benutze die Erweiterung erst seit der Version 1.3.0 b21. Leider bekomme ich den Fehler, der einige Postings vor mir schon aufgetaucht ist trotzdem... Mir werden keine Tabs angezeigt, sondern alle Inhalte ausgeklappt.

Contao v2.10.4 / XHTML strict / tabcontrol.js ist drin / Mootools aktiviert

Link

Danke für die Hilfe.

hallo makai,

du hast leider kein mootools aktiviert.
tabcontrol benötigt aber mootools.

Danke für die Hilfe!

Zitat:

---

Zitat von christian.barkowsky

hallo makai,

du hast leider kein mootools aktiviert.
tabcontrol benötigt aber mootools.

---

Fehlt da noch was?

http://www.abload.de/img/mooxpb2d.png

Du bindest ja jquery ein.

Guck mal bitte bei Themes > Seitenlayouts > Experten-Einstellungen ... dort muss eingestellt werden, das sowohl mootools als auch jquery geladen werden sollen.

Zitat:

---

Zitat von christian.barkowsky

Du bindest ja jquery ein.

Guck mal bitte bei Themes > Seitenlayouts > Experten-Einstellungen ... dort muss eingestellt werden, das sowohl mootools als auch jquery geladen werden sollen.

---

Entschuldige, dass du mir alles vorkauen musst :) Ich seh unter den Experteneinstellungen nichts dergleichen. Kann das daran liegen, dass ich jQuery direkt über das Template einbinde und nicht über eine Extension?

Moin makai,

Zitat:

---

Zitat von makai

... Kann das daran liegen, dass ich jQuery direkt über das Template einbinde und nicht über eine Extension?

---

das wird es sein. Dann laufen jQuery und Mootools nicht im noConflict-Mode.

Installier dir die Extension [jquery]. Dann kannst die vorgegebenen Einstellungen vom Christian vornhemen und musst jQuery nicht mehr über das Template einbinden.

Grüße, Cliff

Danke für die Hilfe ihr beide. Leider ändert sich auch nichts bei folgenden Einstellungen (s.u.). Auch wenn ich alles an (jQuery-)JS auskommentiere und ich nur MooTools lade werden mir keine Tabs angezeigt. Ist das vielleicht ein Fehler im xhtml-Template?

http://www.abload.de/img/bgmy41.png

Und wenn du mal <script src="./tl_files/tsv_layouts/js/miscellaneous.js" type="text/javascript"></script> und $.noConflict(); auskommentierst?!?

HALT STOP ...

Deine Anpassungen in der fe_page machen die Probleme.

Normalerweise wird erst Mootools eingebunden und dann das taccontrol.js ... bei dir ist es genau andersrum.

Zitat:

---

Zitat von christian.barkowsky

HALT STOP ...

Deine Anpassungen in der fe_page machen die Probleme.

Normalerweise wird erst Mootools eingebunden und dann das taccontrol.js ... bei dir ist es genau andersrum.

---

HALT STOP :) -> Genau das wars :)

Leider doch nicht. Wenn ich $this->head; nach unten verschiebe und NC anschalte funktionieren die Tabs aber der jQuery-Slider und das Superfish-Menü nicht mehr. Sobald ich NC ausschalte funktioniert wieder alles außer die Tabs.

Warum nimmst du nicht das Original fe_page Template???
Den Rest sollten doch die Module selber machen ...

Das Template basiert größtenteils auch auf fe_page, nur der header wurde eben stark modifiziert. Meine einzige Alternative ist es also alles von jQuery auf MooTools über Extensions zu münzen? Wieso klappt dann das Akkordeon problemlos?

Das tabcontrol JS darf erst nach dem Mootools JS eingebunden werden ... sonst klappt das nicht.

Wie ich aber sehe ... funktioniert es nun.

Hallo,

wie kann ich auf einer Seite mehrere tabcontrols betreiben?
Wenn ich bei mir 3 x tabcontrol anlege bekomme ich nur das erste angezeigt
die anderen zeigen keinen Inhalt.

Danke

Gruß
Christian

Erste Idee, ohne zu wissen, wie das bei dir aufgebaut ist... mehrere Artikel.
Ich meine, ich hatte ads Problem auch mal... und habs so gelöst.

Gruß
Thomas

Hallo,

hab die ne PN geschickt.

Hallo an alle,

ich wollte in der Contao Version 2.11 den Tabcontrol verwenden, leider vergebens.

Unter Contao Version 2.10.3 funktioniert Tabcontrol problemlos.

Habt Ihr da schon Erfahrungen machen können?

Beste Grüße

Steffen

Moin moin,

das Update kommt heute.

Ready for Contao 2.11

http://www.contao.org/de/extension-l...030019.de.html

Hallo Zusammen,

ich glaube, an dieser Stelle ist mein Beitrag besser aufgehoben.
Ich habe Ebenfalls Probleme mit Tabcontrol. Hier mein Beitrag mit
einer großen Bitte! Hat jemand eine Lösung für mich?

https://www.contao-community.de/show...-Zusammenspiel

Danke
avogt