Blog



Tree ersetzt Menu

Ich habe intern Kritik erhalten wegen dem Menu.prg. Langsam gibt es zu viele Optionen und das macht die Bedienung nicht gerade einfach. Also habe ich zusammen mit einem kleinen Team nach einer neuen Möglichkeit gesucht, wie man die Navigation einfach und trotzdem flexibel realisieren kann. Herausgekommen ist tree.prg.

Als Parameter erhält es die Vorlage, die benutzt werden soll (es gibt nur eine). Weiterhin stehen 3 Schalter zur Verfügung:
  • ifnotexist
    Gibt Punkte in der Defaultsprache aus, wenn er in der aktuellen nicht existiert

  • all
    Blättert das komplette Menü auf, nicht nur den Pfad zum aktuellen Punkt

  • pathactive
    Stellt alle Punkte zum aktuellen als Aktiv dar
Beispiel für die Benutzung: {execmacro="tree" param="template=mainmenu;all;"}

Die Vorlagen enthalten dann schlicht den HTML-Code mit ein paar Platzhaltern, die Schleifen darstellen. Hier einfach 3 Beispiele:
Beispiel 1:
<ul>
{loop_level_1}
  <li><a {ifactitem_level_1}class="act" {/ifactitem_level_1}href="{link}">{title}</a>
  {level_2}
    <ul>
    {loop_level_2}
      <li><a {ifactitem_level_2}class="act" {/ifactitem_level_2}href="{link}">{title}</a>
      {level_3}
        <ul>
        {loop_level_3}
          <li><a {ifactitem_level_3}class="act" {/ifactitem_level_3}href="{link}">{title}</a>
          {level_4}
            <ul>
            {loop_level_4}
              <li><a {ifactitem_level_4}class="act" {/ifactitem_level_4}href="{link}">{title}</a></li>
            {/loop_level_4}
            </ul>
          {/level_4}
          </li>
        {/loop_level_3}
        </ul>
      {/level_3}
      </li>
    {/loop_level_2}
    </ul>
  {/level_2}
  </li>
{/loop_level_1}
</ul>
Gibt beim Aufruf mit Parameter all den kompletten Baum in einer HTML-UL-Liste aus.

Beispiel 2:
{loop_level_1}
  {level_2}
    {loop_level_2}
       <a {ifactitem_level_2}class="act" {/ifactitem_level_2}href="{link}">{title}</a>
      {level_3}
        {loop_level_3}
           <a class="menl3{ifactitem_level_3} act{/ifactitem_level_3}" href="{link}">{title}</a>
        {/loop_level_3}
      {/level_3}
    {/loop_level_2}
  {/level_2}
{/loop_level_1}
Gibt ein Untermenü ab Ebene 2 aus. Darstellung recht einfach als Links.

Beispiel 3:
{[8]if="{[9]level}#0"}
Sie sind hier:
{loop_level_1}
  {ifactitem_level_1}<a href="{link}">{title}</a>{/ifactitem_level_1}
  {level_2}
    {loop_level_2}
      {ifactitem_level_2} - <a href="{link}">{title}</a>{/ifactitem_level_2}
      {level_3}
        {loop_level_3}
          {ifactitem_level_3} - <a href="{link}">{title}</a>{/ifactitem_level_3}
          {level_4}
            {loop_level_4}
              {ifactitem_level_4} - <a href="{link}">{title}</a>{/ifactitem_level_4}
            {/loop_level_4}
          {/level_4}
        {/loop_level_3}
      {/level_3}
    {/loop_level_2}
  {/level_2}
{/loop_level_1}
{end}
Eine Brotkrummennavigation. Dazu ist der Parameter pathactive notwendig, da nur aktive Punkte ausgegeben werden. Die If-Abfrage Außenrum sorgt übrigens dafür, dass auf der Startseite nichts angezeigt wird. Macht da ja keinen Sinn. Der Platzhalter {level} dazu ist auch neu.

Neben den Platzhaltern, die man in den Beispielen sieht, gibt es noch diese:
  • Zwischen {ifnotactitem_level_X} und {/ifnotactitem_level_X} bleibt nur etwas übrig, wenn der aktuelle Punkt NICHT aktiv ist.
  • Was zwischen {ifnotlast_level_X}  und {\ifnotlast_level_X}steht wird nur ausgegeben, wenn der aktuelle Punkt nicht der letzte ist.
Ansonsten sind die gleichen Platzhalter für die eigentlichen Punkte möglich, wie beim menu.prg. Also:
  • {name}
  • {date}
  • {description}
  • {keywords}
  • {title}
  • {link}
{counter} zählt dann noch die Schleife mit. Damit kann man dann sehr spezielle Lösungen machen, z.B. besondere Trennlinien zwischen Menü-Hälften, andere Farben für jeden Punkt usw..

Weil Dinge wie eben eine Brotkrumennavigation oder eine Sitemap möglich sind, nennt sich dieses Modul nun eben Tree und nicht mehr Menu.

Wenn man ein neues HTML-Design macht und darin ein Beispiel-Menü enthalten ist, kann man dieses nun einfach mit den "level-Tags" versehen und hat im Handumdrehen ein funktionierendes Menü.

Übrigens:
Neu sind neben dem Platzhalter {level} auch noch:
  • {systemname}
  • {systemurl}
  • {systemadminname}
  • {systemadminmail}
  • {systemsendermail}
