[TYPO3-german] [TYPO3-v4] Announcing TYPO3 4.5 beta1

Sat Nov 20 19:38:40 CET 2010

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hallo zusammen.

Ich hatte mir eigentlich fest vorgenommen, auf diese Diskussion nicht einzusteigen. Der anfänglich enorm herbe Ton gefällt mir nicht und das ursprüngliche Thema ("warum kann ich keine X Bilder und Links in ein Text-mit-Bild-Element bauen") ist sowohl ausführlich besprochen als auch recht leidig.

Die Diskussion ist in eine Richtung abgedriftet, die mich dann aber doch ein wenig interessiert. Man darf das aktuell hier besprochene Problem wohl als "mangelhafte Standardwerte" zusammenfassen. Die gibt es auf diversen Ebenen und in diversen Komponenten.

Meine Meinung dazu: Das ist ein *sehr* schwieriges Thema. Aus meiner Praxis kann ich sagen, dass der größte Teil Individualisierung ist. Ich könnte bei den wenigsten Parametern einen sinnvolleren Standard nennen als den aktuellen weil meine Projekte dazu deutlich zu unterschiedlich sind.

Zum einen wurde das Fehlen sinnvoller Templates angesprochen. Ich halte das Introduction Package allerdings für optisch gar nicht so schlecht, und weitere Templates sollte man wohl auch via Google finden. Zugegeben, ich kenne keinen größeren Anbieter (egal ob freier oder kostenpflichtiger) Templates. Den Vermerk (sinnhaft, den Wortlaut habe ich mir nicht gemerkt) "freie Layout von XYZ" habe ich aber schon das ein oder andere mal gelesen. Wenn hier wirklich der Bedarf besteht, vielleicht kann man sowas ja auf typo3.org veröffentlichen. Evtl. lässt sich das ähnlich wie das TER aufziehen. Ein solches Layout sollte sich recht leicht als t3d-File exportieren lassen, sodass man gebündelt CSS-Dateien, HTML-Gerüst, Bilder und bei Bedarf Templavoila-Records in einer Datei hat. Es spricht aus meiner Sicht nichts dagegen, sowas "offiziell" zu machen. Vielleicht sollte man sowas mal an passender Stelle (sprich dem zuständigen TYPO3-Core-Team-Member, wer auch immer das ist) vorschlagen. Es kommt bei uns -- und so sicherlich auch bei vielen anderen -- ab und an vor, dass man mal einen Pitch nicht gewinnt und dann auf einem halb fertigen Photoshop-Dokument sitzt. Ich kann nichts versprechen weil ich hier die Preispolitik meiner Firma nicht beeinflussen kann. Vielleicht lässt sich so ein Layout mit relativ wenig Aufwand dann doch noch in Ansätzen realisieren. Das wären für mich jedenfalls die idealen Kandidaten für eine kostenfreie Veröffentlichung weil der Großteil der Layoutarbeit eh schon erledigt ist aber kein Kunde dafür existiert.
=> Wenn jemand ernsthaft Interesse daran hat soll er das mal in die Wege leiten und ggf. eine größere Abstimmung darüber anleiern.

Ein weiterer Punkt sind schlechte bzw. fehlende Defaultsettings für den RTE. Ich hab weiter oben die sinngemäße Antwort "das macht ja jeder Integrator nur einmal im Leben" gelesen. Kann ich, ehrlich gesagt, bestätigen. Ich muss aber auch zugeben, mir in dieser Beziehung das Introduction Package nicht näher angesehen zu haben. Wenn sowas irgend wo existiert dann wohl da. Beim Core handelt es sich immerhin ganz bewusst um eine nicht-konfigurierte Variante. Und wenn nicht wäre das ein Thema für einen Featurerequest konkret zum Introduction Package. Auch hierzu würde ich vorschlagen, eine gesonderte Diskussion über "was muss der RTE können und was gehört standardmäßig versteckt" anzustoßen.

