Suche Tester für Schnelleinstieg Icons (directentrys_theme)

Hallo Zusammen

Ich habe eine kleine Extension geschrieben, die mittlerweile jener von easy_themes ähnlich ist.

Sie fügt direkte Links zu CSS, Frontend Modulen und Layout hinzu.

Im Vergleich zu easy_themes, welches verschiedenste Optionen bietet richtet sich meine Erweiterung an all jene, welche ohne Javascript Dropdown und ohne das für jeden User aktivieren zu müssen eine solche Funktionalität wünschen.

Mein Ansatz ist zwar sehr schlicht hat aber seine Tücken, da ich die Ausgabe mit Regular Expressions (Mustererkennung in der Backendausgabe per HOOK) erweitere. Desshalb suche ich Tester, die beobachten ob Sie unerwünschte Veränderungen des Backends wahrnehmen.

directentrys_theme

http://www.dominik-zogg.ch/tl_files/...trys_theme.png

ich teste es :) so sehr ich easy_themes auch mag, der weg über das dropdown ist mir eine bewegung zuviel!

wenn mir was auffällt oder noch irgendwas fehlt meld ich mich :)

Bei easy theme gibts noch den DOM Inject (dann siehts ähnlich aus), auch ohne Dropdown, das muss fairer Weise erwähnt werden.

Danke fürs anschauen.

da muss ich peinlicherweise zugeben das mir die option nie aufgefallen ist!!!

wo besteht dann der unterschied zwischen den extensions?

Zitat:

---

Zitat von jared

wo besteht dann der unterschied zwischen den extensions?

---

Der zusätzliche Inhalt wird nicht nachgeladen, ist viel schlanker (Code) und ist nicht von Benutzereinstellungen, was ich in diesem Fall als Vorteil erachte, abhängig wobei das klar subjektiv ist.

Und ja, man übersieht nicht das es ohne Dropdown auch geht ,)

PS: Ohne Andreas Schempp der mich nach meiner ersten Version darauf aufmerksam gemacht hat, hätte ich von easy_themes eventuell bis heute nichts gewusst :o

Vielleicht auch weil man es über das ER weder über das Stichwort 'easy' noch über 'theme' findet ;-)

Hi,

Du könntest in der "DirectEntrysTheme.php" (Zeile 82 bzw. 87) die kaufmännischen Und's "&" durch das entsprechende Entity "&" ersetzen.

Ansonsten: Sehr schön. Und praktisch.

Hey, sehr fein.
Ich finde/fand bei easy_theme auch immer etwas umständlich, das sich jeder Benutzer die Einstellung wie die Darstellung erscheint, selber einstellen konnte bzw. musste.
In 99% aller Projekte war dieses Szenario bei mir unnötig.

Also sag ich auch mal Danke!

Gruß
Thomas

In Analogie zur Erweiterung "easy_catalog" könnte man auch eine "directentrys_catalog" machen... :)

Ich schau's mir mal an, welche Anpassungen dafür notwendig wären...

Zitat:

---

Wenn dich was an easy_themes stöhrt, dann schreibe einen Patch und schicke ihn Toflar. Aber das hier ist einfach sinnlos. So kommts, dass wird dutzende Erweiterungen haben die das selbe machen und sich keine Sau mehr auskennt.

---

Das sehe ich auch ein bisschen so. Aber trotzdem danke für deine Mühe!

Zitat:

---

Zitat von dominik.zogg@gmail.com

PS: Ohne Andreas Schempp der mich nach meiner ersten Version darauf aufmerksam gemacht hat, hätte ich von easy_themes eventuell bis heute nichts gewusst :o

---

@leo.unglaub - vermutlich liegt das eben daran dass man die easy_themes nicht so einfach über das ER findet?!

Vielen Dank für eure Anregungen und Kritik.

@xchs: Ist gemacht.
@leo: Ich wollte eine möglichst schlichte Lösung, ohne Optionen, möglichst schlank (optisch), mit möglichst wenig Code umsetzen und ohne DOM Inject arbeiten. Ich will meine Idee, welche sich dadurch stark von Toflars Idee unterscheidet, weder aufzwingen, noch als die bessere bezeichnen, so das ich es für sinnvoll erachte, dass es beide Erweiterungen gibt.

Hallo Leo