Die jeweils einfach den Wert ausgeben, der in der eforia.ini entsprechend hinterlegt ist.  Der Sinn des Ganzen ist, nur an einer Stelle die URL des Systems, den Namen und solche Angaben ändern zu müssen. Das ist bei der Ersteinrichtung eine Hilfe. Diese Platzhalter können auch in allen Mailvorlagen benutzt werden.

Außerdem können {title}, {name}, {lfd}, {id}, {poscount} und {position} nun mit einem Prefix aufgerufen werden. Als Prefix ist parent, prev und next erlaubt. Beispielsweise gibt {parent.id} die ID der Elternseite aus. Das kann man benutzen, um Vorlagen in Abhängigkeit des Überpunktes verschieden reagieren zu lassen. Als eindeutiges Kriterium ist die ID sowieso nicht schlecht. Sie kann leichter eindeutig gehalten werden wie der Name und ist doch änderbarer als die Lfd. Wenn man z.B. mit Entwürfen arbeitet oder verschiedenen Sprachversionen ist die Lfd als Ziel eher weniger geeignet. Die ID bleibt auch gleich, wenn eine Seite verschoben wird, im Gegensatz zum Namen. Deshalb ist das Feld für die ID nun etwas größer und auch alphanumerische Angaben möglich.
Michael [Link entfernt, weil Linkziel leider nicht mehr verfügbar] wollte schon seit Langem, dass die ID etwas mehr genutzt wird.


Dieser Artikel wurde veröffentlicht am 22.05.2010 um 16:56 Uhr. Noch kein Kommentar.

Tester für menu.prg gesucht

Das neue Design für die ewm5 Standardvorlage habe ich ja bereits vorgestellt. Nun musste ich beim Umsetzen das Menu-Modul etwas anpassen. Das obere Menü ist nämlich im HTML-Code eine <ul>, die den kompletten Baum abbildet. Per CSS wird dann die Darstellung geregelt. Um aber die Baumstruktur abzubilden, musste ich festlegen können, wie das Menü-Modul die Zwischen-Templates einfügt, wenn weitere Kindelemente kommen. Also vereinfacht gesagt, es muss ein Unter-<ul> geöffnet werden, bevor das vorhergehende mit </li> beendet wird. Bisher konnte man das nicht bestimmen, jetzt gibt es eine Option afterchild.

Außerdem wollte ich, dass zusätzlich ein Untermenü links erscheint, aber nur wenn es gebraucht wird. Weil es schöner aussieht, wenn ein wenig "Eye-Candy" herum ist, das aber auch nur angezeigt werden soll, wenn auch ein Menü kommt (eine leere Box ist einfach unschön), habe ich die Vorlagen before und after eingeführt. Also komplett z.B. menu/before_1. Gerade bei der aftter-Vorlage spielt dann auch wieder das afterchild eine Rolle.

Weil ich nun einerseits das Hauptmenü habe, dann das Untermenü und beide mit verschiedenen Vorlagen auskommen sollen, habe ich gleich noch den Parameter template=xxx eingefügt, mit dem dann die Vorlagen bestimmt werden. Also wird z.B. statt menu/button_1 dann menu/xxx/button_1 genommen.

Und zu guter Letzt habe ich auch noch die Parameter ifnotexist, all und switch in die Parameterliste genommen. Bisher mussten die in der menu.ini angegeben werden, jetzt geht es auch einfach als Parameter.

Die Konfiguration in den Tools habe ich dafür entfernt. Ich glaube so wirklich benutzt hat das doch niemand, oder? Ich bin generell am Aufräumen und versuche unnötige Dinge zu entfernen. Beispielsweise wird das News-Modul nicht mehr dabei sein. Das kann man mit anderen Mitteln besser lösen. Keine Angst, wer etwas einsetzt, kann das schon weiter machen. Ich nutze es ja selbst auch in vielen Projekten. Aber wer neu beginnt, sollte es dann eben gleich mit Bordmitteln lösen. Das wird im "Auslieferungszustand" auch gleich eingerichtet sein.

Langer Rede, kurzer Sinn: Das menu.prg hat doch einige Änderungen erfahren. Ich bräuchte mutige Tester, die einfach mal die bestehende menu.prg im custprg-Verzeichnis gegen die neue ersetzten und mir sagen, falls das Menü dann nicht mehr funktioniert wie es sollte. Die alte menu.prg bitte als Kopie behalten, damit diese bei Problemen sofort wieder eingesetzt werden kann.

Download menu.prg als ZIP hier.


PS: Es sieht derzeit ganz gut aus, dass ich den Quellcode komplett und kompilierfähig veröffentlichen kann. Also auch die Teile, bei denen die Rechte bei der tdb GmbH liegen sollen wieder unter GPL veröffentlicht werden (war bis 16.8.08 schon mal unter GPL). Ich bin mir noch nicht ganz sicher, wie ich das machen soll (ZIP, SVN, GIT). Vielleicht hat ja jemand Vorschläge oder Wünsche?

Dieser Artikel wurde veröffentlicht am 18.05.2010 um 21:08 Uhr. Ein Kommentar.
Zeige 1 - 2 von 2


Hier bloggt Horst Klier mit und über eforia web manager und was dazugehört (HTML, Javascript, Internet, Webdesign, Such- maschinenoptimierung, usw.).

>> Zur Blog Startseite

RSS-Feed
abonnieren


Übersicht über alle Beiträge



eforia® ist ein eingetragenes Markenzeichen.
Alle anderen Marken und Markenzeichen gehören Ihren jeweiligen Besitzern.
Letzte Aktualisierung dieser Seite: 03.03.2024 / 16:20:42
Suche  
Login / Userdaten
Impressum/Datenschutz