Das nächste Thema sind sinnvolle Standardsettings für (zum Beispiel) sr_feuser_register.
Zunächst muss ich sagen: Ich habe gestern Abend eine Installation von 4.3 auf 4.4 gezogen und dabei alle Extensins mit aktualisiert, darunter auchi sr_feuser_register. Es verschickt nach wie vor E-Mails und man kann sich nach wie vor anmelden. Es sieht im Frontend exakt so aus wie vor dem Update. Kaputt kann ich das nicht bezeichnen.
Hier sind wir aber wieder bei der Individualisierung und der Frage, was hier der sinnvolle Standard sein soll. Im einfachsten Fall fragt man lediglich die E-Mail-Adresse und den Namen an um Newsletteranmeldungen zu sammeln. In umfangreicheren Fällen wird das Formular mehrseitig. Ich könnte wirklich nicht mit Sicherheit sagen, welches die sinnvollere Standardeinstellung wäre.
Ganz davon abgesehen handelt es sich dabei (mit Recht, wie ich finde) um eine Extension und somit müsste dieser Vorschlag der verantwortlichen Gruppe zugetragen werden, nicht dem Core-Team.

Nun noch kurz doch ein paar Worte zum Problem der vielen Bildlinks:

Ich kann grundsätzlich beide Fraktionen verstehen. Einerseits verstehe ich die Entwickler die sagen, dass man zwar technisch das Feld vergrößern kann, dass das aber keine langfristig befriedigende Lösung sein wird. Ich verstehe aber andererseits auch die Endbenutzer die fragen, warum man das nicht trotzdem einfach so machen kann. Letztendlich bin ich aber eher auf de Seite der Entwickler. Zum einen wohl, weil ich selbst einer bin. Zum anderen aber, weil ich die grundlegende Struktur "in ein Feld x Bilder, ein ein zweites x Texte, in ein drittes x Links" für äußerst "unergonomisch" halte. Das Problem, dass ein Komma ein in ener URL zulässiges Zeichen darstellt wurde schon genannt. Und jetzt erklär mal einem Kunden, dass die Eingabe von "http://www.xyz.de/foobar.html#text,links,2" in diese Zeile dazu führt, dass das erste Bild mit "http://www.xyz.de/foobar.html#text" verlinkt wird, das zweite Bild nicht und das dritte Bild mit der internen Seite mit der UID 2. Das Feld einfach zu erweitern greift schlicht zu kurz. Gerade die von Kunden gewünschten Änderungen (das betrifft nicht dieses Problem sondern ist eher so etwas wie eine Gesetzmäßigkeit) in der Größenordnung 15 Minuten sind häufig die, die noch wochenlang Regressionen nach sich ziehen.

Aus dieser Sicht heraus könnte man von einem Designfehler sprechen. Wenn es zwischen Text und Bild eine 1:n-Beziehung gibt muss diese Sachverhalt sinnvoll wiedergegeben werden, eine kommaseparierte Liste kann das in meinen Augen nur bedingt.

Ich für meinen Teil würde, soviel sei gesagt, mittels Templavoila (die Diskussion über dessen Sinn und Unsinn möchte ich hier nicht führen, das passiert mit Joey schon oft genug off-topic) passende FCEs definieren.
Der Grund dafür ist recht simpel: Die Größenordnung in der ich TYPO3 einsetze bringt stehts ein recht umfangreiches Sammelsurium an Layoutelementen mit sich. Wenn der Grafiker ein entsprechendes, tabellarisches Bilderelement vorsieht ist der Kunde in der Regel froh, wenn seine Redakteure mit möglichst wenigen Handgriffen genau das Layout füllen können. Er stört sich dagegen daran, wenn sich seine Redakteure durch Unachtsamkeit oder schlicht Unwissen (Bild 200px breit statt 190 zum Beispiel) auf fünf Seiten auf fünf unterschiedliche Arten an das Layout lediglich annähern. Kurzum, FCEs helfen, Konsistenz zu erzeugen.

