(hai)હેલો
Es gibt noch die Breadcrumb-Geschichte,
[] der Rest von dir ist mir zu Hoch. Menu,
Der Vollständigkeit halber, nicht dass ich hier blogge, wir haben ein interessantes Gespräch, zunächst ein schönes Stück Code betr. Breadcrumb:
foreach my $em(@{$self->{MENU}}){
push @{$stash{menu}}, {
linkname => $self->{BIN}{$em}{short} || $self->{DBF}->eav_hunt($em)->{short} || 'NA',
href => $em ne $ENV{REQUEST_URI} ? qq(href="$em") : '',
active => $em eq $ENV{REQUEST_URI} ? 1 : 0,
descr => $self->{BIN}{$em}{descr} || $self->{DBF}->eav_hunt($em)->{descr},
};
}
Schön ja, aber schlecht organisiert, ich schrieb da was von Extrawürsten, Du siehst diese an der Zuweisung für linkname und descr. Da wird einmal in die BIN gegriffen und wenn da der Wert fehlt, wird er mit $self->{DBF}
aus der Objekts-Datei nachgeladen. D.h., der Datenfluss ist hier inkonsistent, der wäre so zu konsolidieren, dass ALLE Methoden, welche auf im Request beteiligte Attribute zugreifen, dies NUR über $self->{BIN}
tun sollten. Der Code ist dann einfacher zu pflegen.
Die Lösung liegt schon parat:
%{$self->{BIN}} = (%{$self->{BIN}}, %breadcrumbs);
Wobei der hash %breadcrumbs
vorher am Stück ermittelt wird über eine Liste der URLs, welche den Breadcrumb ergeben sollen. Über den Data-Abstraction-Layer (persistent Objects, egal an welchem Speicherort, MySQL oder Datei...) wir die Routing-Table dann nur noch an zwei Stellen im Code zusammengebaut, ein etwaiger Austausch des DAL wird weiter vereinfacht, aber darüber denke ich erst nach, wenn es mehr als 1000 Unterseiten sind ;)
Gute Nacht ;)