Performanceprobleme ?
Bugs in zusammenhang mit anderen Implents ?
Performanceprobleme ?
Bugs in zusammenhang mit anderen Implents ?
Benjamin Weigl, Webentwicklung & Designhttp://benjamin-weigl.de
~kein Joomla Support mehr~
Das ist Unsinn! Es befinden sich nur einige wenige dieser von dir bezeichneten "Spielzeugkomponenten" im Core. Der Poll und die Weblink Komponente machen gerade einmal 0,5% des gesamten Codes aus.
Es war nicht anders zu erwarten. Die Version 1.5 ist eine völlig neue Version. Praktisch der gesamte Code ist umgeschrieben worden. Man kann nicht erwarten dass das alles von heute auf morgen geschieht. Joomla ist Open Source. Das macht die Sache schon schwierig genug. Wenn du ein richtiges professionelles CMS haben willst dann greife zu Jalios JCMS, RedDot, EM3 iOn oder Traction TeamPage. Zur Not kannst du auch einen Microsoft Office SharePoint Server 2007 anmieten. Der dürfte deine Anforderungen halbwegs erfüllen.
Sicher. Und die erforderliche Flexibilität des Readon-Links macht natürlich viel mehr aus.
Stimmt. Bereits gefundene Lösungen wreden einfach umgeworfen, alternative Lösungen werden nicht einmal diskutiert. Auf dieser Basis nützt Open Source wenig.Es war nicht anders zu erwarten. Die Version 1.5 ist eine völlig neue Version. Praktisch der gesamte Code ist umgeschrieben worden. Man kann nicht erwarten dass das alles von heute auf morgen geschieht. Joomla ist Open Source. Das macht die Sache schon schwierig genug.
Ein Open Source Projekt, das sich wegen interner Streitereien in viele Forks zersplittert, ist früher oder später zum Scheitern verurteilt. Sinnvoll ist einzig die optimale Koordination aller angebotenen Hilfen und Lösungen.
Ich glaube einfach nicht, daß eine freie Formatierbarkeit des Readon-Links Joomla inakzeptabel ausbremsen würde. Und ich glaube ebenfalls nicht, daß die Implementierung mehr Aufwand als die Anpassung der Komponenten, die nicht in den Core gehören, sondern zusätzlich installierbar sein müßten, gewesen wäre.
Was ein herrlicher Rant um so viele ungekochte Eier.
Vielleicht sollten manche Menschen ihre Englischkenntnisse aufbessern um die Informationen auf joomla.org verfolgen und verstehen zu können.
J! 1.5 war zu keinem Zeitpunkt als die bahnbrechende Neuerung in Sachen Features oder neues CMS gedacht sondern ein Interimsrelease um die Codebase auf den Stand der Dinge zu bringen, sprich sauberen, objektorientierten Code, der unter PHP5+ flutscht und sich zukünftig besser erweitern lässt. Das kann man von dem Durcheinander -- um nicht zu sagen Sauhaufen -- in J! 1.0 nicht behauten, was inzwischen auch die Leute bei Mambo eingesehen haben. Die nehmen für ihre 5.0 jedoch lieber ein externes Framework (CakePHP) statt sich die ganze Arbeit selbst zu machen -- auch dazu gibt es Für und Wider.
Gleichzeitig soll in J! 1.5 noch die Kompatibilität mit den abertausenden "tollen" und zum Großteil nicht minder schlecht programmierten Erweiterungen von Joomla 1.0/Mambo 4.5 gewahrt bleiben, damit die Drittanbieter Zeit haben sich an das Framework zu gewöhnen. Hoffen wir mal, dass diese sich dann auch an die üblichen und in J! demonstrierten Code-Guidelines halten ...
Soviel jedenfalls dazu.
Im Core-Team gibt es sicher einige Leute deren Motivation und Attitude fragwürdig ist, so bin ich auch der Meinung, dass einige nichts in den Core-Code lassen, was sie nicht selbst "erfunden", oder an Ideen abgekupfert und dann mehr oder minder unkenntlich umgeschrieben haben. Zum Teil wohl getrieben von der GPL-Paranoia, zum anderen durch die eigene(n) Profilneurose(n). Man weiss es nicht, und man muss ja nicht jeden mögen
Grundsätzlich kann man aber sagen, dass der Code sehr sauber und gut geschrieben ist. Noch bei weitem nicht fehlerfrei, wie die noch immer anfällige Menge an offenen Tracke-Einträgen zeigt und trotzdem zu diesem (unnötigen), zum 2-jährigen Geburtstag Joomla's hinausgedroschenen RC2-Release geführt hat. Bei weitem ist er auch nicht so revolutionär wie immer gerne gesagt wird.
Was die Geschwindigkeit von Beez und die angebliche Unmöglichkeit den "Read more" Link umzubenenne angeht, so könnte das hautsächlich an der "bescheidenen" PHP-Code Qualität dieses Templates und mangelnde Kenntnis über eben erwähntes Framework liegen. HIer zeigt sich, dass gute Web-Designer nicht zwangsläufig auch gute Programmierer sind -- das gilt aber auch umgekehrt <g>
Hinzu kommt aber ein kleiner Designfehler in Joomla! bei dem für jedes Templatefile zwei Dateizugriffe erfolgen um einen "Override" zu nutzen oder auch nicht: erst im Core, dann im Template. Nun besteht Beez aus sehr, sehr vielen solcher Überschreibseln und das macht die Sache natürlich nicht schneller. Sicher könnte das Funktionsprinzip intelligenter (innerhalb Joomlas) gelöst werden.
Weiterhin sollte man sich an geeigneter Stelle im Core (-Code und -Team) mal ein paar schlanke Gedanken über das in Teilen noch ausstehende Caching machen, ohne auf PHP-Extensions angewiesen zu sein. Eine Optimierung des Codes als solches steht ohnehin erst vor der Final an.
Doch zurück zu Beez, aber vorab: Ich stelle dessen Qualität in Sachen BITV, 508, WGAC, und wie sie alle heissen, nicht in Abrede, lediglich die technische Umsetzung... und vielleicht liegt darin mit ein Grund warum das Core-Team dieses Template nicht ganz so ernst nimmt wie dessen Erschaffer(in) es gerne hätte(n).
Hier wird dem PHP-Interpreter praktisch keine Möglichkeit zur Optimierung gelassen. Das gesamte Template besteht ausschliesslich aus PHP-Code, der zu 80% nicht mal welcher ist, sondern zusammen geheftete "HTML-Strings".
Anstatt das hässliche, aber optimierbare <?php ... ?> zu nutzen wo es nötig ist, werden alle HTML-Tags ohne Rücksicht auf Verluste durch echo ausgegeben, und dazu noch in der schlechtest möglichen Weise: mit "." getrennt, statt mit ","
Schlecht/langsam: echo 'Hallo' . ' ' . 'Welt';
Gut/schnell: echo 'Hallo', ' ', 'Welt';
Abgesehen von diesem "Zustand" ist der PHP-Code des Template für jeden Editor völlig wertfrei im Sinne einer möglichen Syntaxüberprüfung oder für eine ansatzweise Quelltexthervorhebung -- sind sowieso alles Strings... Der Unterschied ist sogar schon hier im Beitrag zu "sehen".
Das ist ganz sicherlich nicht die Art "Quelltext", die meiner einer als Basis für eine neue Vorlage verwenden möchte.
Zum angeblich nicht überschreibbaren "Read more" Link.
Wie gesagt würde eine bessere Kenntnis von PHP und des Joomla! Frameworks dazu beitragen, ein Problem zu lösen das keines ist, und zwar mit deutlich weniger Code als derzeit (RC2) in Beez genutzt wird.
Original Code:
Eindeutiger Linktitel (Beispiel):PHP-Code:if ($this->params->get('show_readmore') && $this->params->get('show_intro') && $this->item->readmore_text) {
echo '<p><a href="' . $this->item->readmore_link . '" class="readon' . $this->params->get('pageclass_sfx') . '">';
$alias = JFilterOutput :: stringURLSafe($this->item->title);
if ($this->item->title_alias == $alias || $this->item->title_alias == '') {
echo $this->item->readmore_text;
} else {
echo $this->item->title_alias;
}
echo '</a></p>';
}
Oder so:PHP-Code:if ($this->params->get('show_readmore') && $this->params->get('show_intro') && $this->item->readmore_text) {
echo '<p><a href="' . $this->item->readmore_link . '" class="readon' . $this->params->get('pageclass_sfx') . '">'
, JText::_('Read more...'),' <q>', $this->item->title,'</q>'
, '</a></p>';
}
Der Text 'Continue with' ist in der Sprachdatei des Templates untergebracht, das Resultat ist im Anhang zu sehen. Ich stelle diese Lösungsmöglichkeit hiermit gerne zur weiteren Verarbeitung zu Verfügung, sollte sie den hohen Ansprüchen genügenPHP-Code:<?php if ($this->params->get('show_readmore') && $this->params->get('show_intro') && $this->item->readmore_text) : ?>
<p><a href="<?php echo $this->item->readmore_link?>" class="readon<?php echo $this->params->get('pageclass_sfx')?>">
<?php echo JText::_('Continue with'),' <q>', $this->item->title,'</q>'; ?>
</a></p>
<?php endif; ?>
Wie gesagt ist das einstreuen der <?php .. ?> Tags hässlich, hilft aber dem PHP-Interpreter schon im Vorfeld dabei festzustellen, was ihn angeht und was er einfach durchschieben kann.
Ansonsten noch viel Spaß beim gegenseitig angiften.
CirTap
Geändert von CirTap (02.09.2007 um 04:29 Uhr) Grund: schraibpfehla
Shit happens....dumm gelaufen.
so sehr ich auch die Arbeit von Angie u Robert respektiere...
aber sie hätten wissen müssen (oder zumindest in Betracht ziehen müssen), dass das Core Team seinen eigenen Kopf hat. Das hat es in der Vergangenheit immer wieder bewiesen.
Die beiden haben sich weit aus dem Fenster gelehnt und gehofft, dass ihr Code ins Core einfließt (verständlich).
Dieses ist nun nicht geschehen u nun ist das Geweine da. Das ist aber genau das Risiko, dessen man sich im Vorfeld bewusst sein muss. Und jetzt negative Stimmung gegen das Core-Team zu machen, ist meiner Meinung nach nicht angebracht.
Ebenso nicht gerechtfertigt finde ich das Posting dieses offenen Briefes in diesen Channel, in dem es meiner Meinung nach nur um Ankündigungen u Mitteilungen offizieller Joomlaangelegenheiten geht. Dieser thread ist jedoch absolut privat u sollte daher in einem anderen Channel stehen.
Hier ist der Mod-Status ungerechtfertigt ausgenutzt worden(denn nur Mods dürfen hier posten)..um einen Beitrag hervorzuheben....für private Reibereien ..sorry lukewill
Ich möchte ja gar nicht bestreiten, dass diese Entwicklungen ins Core müssen...Zusammen mit Robert Deutz habe ich deshalb den ersten Run-Digital Hack entwickelt, der die zuständigen Core-Dateien überschrieb, um eine strukturierte Ausgabe möglich zu machen.
Ich weiss nur, dass wäre ich im Core-Team, mich jeder noch so gut gemeinte und ausgeführte Hack stören würde. Denn sollte durch so eine Code-Veränderung das Programm Macken haben, fiele der dunkle Schatten nämlich auf das komplette Programm.
Alan
Ich reagiere nur auf Fragen, deren Lesbarkeit keine Zumutung darstellt
JUG-im-Pott (Joomla-User-Group)
und ebenfalls "no Artisteer support"
@Cirtap,
deine vorgeschlagen Lösung ist keine. Es würde sich dabei nur um eine Wiederholung einer schon vorhandenen Information handeln. Das ist auch nicht besser, der "weiterlesen" link soll etwas über das Sprungziel aussagen.
Bzgl. der Anmerkungen PHP-Code, ich persönlich finde das diese "?>" und "<?php" die Lesebarkeit deutlich verschlechtern, hier muss man sich einfach fragen was will man erreichen. Die Verständlichkeit für das was da passiert erhöhen oder performanten Code.
Soweit zu dem inhaltlichen, ansonsten finde ich dein Posting vollkommen unverschämt. Du behauptest bzw. unterstellst mangelnde Sachkenntnis und eine schlechte technisch Umsetzung. Du hättest dich besser vorher etwas mehr informiert bevor du solches unterstellst. Deine Kritikpunkte hängen entweder mit den Rahmenbedingungen des Frameworks zusammen (Overide, Dateizugriffe - übrigens passiert das egal welches template du nutzt -) oder sind eben keine Lösung für das Problem. Bevor man solch einen Hammer rausholt und zuschlägt, wäre ein konstruktiver Beitrag sicher besser gewesen.
Das hatte ich bereits geschrieben.![]()
In Joomla 1.5 ging es primär ein Framework für kommende Entwicklungen aufzubauen. Das ist eine sehr schwierige Angelegenheit, weil eine sehr gute Konzeption erforderlich ist um am Ende nicht wieder einen verwirrenden und schlechten Codebestand zu erhalten.
Alles richtig. Der Codebestand der 1er ist tatsächlich unter aller Sau. Die Entscheidung CakePHP einzusetzen ist per se nicht verkehrt. Es wird sich zeigen welche Strategie letztenendes die Bessere war. Eigenes Framework oder die Auslagerung der Entwicklung an Dritte.
Objektorientierter Code hat den Vorteil das der interne Code von Joomla geschützt bleibt und nur über die Schnittstellen ein Zugriff möglich ist. Viel Unsinn werden Komponentenentwickler in Zukunft damit nicht mehr treiben können. Das einzige Problem liegt in der Frage ob das Joomla 1.5 Framework auch richtig verwendet wird. Die Komponentenentwickler können auch dazu abdriften reinen eigenen PHP Code zu nutzen und auf diese Weise den Großteil des Joomla Codes außen vor zu lassen. Man kann zugunsten eines sichereren, saubereren, effizienteren und kompakteren Code nur hoffen dass das nicht viele machen werden.
Ganz meine Meinung. Der RC2 Realese war vollkommen überflüssig. Zudem war zum Zeitpunkt des Release bekannt das es Probleme mit SEO gibt, die vor einigen Tagen aufgrund von Codeänderungen aufgetaucht sind. Man hätte zumindest warten sollen bis das gefixt wird. Ansonsten stimmt auch das andere. Der Code ist mehr oder weniger sauber und gut strukturiert. Zumindest besteht sehr viel Potential. Allerdings wird es noch 1 Jahr dauern bis die meisten Komponentenentwickler lernen damit umzugehen und brauchbares produzieren.
Alles wieder richtig. Codeoptimierungen werden aber auch bei der Final nur von marginaler Natur sein. Es ist anzunehmen das es noch eine ganze Weile dauern wird, bis das gesamte System hinreichend optimiert wurde.
Das ist richtig. Allerdings ist die Ausgabe in PHP im Vergleich zu anderem Code so schnell, das die Art der Verknüpfung von Zeichenketten kaum Auswirkungen auf die Performance haben dürfte.
Designer sind nunmal keine PHP-Programmierer. Deshalb existieren auch Projekte, wie Smarty.
@Alan,
also erst mal war es Auftrag der Core-teams, das Template zu entwickeln. Und zweitens war von Anfang an klar das das template mit in die Version kommt.
Ob das hier der richtige channel ist ... naja ich finde schon, aber von mir aus kann man das nach woauchimmer verschieben.
Das Thema ist allerdings mit Sicherheit keine Privatangelegenheit. Ich kann das alles auch selber machen, die notwendigen Ergänzungen kann ich ganze einfach selber im Template unterbringen.
Aber auf einen guten Gedanken bringst du mich, ich sollte in Betracht ziehen und mich mehr um privates kümmern anstatt 3 Wochen mit der Erstellung eines Templates verbringen.
Lesezeichen