Die gewünschte Lösung, das Textfeld auf xyz Zeichen zu erweitern ist wegen der enorm schlechten Bedienbarkeit absolut keine Musterlösung. Das wurde auch schon angesprochen. Ob man es dann nun durch Pages und ein HMENU löst oder tt_address spielt eigentlich keine Rolle, es müssen jedenfalls geeignete (!) Elemente dafür sein.
Auch könnte ich mir vorstellen, dass man das Text-mit-Bild-Element um ein IRRE-Feld erweitert, mit dem sich diese geeigneten Elemente dann anwählen lassen. Das ergibt dann immerhin auch eine Lösung, die der Redakteur an recht beliebiger Stelle wiederverwenden kann.

Wie ich es auch drehe: Es läuft für mich immer auf einen anfänglichen, recht geringen (Joey hat von 15 Minuten gesprochen, und lassen wir es 30 sein) Aufwand als Aufgabe eines Integrators hinaus, anschließend existiert für den Redakteur eine Möglichkeit, das (und genau das) zu erzielen.

Grüße,

Stephan Schuler
Web-Entwickler

Telefon: +49 (911) 539909 - 0
E-Mail: Stephan.Schuler at netlogix.de
Internet: http://media.netlogix.de

- --
netlogix GmbH & Co. KG
IT-Services | IT-Training | Media
Andernacher Straße 53 | 90411 Nürnberg
Telefon: +49 (911) 539909 - 0 | Fax: +49 (911) 539909 - 99
E-Mail: mailto:info at netlogix.de | Internet: http://www.netlogix.de/

netlogix GmbH & Co. KG ist eingetragen am Amtsgericht Nürnberg (HRA 13338)
Persönlich haftende Gesellschafterin: netlogix Verwaltungs GmbH (HRB 20634)
Umsatzsteuer-Identifikationsnummer: DE 233472254
Geschäftsführer: Stefan Buchta, Matthias Schmidt

________________________________________

Von: typo3-german-bounces at lists.typo3.org [typo3-german-bounces at lists.typo3.org] im Auftrag von Claus Fassing [claus at fassing.eu]
Gesendet: Samstag, 20. November 2010 18:18
An: typo3-german at lists.typo3.org
Betreff: Re: [TYPO3-german] [TYPO3-v4] Announcing TYPO3 4.5 beta1

* PGP Signed by an unknown key

Hallo Bernhard,

Am 20.11.2010 17:49, schrieb LUCOMP mediale kommunikation &
internetDesign Bernhard Ludwig:
> Oh Wunder, Joomla, Magento, einfach mal ausprobieren, macht Spaß und
> funktioniert sogar.

sieht für mich so aus als wenn die Integration von Backup/Restore bei
Joomla lediglich zur Abstimmung vorliegt [1].

> War mir aber schon klar, dass Dein Interesse nicht ernsthafter Natur war...

Das habe ich weder geschrieben noch zwischen den Zeilen platziert.

[1]http://ideas.joomla.org/forums/84261-joomla-idea-pool/suggestions/1213469-built-in-backups?ref=title

* Unknown Key
* 0xAE74E6DF(L)
_______________________________________________
TYPO3-german mailing list
TYPO3-german at lists.typo3.org
http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-german

-----BEGIN PGP SIGNATURE-----
Version: PGP Universal 3.0.0 (Build 2881)
Charset: Windows-1252

wpUDBQFM6BW3pp0IwsibV8MBCCzmBACH3L2hl0G4wXTGzcRTiDneSVPgcOvAhMt4
vMqSXRPMVMPLwKZI+b+IvaLnMQbT6IAgtx0ek57dYLFeNtR/ze12sqfutV16wHE7
ggJ32wOTs40a9XY3xz2lhmkNUWRoWc2bTL3jjUIX+pg6OPhXVYdAhw/B9rml4g5J
qxZ+avMFeg==
=g+bv
-----END PGP SIGNATURE-----