Obwohl ich nicht gelesen habe, dass ich von Performance gesprochen habe, wollte ich Fakten schaffen.
Dabei habe ich von prepare->()->execute auf query umgestellt und eine Zeitmessung eingebaut.
Folgende Zeit wird benötigt um die ganze Methode abzuarbeiten.

query:
0.0007901192
0.0007801056
0.0007851124

Ich glaube damit leben zu können, getestet auf einer OpenVZ Umgebung in Wien.

Was ich damit ausdrücken wollte ist nicht schlanker Code = schnell, sondern schlanker Code = Entwickler ist schnell und er kann sehr schnell Korrekturen machen. Ich bin der Meinung, dass unsere Zeit viel wertvoller ist, als die paar Euro die ein schlaues Hosting im Jahr mehr kostet. Das muss allerdings jeder für sich selbst entscheiden.

PS: Beim DOM Inject ist das window.addEvent('load'), welches mit zwandläufig auf der fertigen (Grafiken halten sich im Backend ja in grenzen) Aufbau, nochmals nach unten korrigiert, was bei einem zügigen Arbeiten, den Fluss nicht zwingend erleichtert.

Gruss Dominik

Ich bin mir bewusst, das ist ein alter Thread, aber für mich ist das ein gutes Beispiel für ein Problem, mit dem alle mir bekannten CMS konfrontiert sind.

Directentries ist eigentlich das dritte Modul, das (fast) das gleiche macht: es gibt easy_themes und mit custom_be_modules kann man zum Teil noch wesentlich mehr erreichen. Jede der drei Erweiterungen ist ein wenig anders und hat ihre eigenen Vor- und Nachteile. Bei mehreren Themes und wenigen BE-Usern ist für mich easy_themes eine schöne Lösung, bei mehreren Themes und vielen BE-Usern finde ich directentries praktischer, und für die Fälle, die sich für mich hauptsächlich ergeben, ist custom_be_modules die erste Wahl, weil ich zumeist nur ein Theme, höchstens drei Backend-User habe, und die einzelnen Stylesheets und Module ganz gezielt ansteuerbar machen möchte.

Das zeigt, dass die Vielfalt des Angebots durchaus ein Vorteil ist, aber auch, dass im Grunde eine einzige Erweiterung, die mittels Konfiguration allen drei Szenarien gerecht werden könnte, das Ideal wäre.

Auch muss mich beim Einsatz einer Erweiterung immer interessieren, wie groß die Wahrscheinlichkeit ist, dass sie vom jeweiligen Entwickler für kommende Contao-Versionen weiterhin gepflegt wird. Die Wahl einer Erweiterung wird von diesem Umstand zu einem großen Teil beeinflusst.

Ich gebe Leo recht, der davor warnt, dass immer mehr Erweiterungen entwickelt werden, die ähnliches tun und teilweise das Rad immer neu erfinden.

Warum nicht hier Synergien nutzen, indem sich die Entwickler von Erweiterungen mit sehr ähnlichen Funktionalitäten zu Teams zusammenschließen, mit dem Ziel, eine einzige Conato-Erweiterung zu entwickeln bzw. weiter zu entwickeln, die die Funktionalitäten mehrerer ähnlicher abdeckt?

Vielfalt UND Kontinuität kann eigentlich nur im Team gewährleistet werden. Wäre dies im konkreten Fall der drei genannten Erweiterungen möglich?

Gruß
Michael

Ich gebe dir grundsätzlich recht aber muss noch ein, zwei Dinge einwerfen. custom_be_modules ist vom selben Entwickler wie easy_themes und hat von Anfang an eine andere Zielsetzung gehabt. Ich installiere mir jedes Mal easy_themes, habe aber nur in jeder 5ten Installation custom_be_modules. Man kann diese Extensions einfach nicht vergleichen.

Bei directentrys_theme und easy_themes muss ich dir Recht geben. Da wurde in keinster Weise kommuniziert, wie so oft. Man darf Dominik aber auch kein Vorwurf machen - oftmals laufen die Vorstellungen nun mal auseinander. Und wenn ich z.b. bei mir in der Agentur mit 4 Devs diskutieren muss, dann habe ich kein Bedürfnis noch mit einem fremden Dev wegen einem Feature zu diskutieren. Dann wird die Extension halt selber programmiert und das genauso wie der Kunde oder der Chef es wünscht. Fertig. Man stellt sie dann nur nicht ins ER!!!

Ich denke, ich verstehe. Wäre ich selbst Entwickler, bzw. hätte ich eine Agentur, die Entwickler beschäftigt, um Kundenprojekte zu realisieren, wäre mein erstes spontanes Interesse vermutlich auch nicht gleich der Abgleich mit anderen Erweiterungen, die schon im ER existieren. Andererseits hat die Entwicklung von Erweiterungen langfristig wohl auch Auswirkungen auf das CMS als Basis.

Deswegen stimme ich Leo zu. TYPO3 wäre ein Beispiel von vielen dafür, wie ein Erweiterungs-Repository ausufern kann. Concrete5 wäre ein aktuelles Beispiel dafür, wie eine sinnvolle Kontrolle über (auch kostenlose) Erweiterungen realisiert werden kann (c5-marketplace).

Gruß
Michael

Die Tatsache, dass ich directentrys_theme gebaut habe, beruht darauf, dass ich easy_themes nicht kannte. An der Konferenz habe, so denke ich easy_themes gesehen und danach gesucht, vergebens. Also dachte ich, dass da jemand nur für sich was gebaut hat. Das man die ER Suche rauchen kann war mir noch nicht bekannt.

Damals habe ich von Leo Unglaub erfahren, dass es "diese" Erweiterung bereits gibt. Nachdem ich Sie getestet deren Source gelesen habe und noch keinen Kontakt zu Yanick hatte, beschloss ich die Erweiterung beizubehalten und weiter zu entwicklen. Da mir bis auf den Grundgedanken nichts davon gefiel. Die Navigation des Backends baute langsamer auf als bei directentrys_theme und für einen derartigen Helfer will ich keine Konfiguration haben.

Es sind zwei Philosophien, zwei Lösungsansätze für das selbe, wieso sollte ich anderen, nicht die Möglichkeit sich selbst zu entscheiden. Eventuell habe ich das schlecht kommuniziert, aber ich kann mich nicht erinnern, dass ich jemanden abwerben wollte.

Den eigentlichen Fehler den ich meines Erachtens getan habe, war die Tatsache, das der Erweiterungsname zu engstirnig war, nicht passend, für das was ich aktuell nachrüsten wollte.

Man kann Erweiterungen nicht umbenennen, es gibt keine Möglichkeit, wie bei umfangreicheren Paketmanagement Lösungen, Erweiterungen zu ersetzen, dh. als Ersatz zu deklarieren.

Vielleicht sehe ich das anders, als andere hier, aber meines Erachtens, sollte jeder die Wahl haben.

Organisatorische Probleme, Probleme in der Kommunikation, wie Sie hier auch unabhängig von mir gibt, auf meine Erweiterung abzuschieben finde ich etwas zu einfach.

Hallo zusammen,

grundsätzlich gebe ich leo.unglaub Recht, ich ärgere mich auch über doppelte Erweiterungen, übrigens auch über Bundles und Erweiterungen, die im Prinzip nix anderes machen, als was man auch mit nem schnellen Eintrag in die z.B. dcaconfig.php machen könnte und auch über schlecht gecodete Erweiterungen und auch über Erweiterungen, welche die FE-Ausgabe nicht validieren.

Ich finde directentries aber gut, weil ich mit easy_themes viele Probleme hatte vor allem auch in meinem eigenen BE-Theme und das JS auch mal anderen Erweiterungen ins Gehege kam. Bisher habe ich mir in jede Installation mit custom_be_modules einen Link zu den Modulen und ins Standardlayout gemacht. Was mittlerweile fluppt, aber directentries war da einfach nochmal schneller.

Hier ein paar Feature Requests dazu:

Da ich immer nur mit einem Theme und einem Layout arbeite (es gibt auch noch andere Entwickler, die Unterschiede zwischen diversen Seiten mit anderen Mitteln erledigen als über mehrere Layouts), wünschte ich mir, dass ich in den Usereinstelllungen die einzelnen Items abschalten könnte.

Obiger Punkt ist mir nicht ganz so wichtig, da die Icons ja klein sind und in einer Reihe sitzen (habe gerade mein ab_optimized BE-Theme für directentries angepasst), hauptsächlich aber habe ich dieses Forum hier gesucht, weil ich mir wünschte, dass ich den Layoutlink in den Usereinstellungen so einstellen kann, dass er direkt ins Standardlayout zeigt. Evtl. mit der Eingabe einer Layout-ID, im Standardfall wäre das die 1. Solange mache ich dann doch noch mit custom_be_modules.

Gruß von Andreas